Skip to content
/

cc-sdd (gotalab)

cc-sdd · gotalab/cc-sdd · ★ 3.4k · last commit 2026-05-20

Portable Kiro-style SDD harness for 8 AI agents: discovery-routed spec creation with boundary-annotated tasks and autonomous subagent-per-task TDD implementation.

Best whenSpecs should be system contracts defining component boundaries, not master command documents — making them useful even without an active agent session.
Skip ifCreating a spec for a trivial bug fix or refactor, Batching multiple sub-tasks into a single subagent dispatch
vs seeds
spec-kitlacks. Compared to superpowers, cc-sdd is feature-sco…
Primitive shape 20 total
Skills 17 Subagents 3
00

Summary

cc-sdd — Summary

cc-sdd (gotalab) is a Kiro-inspired, Spec-Driven Development harness delivered as an npm CLI tool (npx cc-sdd@latest) that installs 17 Agent Skills across 8 AI coding agents (Claude Code, Codex, Cursor, Copilot, Windsurf, OpenCode, Gemini CLI, Antigravity). It models the full agentic SDLC: discovery → requirements → design → tasks → autonomous implementation with per-task independent subagent review and auto-debug passes. The spec is treated as a contract between parts of the system, not a master command document; boundaries declared in design.md are enforced by annotated task boundaries (_Boundary:_, _Depends:_) and reviewed by fresh independent reviewer subagents per task. Long-running kiro-impl autonomous mode dispatches one fresh implementer subagent per task, with a separate reviewer subagent and an auto-debug loop that re-enters the task if the reviewer rejects it twice. Steering documents (.kiro/steering/product.md, tech.md, structure.md) carry persistent project context across sessions. Version 3.0.2 (May 2026) represents a complete rework from slash-command mode to skills mode with TDD (RED → GREEN) behind feature flags and learnings propagated forward via ## Implementation Notes in tasks.md.

Differs from seeds: Most similar to the kiro seed (EARS requirements, design.md + tasks.md under .kiro/specs/, steering layer) but cc-sdd is a fully portable npm package installable in 8 agents, not a proprietary IDE. Compared to spec-kit (GitHub's Python CLI), cc-sdd ships 17 skills vs spec-kit's 9 commands/9 skills, adds subagent-per-task autonomous implementation, and introduces TDD feature flags; spec-kit has no autonomous implementation phase. Compared to superpowers, cc-sdd adds a discovery routing step, multi-spec batch decomposition, and boundary-first design discipline, while superpowers emphasizes Iron Law skill enforcement.

01

Overview

cc-sdd — Overview

Origin

Created by Gota (gotalab) as an openly acknowledged derivative of Kiro IDE's spec-driven development workflow. The README states explicitly: "Kiro-inspired. Similar spec-driven, agentic SDLC style as Kiro IDE. Existing Kiro specs remain compatible and portable." First published as a narrow Claude Code slash-command port; version 3.0 (2026) was a complete rework into platform-agnostic Agent Skills. Available on npm as cc-sdd version 3.0.2.

Philosophy (Verbatim from README/Docs)

"cc-sdd treats the spec as a contract between parts of the system, not a master command document handed to the agent. Code remains the source of truth. Specs make the boundaries between parts of the code explicit so humans and agents can work in parallel without constant synchronization."

"The bet: explicit contracts at the right granularity let AI-driven development at team scale move faster, not slower. Agents write the spec, humans approve the contract at phase gates, code is what ships."

"Boundaries are not overhead. They are what lets you move freely inside while protecting the outside."

Key Design Choices

  1. Discovery routing before spec creationkiro-discovery inspects the project state and routes the request to one of five paths: extend existing spec, implement directly with no spec, create new spec, multi-spec decomposition, or mixed. Avoids creating a spec for trivial changes.

  2. Boundary-first spec disciplinedesign.md includes a File Structure Plan. Every task in tasks.md carries _Boundary:_ and _Depends:_ annotations. Review and validation look for boundary violations, not just style issues.

  3. One subagent per taskkiro-impl autonomous mode dispatches a fresh implementer per task, an independent reviewer afterward, and an auto-debug pass if the reviewer rejects twice. Learnings from earlier tasks propagate forward via ## Implementation Notes in tasks.md.

  4. TDD RED → GREEN behind feature flags — Each behavioral task gets a feature flag; tests are written first (RED), then implementation (GREEN), flag removed at the end. Non-behavioral tasks skip the flag protocol.

  5. Multi-spec batch decompositionkiro-spec-batch turns a roadmap.md (written by discovery) into multiple specs in parallel, with cross-spec review to catch contradictions and interface mismatches.

  6. Progressive disclosure via skills — Skills are loaded on demand; users see only the relevant ones without reading a large spec beforehand.

Antipatterns

  • Skipping kiro-discovery for ideas that might need decomposition
  • Creating a spec for a bug fix or trivial refactor
  • Batching multiple tasks into one subagent dispatch in autonomous mode
  • Using kiro-impl without approved tasks in spec.json
02

Architecture

cc-sdd — Architecture

Distribution

  • npm package: cc-sdd v3.0.2 (public npm registry)
  • CLI binary: cc-sdd (shipped as bin.cc-sdd in package.json, entrypoint dist/cli.js)
  • TypeScript source in tools/cc-sdd/src/; compiled to dist/
  • Templates directory: tools/cc-sdd/templates/agents/ — one subdirectory per supported agent × two modes (skills, legacy)

Install

npx cc-sdd@latest                      # Claude Code Skills (default)
npx cc-sdd@latest --codex-skills       # Codex Skills
npx cc-sdd@latest --cursor-skills      # Cursor IDE Skills (beta)
npx cc-sdd@latest --copilot-skills     # GitHub Copilot Skills (beta)
npx cc-sdd@latest --windsurf-skills    # Windsurf IDE Skills (beta)
npx cc-sdd@latest --opencode-skills    # OpenCode Skills (beta)
npx cc-sdd@latest --gemini-skills      # Gemini CLI Skills (beta)
npx cc-sdd@latest --antigravity        # Antigravity Skills (beta)

Additional options: --lang <code> for 13 supported languages (e.g. --lang ja, --lang zh-TW).

Directory Tree (installed into project)

.claude/
  skills/
    kiro-debug/SKILL.md
    kiro-discovery/SKILL.md
    kiro-impl/SKILL.md          # + templates/ subdirectory
    kiro-review/SKILL.md
    kiro-spec-batch/SKILL.md
    kiro-spec-design/SKILL.md
    kiro-spec-init/SKILL.md
    kiro-spec-quick/SKILL.md
    kiro-spec-requirements/SKILL.md
    kiro-spec-status/SKILL.md
    kiro-spec-tasks/SKILL.md
    kiro-steering/SKILL.md
    kiro-steering-custom/SKILL.md
    kiro-validate-design/SKILL.md
    kiro-validate-gap/SKILL.md
    kiro-validate-impl/SKILL.md
    kiro-verify-completion/SKILL.md
CLAUDE.md                             # top-level doc injected by installer
.kiro/
  specs/{feature}/
    spec.json          # metadata + approval status
    requirements.md
    design.md
    tasks.md
    brief.md           # written by discovery
  steering/
    product.md
    tech.md
    structure.md
    roadmap.md         # multi-spec projects
  settings/
    templates/         # project-scoped templates

Required Runtime

  • Node.js ≥ 18 (for the CLI installer)
  • No runtime dependency at agent execution time — skills are markdown files read by the agent

Target AI Tools

Claude Code (stable), Codex CLI (stable), Cursor IDE (beta), GitHub Copilot (beta), Windsurf IDE (beta), OpenCode (beta), Gemini CLI (beta), Antigravity (beta, experimental), Qwen Code (legacy commands only, not skills)

Internal Source Structure

tools/cc-sdd/src/
  cli.ts / index.ts        # CLI entry, runCli()
  cli/
    agents.ts              # agent detection + template selection
    args.ts                # argument parsing
    config.ts              # config loading
    io.ts                  # file I/O
    policies.ts            # install policies
    store.ts               # install state
  template/                # template rendering
  manifest/                # manifest loading (templates/manifests/*.json)
  resolvers/               # path resolution
  plan/                    # install plan computation
  utils/
templates/
  agents/
    claude-code-skills/    # 17 SKILL.md files + docs/CLAUDE.md
    codex-skills/
    cursor-skills/
    ...
  manifests/               # JSON manifests per agent variant
  shared/                  # shared settings templates
03

Components

cc-sdd — Components

CLI Binary

Name Purpose
cc-sdd npm CLI that installs agent-specific skill files into a project directory; takes flags for agent type + language

Agent Skills (17 — Claude Code variant; identical set for all 8 agents)

Skill Name Purpose
kiro-discovery Entry point — detects project state, routes to one of 5 action paths, writes brief.md and optionally roadmap.md
kiro-spec-init Initialize a new spec directory and spec.json metadata file
kiro-spec-requirements Generate EARS-format requirements with user stories and acceptance criteria; iterates with user until approved
kiro-spec-design Generate architecture doc with Mermaid diagrams and File Structure Plan; updates spec.json approval
kiro-spec-tasks Break design into tasks with _Boundary:_ and _Depends:_ annotations; TDD task sequencing
kiro-spec-quick Single-command spec creation (init + requirements + design + tasks in one run; supports --auto)
kiro-spec-batch Multi-spec decomposition — turns roadmap.md into specs in dependency-wave parallel order
kiro-impl Autonomous implementation — dispatches one fresh subagent per task, independent review, auto-debug on failure
kiro-review Task-local adversarial review protocol used by reviewer subagents spawned by kiro-impl
kiro-debug Root-cause-first debug protocol used by debugger subagents when implementer is blocked
kiro-verify-completion Fresh-evidence gate before success or completion claims
kiro-validate-gap Gap validation for existing codebases — checks if spec covers real code state
kiro-validate-design Design quality review — alignment with requirements, boundary clarity
kiro-validate-impl Standalone re-validation of implementation against spec
kiro-spec-status Show per-spec phase progress summary
kiro-steering Create/update default steering files (product.md, tech.md, structure.md)
kiro-steering-custom Manage custom steering files with different inclusion modes

Subagent Roles (spawned by kiro-impl)

Role Mechanism
Implementer Spawned via native Task tool per kiro-impl iteration
Reviewer Independent reviewer subagent per task — spawned after implementer completes
Debugger Auto-debug subagent spawned when implementer is blocked or reviewer rejects twice

Templates

Templates in tools/cc-sdd/templates/agents/claude-code-skills/skills/kiro-impl/templates/:

  • implementer-prompt.md — Template for constructing per-task implementer subagent prompt
  • (Reviewer and debugger prompts also included per-skill)

Config Files (Project-Level)

File Purpose
.kiro/specs/{feature}/spec.json Metadata: name, phase, approvals, language
.kiro/steering/product.md Product vision and goals
.kiro/steering/tech.md Tech stack and conventions
.kiro/steering/structure.md Directory/module structure conventions
.kiro/steering/roadmap.md Multi-spec initiative roadmap (written by discovery)
CLAUDE.md Top-level agent instructions injected by installer
05

Prompts

cc-sdd — Prompts

Excerpt 1: kiro-discovery Skill — Discovery Routing (Step 2)

Source: tools/cc-sdd/templates/agents/claude-code-skills/skills/kiro-discovery/SKILL.md

Prompting technique: Structured decision-tree routing with explicit paths; uses minimal-context preflight before loading heavy context. Delegates codebase exploration to a subagent to keep main context lean.

### Step 2: Determine Action Path

Based on the user's request and the metadata from Step 1, determine which path applies:

**Path A: Existing spec covers this**
- The request is an extension, enhancement, or fix within an existing spec's domain
- Every meaningful part of the request fits that same spec boundary
- Any remaining small follow-up work can be handled directly without creating a new spec
- Skip remaining steps

**Path B: No spec needed**
- The request is a bug fix, config change, simple refactor, or trivial addition
- No meaningful part of the request needs a new or updated spec boundary
- The request does not need to update an existing spec either
- Skip remaining steps

**Path C: New single-scope feature**
- The request is new, doesn't overlap with existing specs, and fits in one spec

**Path D: Multi-scope decomposition needed**
- The request spans multiple domains or would produce 20+ tasks in a single spec

**Path E: Mixed decomposition**
- The request contains a mix of: existing spec extensions, one or more new spec candidates, and optional direct-implementation work
- Use this path only when at least one genuinely new spec boundary is needed

For Path C/D/E, present the determined path (or mixed decomposition) to the user and confirm before proceeding.
For Path A/B, recommend the next action and stop.

Excerpt 2: kiro-impl Skill — Implementer Subagent Dispatch

Source: tools/cc-sdd/templates/agents/claude-code-skills/skills/kiro-impl/SKILL.md

Prompting technique: Iteration discipline enforced as explicit constraint; context-window management via one-line summaries; TDD RED → GREEN protocol.

#### Autonomous Mode (subagent dispatch)

**Iteration discipline**: Process exactly ONE sub-task (e.g., 1.1) per iteration. Do NOT batch multiple sub-tasks into a single subagent dispatch. Each iteration follows the full cycle: dispatch implementer → review → commit → re-read tasks.md → next.

**Context management**: At the start of each iteration, re-read `tasks.md` to determine the next actionable sub-task. Do NOT rely on accumulated memory of previous iterations. After completing each iteration, retain only a one-line summary (e.g., "1.1: READY_FOR_REVIEW, 3 files changed") and discard the full status report and reviewer details.

For each task (one at a time):

**a) Dispatch implementer**:
- Read `templates/implementer-prompt.md` from this skill's directory
- Construct a prompt by combining the template with task-specific context:
  - Task description and boundary scope
  - Paths to spec files: requirements.md, design.md, tasks.md
  - Exact requirement and design section numbers this task must satisfy (using source numbering, NOT invented `REQ-*` aliases)
  - Task-relevant steering context and parent-discovered validation commands (tests/build/smoke as relevant)
  - Whether the task is behavioral (Feature Flag Protocol) or non-behavioral

Excerpt 3: kiro-discovery — Subagent Delegation for Context Efficiency

Source: tools/cc-sdd/templates/agents/claude-code-skills/skills/kiro-discovery/SKILL.md

Prompting technique: Explicit context-budget cap; offloads heavy exploration to a subagent returning a max-200-line summary.

**Delegate to subagent via Agent tool** (keeps exploration out of main context):
- **Codebase exploration**: Dispatch a subagent to explore the codebase and return a structured summary. Example prompt: "Explore this project's codebase. Summarize: (1) tech stack and frameworks, (2) directory structure and key modules, (3) patterns and conventions used, (4) areas relevant to [user's request]. Return a summary under 200 lines."
- The subagent uses Read/Glob/Grep to explore, then returns findings. Only the summary enters the main context.
- For Path D/E, also ask the subagent to identify natural domain boundaries, existing module separation, and which areas look like existing-spec extensions vs new boundaries.
- Skip subagent dispatch for small/obvious requests where the top-level directory listing from Step 1 is sufficient.

**Context budget**: Keep total content loaded into main context under ~500 lines. The subagent handles the heavy exploration.
09

Uniqueness

cc-sdd — Uniqueness and Positioning

Differs from Seeds

cc-sdd is most similar to the kiro seed (same EARS requirements format, same requirements.md/design.md/tasks.md triplet under .kiro/specs/, same steering layer concept) but diverges significantly: it is a portable npm package for 8 AI agents, not a proprietary IDE. The spec-kit seed (GitHub's Python CLI) is the closest in tooling style, but spec-kit installs 9 commands + 9 skills without an autonomous implementation phase; cc-sdd adds kiro-impl's subagent-per-task loop, TDD feature flags, and boundary annotations. The superpowers seed emphasizes Iron Law skill enforcement triggered automatically at every session; cc-sdd is command-invoked per feature and focuses on boundary-first contracts and multi-spec decomposition rather than session-wide behavioral enforcement. cc-sdd is alone in the corpus in introducing a discovery routing step that explicitly avoids creating specs for trivial work, and in propagating implementation learnings forward via ## Implementation Notes.

Distinctive Positioning

  • "Spec as system contract": Unlike frameworks that treat the spec as agent instructions, cc-sdd treats the spec as a boundary definition between code components, making it meaningful even when the agent is no longer involved.
  • Discovery-first routing: Prevents over-engineering by routing trivial requests (bug fixes, refactors) away from the full spec pipeline.
  • 8-agent portability: Same skill set, different install paths — the most broadly deployed spec-driven framework in the corpus.
  • Backward Kiro compatibility: Projects started with Kiro IDE (.kiro/specs/) can use cc-sdd immediately.

Observable Failure Modes

  1. Boundary drift: If the File Structure Plan in design.md doesn't match actual implementation, _Boundary:_ annotations become misleading and reviewers miss real violations.
  2. Reviewer rubber-stamping: Independent reviewer subagents receive the same model + context as implementers; without true adversarial incentive, they may over-approve.
  3. Autonomous mode interruption: If kiro-impl is interrupted mid-task and the user re-runs it, the implementer may re-attempt a partially completed task. The spec.json approval check and tasks.md checkbox are the only idempotency guards.
  4. Beta agent instability: 6 of 8 platforms are labeled beta; subagent spawn behavior and skill loading edge cases are likely.
  5. Context budget overflow on large roadmaps: Discovery delegates exploration to a subagent capped at 200 lines, but large codebases may need more context for accurate routing.
04

Workflow

cc-sdd — Workflow

Phases and Artifacts

Phase Command/Skill Artifact(s)
0. Steering (optional) kiro-steering .kiro/steering/product.md, tech.md, structure.md
1. Discovery kiro-discovery "idea" .kiro/specs/{feature}/brief.md; .kiro/steering/roadmap.md (multi-spec)
2. Init kiro-spec-init "description" .kiro/specs/{feature}/spec.json
3. Requirements kiro-spec-requirements {feature} .kiro/specs/{feature}/requirements.md (EARS format)
3a. Gap Validation (optional) kiro-validate-gap {feature} Validation report inline
4. Design kiro-spec-design {feature} [-y] .kiro/specs/{feature}/design.md (arch + File Structure Plan + Mermaid)
4a. Design Validation (optional) kiro-validate-design {feature} Design review report
5. Tasks kiro-spec-tasks {feature} [-y] .kiro/specs/{feature}/tasks.md (boundary + dependency annotated)
6. Implementation kiro-impl {feature} [task#s] Code changes, test files, tasks.md checkbox updates

Approval Gates

Gate Type Description
After requirements freetext-clarify User must explicitly approve requirements.md before design starts
After design freetext-clarify User must explicitly approve design.md before tasks start (bypass with -y)
After tasks freetext-clarify User must explicitly approve tasks.md before autonomous implementation starts
Discovery path confirmation choice-list When discovery proposes Path C/D/E, user confirms before deep context loading
Multi-spec decomposition yes-no Discovery presents decomposition plan, user confirms before kiro-spec-batch
Reviewer rejection (2×) auto-trigger If independent reviewer rejects the same task twice, auto-debug subagent is spawned

Key Workflow Mechanics

Discovery Paths

  • Path A: Existing spec covers the request → extend it
  • Path B: No spec needed (bug fix, refactor) → implement directly
  • Path C: New single-scope feature → single spec pipeline
  • Path D: Multi-scope → kiro-spec-batch with roadmap.md
  • Path E: Mixed decomposition → combination of A/B/C/D

kiro-impl Autonomous Loop (one sub-task per iteration)

  1. Re-read tasks.md to determine next actionable sub-task (numbered X.Y)
  2. Read implementer-prompt.md template; construct per-task prompt
  3. Dispatch implementer subagent (fresh context, TDD RED → GREEN)
  4. Dispatch independent reviewer subagent (adversarial completeness check)
  5. If reviewer approves: commit, update tasks.md, proceed
  6. If reviewer rejects once: implementer retries
  7. If reviewer rejects twice: dispatch auto-debug subagent (root-cause-first)
  8. Retain only one-line summary of completed task, discard full status

TDD Protocol

  • Behavioral tasks: write failing tests FIRST, implement to GREEN, remove feature flag
  • Non-behavioral tasks: skip feature flag protocol
  • Validation commands (TEST_COMMANDS, BUILD_COMMANDS, SMOKE_COMMANDS) discovered from repo tooling (package.json, Makefile, CI files) during kiro-impl preflight

Prompt Chaining

One phase's output is the explicit input for the next:

  • requirements.md → input to kiro-spec-design
  • design.md → input to kiro-spec-tasks
  • tasks.md → input to kiro-impl
  • Learnings from task N → ## Implementation Notes in tasks.md → context for task N+1
06

Memory Context

cc-sdd — Memory and Context

State Storage

All state is file-based under .kiro/:

File Content
.kiro/specs/{feature}/spec.json Structured metadata: name, phase status, approvals (requirements/design/tasks), language
.kiro/specs/{feature}/requirements.md EARS-format requirements
.kiro/specs/{feature}/design.md Architecture, File Structure Plan, Mermaid diagrams
.kiro/specs/{feature}/tasks.md Annotated task list with _Boundary:_, _Depends:_ markers; checkbox completion status
.kiro/specs/{feature}/brief.md Discovery output: work description and recommended path
.kiro/steering/roadmap.md Multi-spec initiative plan written by discovery
.kiro/steering/product.md Product vision (persistent project context)
.kiro/steering/tech.md Tech stack and coding conventions
.kiro/steering/structure.md Directory/module structure conventions
CLAUDE.md Top-level doc loaded by Claude Code at session start

Persistence Level

project — all state files live under .kiro/ within the repository. No global state, no external database.

Context Compaction Handling

  • CLAUDE.md injected at session start provides restoration anchor
  • Steering documents (product.md, tech.md, structure.md) are re-loaded by each skill as needed — spec context is never assumed to be in active context
  • kiro-impl autonomous mode explicitly re-reads tasks.md at the start of each iteration to avoid relying on accumulated memory
  • After each task iteration, only a one-line summary is retained; full context is discarded

Cross-Session Handoff

Yes — spec.json tracks phase and approval state, so work can resume across sessions. Any skill reads the spec files fresh rather than relying on conversational history.

Implementation Notes (Forward Propagation)

A novel feature: when kiro-impl completes a task, it appends learnings to a ## Implementation Notes section in tasks.md. Subsequent task subagents receive this as context, allowing incremental knowledge accumulation within a spec run without polluting the main context.

Steering vs Spec

  • Steering (.kiro/steering/): Project-wide rules, tech stack, product vision — loaded by any skill on demand
  • Specs (.kiro/specs/{feature}/): Feature-specific phase artifacts — loaded by feature-specific skills
  • Steering is analogous to Kiro IDE's "Always" and "On-Condition" steering inclusion modes
07

Orchestration

cc-sdd — Orchestration

Multi-Agent

Yes — kiro-impl autonomous mode dispatches three distinct subagent roles per task: implementer, reviewer, debugger.

Orchestration Pattern

task-decomposition-tree with sequential per-task waves:

  • Parent (kiro-impl) owns the task queue from tasks.md
  • Per task: spawns implementer subagent → reviewer subagent → optional debugger subagent
  • One sub-task per iteration; strictly sequential within a spec
  • kiro-spec-batch enables parallel spec creation across multiple features (parallel-fan-out for the spec-writing phase)

Multi-Model

No — skills use whatever model the agent runs. No role-based model routing configured.

Isolation Mechanism

none for primary workflow — subagents edit files in-place. The skill references Cursor 3.2 worktrees as an optional mechanism when using the Cursor variant, but no automatic worktree-per-task isolation.

Subagent Definition Format

task-tool-spawn — subagents are dispatched via the platform's native Task/Agent tool with a constructed prompt; no separate persona file or class definition.

Execution Mode

interactive-loop for spec phases (each phase waits for human approval before continuing); continuous-ralph style for kiro-impl autonomous mode (loops over tasks until all complete or blocked).

Prompt Chaining

Yes — each phase explicitly reads the prior phase's artifact:

  • kiro-spec-design reads requirements.md
  • kiro-spec-tasks reads design.md
  • kiro-impl reads requirements.md + design.md + tasks.md + ## Implementation Notes

Consensus Mechanism

None — single reviewer subagent per task; two rejections trigger debugger subagent (not quorum/vote).

Max Concurrent Agents

1 task implementer at a time in kiro-impl; kiro-spec-batch parallelizes spec writing by dependency wave (count depends on roadmap topology).

Cross-Tool Portability

High — same 17-skill set installed with platform-specific file paths. Claude Code and Codex are stable; 6 others are beta.

08

Ui Cli Surface

cc-sdd — UI, CLI, and Surface

CLI Binary

  • Binary name: cc-sdd
  • Invocation: npx cc-sdd@latest [flags]
  • Purpose: Installer only — not a runtime CLI. Run once to copy agent-specific skill files + CLAUDE.md into the project.
  • Is thin wrapper: No — it is its own TypeScript runtime with manifest resolution, template rendering, and multi-agent path logic.
  • Subcommands / flags (from README + package.json):
    • --claude-skills / --codex-skills / --cursor-skills / --copilot-skills / --windsurf-skills / --opencode-skills / --gemini-skills / --antigravity — agent selection
    • --lang <code> — language selection (13 languages)
    • Legacy flags (deprecated): --claude, --codex, --cursor, --copilot, --windsurf, --opencode, --gemini

Local Web UI / Dashboard

None — no embedded web dashboard or TUI.

IDE Integration

  • Cursor IDE supported via .cursor/ skill path (beta)
  • VS Code supported via GitHub Copilot skills (beta)
  • Windsurf IDE supported (beta)

Observability

  • Audit log: No dedicated audit log file
  • Spec status: kiro-spec-status {feature} skill shows phase progress from spec.json
  • Implementation Notes in tasks.md serve as a soft audit trail of per-task learnings
  • No replay capability

Agent Console / Monitoring

No dedicated monitoring surface. All feedback is inline in the agent conversation.

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.