Brownfield adoption

Most real projects aren’t greenfield. /specforge:reverse-engineer seeds the spec store from an existing codebase so you can adopt the lifecycle without pretending you’re starting over.

Steps

1. /specforge:init — create the specforge/ workspace.

2. /specforge:reverse-engineer — the reverse-engineer subagent analyzes the repo (manifests, structure, entry points, public interfaces) and writes a baseline under specforge/specs/000-baseline/:

   • business-overview.md — what the system does, for whom (inferred; guesses marked).
   • architecture.md — components, data flow, a diagram, key dependencies.
   • code-structure.md — directory map + module responsibilities.
   • api-documentation.md — observed public interfaces / contracts.
   • code-quality-assessment.md — risks, tech debt, missing tests.

   It also fills specforge/inputs/tech-environment.md from what it actually observes.

3. Review the baseline with your team; correct any [NEEDS CLARIFICATION] inferences.

4. /specforge:specify your first real change on top of the as-built understanding, then proceed through the normal lifecycle.

Principles

• Read-only on your code — reverse-engineering never edits application code; it only writes SpecForge artifacts.
• Fact vs inference — everything uncertain is marked [NEEDS CLARIFICATION] so you confirm rather than trust a guess.
• High-signal over exhaustive — the goal is a navigable map, not a dump of every file.

The 000 number marks the as-built snapshot, distinct from the features you add (001, 002, …). Future specs can point back to it, and /specforge:analyze can compare new work against the baseline to surface drift.