Brownfield workflow
The brownfield adoption process follows four key steps:Diagnose project state
Run
/sdd:onboarding to scan your project and classify it into one of 8 scenarios. The skill generates a comprehensive diagnostic report with a step-by-step action plan.Import existing documentation
Use
/sdd:import to convert external documentation from Jira, OpenAPI, Markdown, Notion, CSV, or Excel into SDD format.Reverse engineer from code
Run
/sdd:reverse-engineer to analyze your codebase and generate complete SDD artifacts including requirements, specifications, test plans, and architecture documentation.Eight project scenarios
The onboarding skill classifies projects into eight distinct scenarios, each with a specific adoption strategy:Greenfield
No code, no docs. Start with the standard pipeline from
/sdd:requirements-engineer.Brownfield bare
Code exists with no documentation or tests. Run
/sdd:reverse-engineer to bootstrap all SDD artifacts from the codebase.SDD drift
SDD artifacts exist but have diverged from the code. Use
/sdd:reconcile to detect and align differences.Partial SDD
Some SDD artifacts exist but the pipeline is incomplete. Resume from the gap in the pipeline.
Brownfield with docs
Code and non-SDD documentation exist. Run
/sdd:import to convert docs, then /sdd:reverse-engineer to fill gaps, then /sdd:reconcile to align.Tests as spec
Good test coverage but poor or missing documentation. Run
/sdd:reverse-engineer with a test-first strategy to extract behavior from tests.Multi-team
Monorepo or microservices with mixed states across modules. Perform per-module assessment with phased adoption.
Fork/migration
Project forked from another codebase. Assess upstream artifacts, then run
/sdd:import or /sdd:reverse-engineer for the delta.Health scoring
The onboarding skill calculates a health score (0-100) representing SDD readiness across seven dimensions:| Dimension | Weight | Criteria |
|---|---|---|
| Requirements coverage | 20 pts | 0=none, 10=informal docs, 20=SDD format |
| Specification coverage | 20 pts | 0=none, 10=partial specs, 20=full spec/ |
| Test coverage | 15 pts | 0=none, 8=some tests, 15=good coverage+plan |
| Architecture documentation | 15 pts | 0=none, 8=README/diagrams, 15=SDD plan/ |
| Traceability | 15 pts | 0=none, 8=partial refs, 15=full chain |
| Code quality signals | 10 pts | 0=none, 5=linter, 10=types+linter+CI |
| Pipeline state | 5 pts | 0=none, 3=partial, 5=complete pipeline-state.json |
Scores of 80-100 indicate SDD compliance with minor gaps only. Scores below 40 require systematic adoption.
Invocation modes
All brownfield skills support multiple invocation modes for different use cases:Confidence and markers
Brownfield skills tag artifacts with markers to indicate their origin and confidence level:| Marker | Meaning | Requires Review |
|---|---|---|
[IMPORTED] | Artifact imported from external documentation | Yes |
[INFERRED] | Artifact derived from code patterns | Yes |
[IMPLICIT-RULE] | Business rule embedded in code without docs | Yes |
[RECONCILED] | Artifact updated during reconciliation | No |
[RETROACTIVE] | Task documenting already-implemented feature | No |
[DEAD-CODE] | Unreachable or unused code detected | Review recommended |
[TECH-DEBT] | Suboptimal implementation requiring future work | Review recommended |
[WORKAROUND] | Temporary fix or hack | Review recommended |
Next steps
Onboarding skill
Learn how the onboarding skill diagnoses projects and generates adoption plans.
Import skill
Convert external documentation from Jira, OpenAPI, Notion, and more.
Reverse engineer skill
Extract complete SDD artifacts from existing codebases.
Reconcile skill
Detect and resolve drift between specs and code.