Урок 2.16. cc-sdd

Зачем это нужно

cc-sdd полезен как пример минимального, adaptable SDD harness для разных coding agents. Он Kiro-inspired, но не привязан к Kiro IDE. Его идея:

Возьмем понятный workflow requirements -> design -> tasks -> implementation
и установим его как Agent Skills / commands для разных agents.

Для курса это важно по двум причинам.

Во-первых, cc-sdd показывает portability: один spec workflow можно перенести между Claude Code, Codex, Cursor, Copilot, Windsurf, OpenCode, Gemini CLI and Antigravity.

Во-вторых, он делает акцент на boundary-first SDD. Specification важна не как "большой документ", а как contract of responsibility.

Основная идея

cc-sdd рассматривает spec как delivery and revalidation unit.

Хороший spec должен отвечать:

Что эта часть системы owns?
Что она явно не owns?
Какие dependencies allowed?
Какие contracts должны остаться stable?
Что нужно revalidate, если spec изменится?

Это называется boundary-first thinking.

Без boundary-first подхода specs становятся просто длинными documents. С boundary-first подходом specs помогают нескольким agents or developers работать независимо, не ломая architecture.

Ключевые термины

Как это устроено

Главная сила cc-sdd - routing. Он не заставляет каждую просьбу становиться большим spec. Discovery выбирает правильный path.

Quick start

На обзорном уровне:

cd your-project
npx cc-sdd@latest

Для выбора agent/language используются flags, например:

npx cc-sdd@latest --codex-skills

После установки entry point:

/kiro-discovery <idea>

Command syntax зависит от install mode and agent harness. Важно, что skills mode делает spec workflow доступным across agents.

Основной workflow

Для новой feature:

/kiro-discovery
-> /kiro-spec-init
-> /kiro-spec-requirements
-> /kiro-spec-design
-> /kiro-spec-tasks
-> /kiro-impl

Для existing system:

/kiro:steering
-> /kiro-discovery
-> optional /kiro:validate-gap
-> /kiro-spec-design
-> /kiro-spec-tasks
-> /kiro-impl

Для large initiative:

/kiro-discovery
-> /kiro-spec-batch

Artifacts

Typical Kiro-style artifacts:

.kiro/
  steering/
    *.md
  specs/
    <feature>/
      brief.md
      roadmap.md
      requirements.md
      research.md
      design.md
      tasks.md
      gap-report.md
      design-validation.md

Не каждый file появляется всегда. Например, research.md, gap-report.md or roadmap.md нужны только в соответствующих flows.

/kiro-discovery

Discovery - это router, а не auto-runner.

Он должен решить:

Это полезно, потому что не вся работа должна проходить одинаковый heavy process.

/kiro-impl

/kiro-impl отвечает за implementation approved tasks.

В skills mode он может работать:

• autonomous mode: по task, с fresh implementer, independent reviewer and bounded remediation;
• manual mode: TDD в main context for specified tasks.

Для курса важны три правила:

1. One task per iteration.
2. TDD and review are part of implementation.
3. Re-run should be safe after interruption.

Пример: user roles

Задача:

Добавить роли Owner, Admin, Member в Task Manager.

Prompt:

Use cc-sdd.
Start with `/kiro-discovery`.

Goal:
Add Owner, Admin, and Member roles.

Important:
- Existing project membership behavior must not break.
- Permissions must be explicit.
- API changes require OpenAPI update.
- Tests must cover forbidden actions.

Do not implement until requirements, design, and tasks are approved.

Discovery может решить, что это single spec или mixed decomposition:

• update existing membership spec;
• add permissions spec;
• direct migration task.

Good spec boundaries:

Owns:
- role model
- permission checks for project actions

Does not own:
- billing
- authentication provider
- organization-level RBAC

Dependencies:
- existing user model
- project membership table
- API error format

Когда cc-sdd полезен

cc-sdd хорошо подходит, когда:

• нужна portable Kiro-style SDD;
• команда использует разные coding agents;
• нужна boundary-first discipline;
• есть existing Kiro specs;
• нужно long-running implementation with per-task review;
• large initiative нужно разбить на multiple specs;
• хочется minimal adaptable harness without full BMAD overhead.

Когда не стоит брать

cc-sdd может быть лишним, если:

• задача не требует spec;
• команда не готова approve requirements/design/tasks;
• architecture boundaries неясны;
• tests/build/lint не работают;
• нужен product discovery на уровне PRD;
• нужен OS-like ledger/runtime.

Важная мысль из cc-sdd philosophy:

Specs do not fix bad architecture.
They only make architecture operational.

Если ownership and dependencies в system хаотичны, spec workflow сначала выявит проблему, а не магически исправит ее.

Риски

Prompt patterns

Discovery

Use cc-sdd.
Start with `/kiro-discovery`.
Route this request into the smallest appropriate workflow:
existing spec, no spec, single spec, multi-spec, or mixed.
Stop after routing and artifact creation.

Requirements

Create requirements for this spec.
Make boundaries explicit:
- owns
- does not own
- allowed dependencies
- downstream revalidation triggers

Implementation

Run `/kiro-impl` only for approved tasks.
Use one-task-per-iteration.
For each task:
- write failing test first
- implement minimal code
- run verification
- perform independent review
- update tasks.md with implementation notes

Практика

Возьмите feature и опишите boundaries:

Feature:
Owns:
Does not own:
Allowed dependencies:
Forbidden dependencies:
Contracts:
Revalidation triggers:
Verification:

Затем решите, какой discovery outcome правильный: no spec, single spec, multi-spec or mixed.

Критерии готовности

После урока студент должен уметь:

• объяснить cc-sdd как minimal adaptable SDD harness;
• описать Kiro-style workflow;
• понять роль /kiro-discovery;
• сформулировать boundary-first spec;
• объяснить /kiro-impl на уровне process;
• понять, когда specs требуют architecture cleanup.

Краткое резюме

cc-sdd показывает практичный путь: взять requirements/design/tasks workflow и сделать его portable через Agent Skills для разных coding agents. Его главная ценность - boundary-first discipline and long-running implementation harness. Его главный риск - считать specs заменой architecture.

Вопросы для самопроверки

1. Что означает boundary-first SDD?
2. Почему discovery должен быть router, а не auto-runner?
3. Какие outcomes может дать /kiro-discovery?
4. Чем /kiro-impl отличается от обычного "implement tasks"?
5. Почему specs не исправляют плохую architecture?

Источники для актуализации

• cc-sdd repository: https://github.com/gotalab/cc-sdd
• cc-sdd Spec-Driven Development guide: https://github.com/gotalab/cc-sdd/blob/main/docs/guides/spec-driven.md

Что дальше

На этом серия top-10 SDD toolkits завершает модульный обзор инструментов. Дальше эти подходы будут постоянно возвращаться в курсе как практические building blocks: specs, tasks, tests, Git safety, hooks, guardrails, logs, evals and multi-agent review.