cc-sdd is a spec-driven development workflow for coding agents: it turns approved software specifications into requirements, designs, task plans, and extended autonomous implementation. Developers use it across several AI coding agents, with independent review and task-level continuation for long-running work. The catalogue entries provide commands, skills, agents, and instructions for using this workflow.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add gotalab/cc-sdd --skill kiro-validate-implgit clone --depth 1 https://github.com/gotalab/cc-sddWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/gotalab/cc-sdd/kiro-validate-impl)<a href="https://agentmods.dev/skills/gotalab/cc-sdd/kiro-validate-impl"><img src="https://agentmods.dev/badge/skills/gotalab/cc-sdd/kiro-validate-impl/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/gotalab/cc-sdd/kiro-validate-impl"><img src="https://agentmods.dev/badge/skills/gotalab/cc-sdd/kiro-validate-impl.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00031 | $0.02575 |
| Opus 5.5 | $0.00012 | $0.01030 |
| Sonnet 5.5 | $0.00006 | $0.00515 |
| Haiku 4.5 | $0.00003 | $0.00258 |
Grade A, and why
kiro-validate-impl scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- kiro-validate-impl — 88% identical, 27 lines differ
How it starts
The opening of the file, as written. The whole thing — 209 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementation Integration Validation
<background_information> Individual tasks are usually reviewed during implementation. Your job is to catch problems that only become visible when looking across all tasks together.
Boundary terminology continuity:
-
discovery identifies
Boundary Candidates -
design fixes
Boundary Commitments -
tasks constrain execution with
_Boundary:_ -
feature validation checks for cross-task
Boundary Violations -
Success Criteria:
- All tasks marked
[x]in tasks.md - Full test suite passes (not just per-task tests)
- Cross-task integration works (data flows between components, interfaces match)
- Requirements coverage is complete across all tasks (no gaps between tasks)
- Design structure is reflected end-to-end (not just per-component)
- No orphaned code, conflicting implementations, integration seams, or boundary spillover
- All tasks marked
What This Skill Does NOT Do: This skill is not a full replacement for task-local review during /kiro-impl. This skill does NOT re-check every individual task acceptance criterion, every per-file reality check, or every single-task spec detail unless a concrete integration finding forces it.
This skill's main question is: when the completed tasks are viewed together, do they still respect the designed boundary seams and dependency direction? </background_information>
1. Detect Validation Target
If no arguments provided ($1 empty):
- Parse conversation history for
/kiro-impl <feature> [tasks]commands - Extract feature names and task numbers from each execution
- Aggregate all implemented tasks by feature
- Report detected implementations (e.g., "user-auth: 1.1, 1.2, 1.3")
- If no history found, scan
{{KIRO_DIR}}/specs/for features with completed tasks[x]
If feature provided ($1 present, $2 empty):
- Use specified feature
- Detect all completed tasks
[x]in{{KIRO_DIR}}/specs/$1/tasks.md
If both feature and tasks provided ($1 and $2 present):
- Validate specified feature and tasks only (e.g.,
user-auth 1.1,1.2)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed · +1 lines ac0906366ec6
- 1mo ago First seen · 208 lines · 31 tokens per session scan A 12070728b650
kiro-validate-impl is a skill published in the GitHub repository gotalab/cc-sdd (3,745 stars, last pushed 6d ago), licensed MIT. It adds 31 tokens to every session and 2,575 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ai-feature-eval-harness
Design an eval plan for a product AI feature: success criteria, a held-out labeled dataset, per-criterion grading (code-based, then LLM-based), and a pass threshold. Use when a task ships or changes a feature with non-deterministic model output (classification, extraction, summarization, ranking, agent action) needing…
api-runtime-verify
Verify a built backend HTTP surface at runtime: per route, record the response, assert it against the slice's acceptance behavior, and decide PASS/FAIL/BLOCKED. Do not use to review a contract before implementation (use api-contract-review or graphql-contract-review), write code (use implement-approved-slice), triage…
app-runtime-verify
Verify a mobile or app runtime: run the app (device, emulator, or headless), read captured output (logcat, iOS device log, or Metro/JS console), classify errors per stack, and decide a PASS/FAIL gate. Adapters: React Native/Expo, Unity mobile. Do not use to plan a screen (use implementation-plan), to write or fix code…
post-deploy-verifier
Per-slice post-deploy verification plan: acceptance criteria mapped to live signals, plus rollback triggers. Activates after a deploy with no plan, when branch-commit made a deploy without checks, or when slice-closure would close a slice without one. Do not use before the slice ships (use verify-against-rubric), for…
test-strategy
Define the smallest set of meaningful tests that protects behavior and reduces the regression risk for the active task, persisted as TESTSTRATEGY.md. Use when a change affects behavior, contracts, data flow or regression risk, or auth, biometric or runtime-risk scope lacks one, even if small. Do not use when the…
web-runtime-verify
Verify a built web frontend at runtime: serve the build, assert page identity, run the web battery (overflow 320 to 2560, keyboard, console, Lighthouse, axe), and decide a PASS/FAIL/BLOCKED gate. Fixes are routed, not applied. Do not use to plan (implementation-plan), write code (implement-approved-slice), for perf…