codd-assemble
Assemble generated CoDD sprint fragments into a complete, buildable project. Use after all `codd implement` sprints have produced…
Reconstruct CoDD design documents from extracted code facts for a brownfield project. Use after `codd extract` and wave planning when the user needs to infer requirements or restore system and detailed design from existing source code rather than greenfield requirements.
$ npx -y skills add yohey-w/codd-dev --skill codd-restore --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/codd-restoreContext preview
The summary Claude sees to decide when to auto-load this skill.
Reconstruct CoDD design documents from extracted code facts for a brownfield project. Use after `codd extract` and wave planning when the user needs to infer requirements or restore system and detailed design from existing source code rather than greenfield requirements.
name: codd-restore description: | Reconstruct CoDD design documents from extracted code facts for a brownfield project. Use after `codd extract` and wave planning when the user needs to infer requirements or restore system and detailed design from existing source code rather than greenfield requirements.
Reconstruct design documents from extracted code facts for brownfield projects. Unlike `/codd-generate` (which creates docs from requirements), `/codd-restore` asks "what IS the current design?" — reconstructing intent from code structure.
Do NOT use this for greenfield projects with requirements — use `/codd-generate` instead.
codd extract # Step 1: Static analysis → codd/extracted/ codd plan --init # Step 2: Extracted docs → wave_config (auto-detects brownfield) codd restore --wave 0 # Step 3a: Infer requirements from code facts codd restore --wave 2 # Step 3b: Reconstruct system design codd restore --wave 3 # Step 3c: Reconstruct detailed design codd scan --path . # Step 4: Build dependency graph
When restoring a document under `docs/requirements/`, the restore command switches to **requirements inference mode**:
**Important limitations** (the prompt explicitly warns the AI about these):
These are **inferred requirements** — describing what was built, not original intent. Human review is essential.
Before every restore run, verify:
1. `codd/codd.yaml` exists with `wave_config`. 2. `codd/extracted/` contains extracted docs (run `codd extract` first if missing). 3. For Wave 2+, verify that earlier waves have been restored or exist already. 4. Confirm you are in the intended project root.
If any prerequisite fails, stop and resolve it.
Follow this loop for each wave:
1. Restore the target wave:
codd restore --wave 0 --path .
Replace `0` with the current wave number.
2. Read every restored document and confirm:
3. Validate frontmatter and dependency references:
codd validate --path .
4. Refresh the dependency graph:
codd scan --path .
5. Pause for HITL confirmation before the next wave:
Human review is mandatory between waves. Restored documents describe "what IS" but may misinterpret intent. Do not proceed automatically.
If the human rejects a wave, revise with `--force`, re-validate, and request approval again.
| Situation | Command | |-----------|---------| | Have requirements, no code | `/codd-generate` | | Have code, no requirements | `/codd-restore` | | Have both | `/codd-generate` (requirements take precedence) | | Want to infer requirements from code | `codd restore --wave 0` (requirements inference) |
CoDD: Coherence-Driven Development — Claude Code plugin for cross-artifact change impact analysis
Assemble generated CoDD sprint fragments into a complete, buildable project. Use after all `codd implement` sprints have produced…
Conversationally evolve an existing CoDD project. Use when the user describes a functional change in natural language ("add…
Consult Claude Fable 5 (Anthropic's most capable model for deep, long-horizon reasoning — or whichever model currently holds that…
Generate CoDD design documents for a greenfield project one wave at a time. Use after `codd init` and prepared requirements when…
Run the CoDD greenfield autopilot: a requirements document in, a working system out, unattended. Use when the user wants to build…
Analyze the downstream impact of changed requirements, design docs, code, or tests in a CoDD project. Use when the user needs to…