Reverse engineer

/specforge:reverse-engineer — brownfield onboarding

Most real adoption is on existing code, not greenfield. This skill analyzes the current repo and produces a baseline set of artifacts so the team can move forward under the lifecycle. Delegate the heavy analysis to the reverse-engineer subagent to keep the main context clean.

When to use

• Adopting SpecForge on an existing project.
• The user wants an as-built spec/architecture snapshot before making changes.

Preconditions

• A specforge/ workspace exists (run /specforge:init first).

Steps

1. Survey the repo: languages, frameworks, entry points, module boundaries, external dependencies, data stores, and public interfaces (APIs/CLIs/events). Prefer reading manifests (package.json, pyproject, go.mod, etc.) and directory structure over reading every file.
2. Create a baseline feature specforge/specs/000-baseline/ (number 000 marks the as-built snapshot) containing:
   • business-overview.md — what the system does, for whom (inferred; mark guesses).
   • architecture.md — components, data flow, a diagram, key dependencies.
   • code-structure.md — directory map and module responsibilities.
   • api-documentation.md — observed public interfaces / contracts.
   • code-quality-assessment.md — notable risks, tech debt, missing tests.
3. Populate specforge/inputs/tech-environment.md from what you actually observe (language, framework, package manager, test framework, conventions). Flag anything uncertain with [NEEDS CLARIFICATION].
4. Update specforge/state.md (| 000-baseline | reverse-engineer | done | <date> |) and append an audit row.
5. Recommend next steps: review the baseline with the user, then /specforge:specify the first real change on top of the as-built understanding.

Guardrails

• This is a read-only analysis of the codebase — do not modify application code.
• Distinguish observed fact from inference; mark every guess with [NEEDS CLARIFICATION].
• Keep it high-signal: a navigable map beats an exhaustive file dump.