cc-sdd

Install

npx cc-sdd@latest

This is third-party code. Review the repository files before installing.

What it does

A single npx command installs 17 kiro-* skills into the project. The kiro-discovery skill analyzes the request and decides whether to create a spec, extend an existing one or implement directly. The agent then writes requirements, a design with a file structure plan and tasks, and a human approves each phase. The kiro-impl skill runs tasks one at a time with TDD, an independent reviewer and a separate debug pass when work gets stuck.

Who it is for. For teams and developers who want the agent to follow an approved spec rather than one-off prompts.

Example request

/kiro-discovery add subscription billing with a trial period to the service

Limitations

Stable in Claude Code and Codex; Cursor, Copilot, Windsurf, OpenCode, Gemini CLI and Antigravity support is in beta. The process produces many documents and spends tokens on reviews and subagents.

How to disable. Delete the kiro-* skill folders from the agent's skills directory in the project.

Security check

• Autonomous implementation writes code and runs tests in the project

README in short

The README explains the approach: the spec is a contract between parts of the system while code stays the source of truth. Version 3.0 is rebuilt around Agent Skills with kiro-discovery, kiro-impl, kiro-spec-batch and boundary-first design.md. Installation is one npx command with agent and language flags, plus a table of common workflows and a migration guide. MIT licensed.

SKILL.md

---
name: kiro-discovery
description: Entry point for new work. Determines the best action path or work decomposition (update existing spec, create new spec, mixed decomposition, or no spec needed) and refines ideas through structured dialogue.
disable-model-invocation: true
allowed-tools: Read, Write, Glob, Grep, Agent, WebSearch, WebFetch, AskUserQuestion
argument-hint: <idea-or-request>
---

# kiro-discovery Skill

## Core Mission
- **Success Criteria**:
  - Correct action path or work decomposition identified based on existing project state
  - User's intent clarified through questions, not assumptions
  - Output is an actionable next step (not just a description)

## Execution Steps

### Step 1: Lightweight Scan

Gather **only metadata** to determine the action path. Do NOT read full file contents yet.

- **Specs inventory**: Glob `{{KIRO_DIR}}/specs/*/spec.json`, read each spec.json for `name`, `phase` fields and `approvals` status. Note feature names and their current status.
- **Steering existence**: Check which files exist in `{{KIRO_DIR}}/steering/` (product.md, tech.md, structure.md, roadmap.md). Do NOT read their contents yet.
- **Roadmap check**: If `{{KIRO_DIR}}/steering/roadmap.md` exists, read it. This contains project-level context (approach, scope, constraints, spec list) from a previous discovery session. Use it to restore project context.
- **Top-level structure**: List the project root directory to note key directories and files. Do NOT recurse into subdirectories.

This step should consume minimal context. If `specs/` is empty and no steering exists, note "greenfield project" and move to Step 2.

### 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

Related