// Analyze the downstream impact of changed requirements, design docs, code, or tests in a CoDD project. Use when the user needs to decide which CoDD artifacts should be updated next, whether autonomous propagation is allowed, or whether a human approval gate is required.
Assemble generated CoDD sprint fragments into a complete, buildable project. Use after all `codd implement` sprints have produced `src/generated/sprint_N/` fragments and the design documents are ready to be integrated into final project files, entry points, source code, and configuration.
Generate CoDD design documents for a greenfield project one wave at a time. Use after `codd init` and prepared requirements when the user needs requirement-driven design docs, frontmatter validation, graph refresh, and human approval gates between waves.
Initialize CoDD in a project and establish the first scan and validation baseline. Use when a repository does not yet have a `codd/` directory, when importing initial requirements, or when bootstrapping greenfield or brownfield CoDD project structure.
Reverse-propagate source code changes back to affected CoDD design documents. Use after code changes when the user needs to map changed source files to modules, identify impacted design docs, and optionally update those docs while preserving CoDD coherence.
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.
Refresh a CoDD project's dependency graph from document frontmatter and source code. Use after changes to requirements, design docs, implementation, or tests when the user needs current graph data, frontmatter coverage, node and edge counts, or warnings before validation or impact analysis.
| name | codd-impact |
| description | Analyze the downstream impact of changed requirements, design docs, code, or tests in a CoDD project. Use when the user needs to decide which CoDD artifacts should be updated next, whether autonomous propagation is allowed, or whether a human approval gate is required. |
Use this skill after a requirements, design, code, or test change to determine what CoDD artifacts must be updated next. The goal is not only to read the impact report, but to decide whether the AI should update design documents immediately, ask a human for approval, or only report informational findings. Treat the impact report as an action queue for keeping requirements, design, implementation, and tests coherent.
Run impact analysis from the project root:
codd impact --path .
By default, this detects uncommitted changes (compares working tree to HEAD). No need to commit first.
If you need a report file:
codd impact --path . --output "codd/reports/impact_$(date +%Y%m%d_%H%M%S).md"
If you need to compare against a specific commit instead of uncommitted changes:
codd impact --diff <commit-hash> --path .
codd/codd.yaml exists.codd/scan/ directory exists (contains nodes.jsonl and edges.jsonl).codd/scan/ is missing or empty, run:codd scan --path .
codd impact --path ..Convention Alerts have higher priority than Green, Amber, or Gray items. They mean an implicit rule may have been violated.
When a Convention Alert appears:
codd/annotations/conventions.yaml.conventions.yaml.Green Band means the impact is high-confidence and the AI may update affected design documents autonomously.
Action:
codd scan --path . to rebuild the graph after the document update.codd impact --path . to confirm the remaining impact set is reduced or reclassified.Use Green Band for autonomous propagation. Do not wait for human approval unless the change introduces a product decision that is not already justified in the source requirements or governance docs.
Amber Band means the impact is plausible but requires human confirmation before the AI edits the affected document.
Ask the human with this template:
{設計書名}が影響を受けています。更新しますか？（変更内容: {変更サマリ}）
Action:
codd scan --path ., then re-run codd impact --path ..Gray Band is informational only. Report it, but do not edit anything unless the human explicitly asks you to.
Use this message template:
{設計書名}への間接的な影響が検出されましたが、対応不要と判断します
Gray items should still be mentioned in the final status so the human knows they were reviewed.
When Green Band allows autonomous updates, or Amber Band gets approved, update affected design documents with this procedure:
depends_onconventionsdata_dependenciescodd scan --path ..codd impact --path . again.When presenting the result, organize it as:
Always name the exact design documents you changed. If nothing needed an edit, say so explicitly.
The dependency graph has not been built yet or was deleted. Run:
codd scan --path .
Then run:
codd impact --path .
No changes detectedYour diff target may not match the change you intend to analyze. Re-run impact with an explicit commit hash:
codd impact --diff <commit-hash> --path .
Choose the commit by checking recent history with git log --oneline.