Skill 3: SDD-Sanitize-Specs
What SDD-Sanitize-Specs Does
SDD-Sanitize-Specs removes everything in the specs tree that would bias code generation toward the original implementation, so the regenerated code is written from the business requirements rather than from a description of the old code. It strips:
- traceability appendices and per-scenario evidence files
- source-basis tags and open-questions files
- stray vFunction identifiers
- leaked file paths, module names, and package names
Along the way it settles ubiquitous-language conflicts and open questions wherever the evidence in the specs allows, and reports what it could not settle.
Have domain experts settle conflicts and open questions.
Resolving ubiquitous-language conflicts and open questions is best done by domain experts and product managers, not by AI agents. If items are left unanswered, the sanitization step will try to settle them itself, for better or worse.
It writes a sanitized copy; your original tree is never modified. It also writes a findings report. Once started, it runs to completion without asking anything, and unresolved items are collected and surfaced at the end.
Change directories are sorted rather than uniformly stripped:
| Directory | Fate | Why |
|---|---|---|
changes/pending/ |
Kept, sanitized | Not yet in the baseline; applied to generated code later |
changes/spent/ |
Dropped | Already folded into the baseline, so the code will contain it anyway. Reserved for future use; this directory is currently never created. |
changes/proposed/ |
Kept, sanitized | Suggestions from extraction, still yours to decide on |
changes/establish-baseline/ and anything directly under changes/ |
Kept, sanitized | Ordinary content |
Example prompts
Sanitize the specs in ../specs into ../specs-sanitized
Get these specs ready for codegen: ../specs
Sanitize ../specs (the original codebase is at ./src if you need a tie-breaker)
As in the earlier steps, Kiro users should use a sub-directory inside the project for the specs and the sanitized output.
What You Get
../specs-sanitized/ # the de-biased tree, ready for Skill 4: sdd-codegen
../specs-sanitized-report.md # the findings report
Before Moving On
Read the report, in particular:
- Unresolved ubiquitous-language conflicts and unresolved open questions. These still need your decision. Otherwise code generation will settle them by accident.
- Pending Fixes Carried Forward. This decides what you actually get. Code generated from this tree implements the architecture without those fixes; each fix is then applied to the generated code in Step 5. Folding fixes directly into the baseline specs is planned as a future extension of
sdd-fix-architecture.
Next SDD Pipeline Skill
The next SDD Pipeline Skill is: