retrofit

This is NOT about retroactively spec'ing everything that was ever built. It's about creating enough understanding of the current state AND the project's direction that new feature specs are compatible, informed, and aligned with where the project is headed.

The code tells you what IS. Only the user can tell you what was INTENDED, what's stale, what was abandoned, and where the project is going.

Output: specs/BASELINE.md — a structured snapshot of the project's current state AND future direction that becomes the foundation for all future spec work.

Key insight: Existing projects have TWO layers of context that a code scan alone can't fully capture:

1. What exists — architecture, conventions, tech stack (code can mostly tell you this)
2. Where it's going — vision, goals, roadmap, what's stale, what was abandoned (ONLY the user can tell you this)

The baseline captures both. Without layer 2, feature specs are technically compatible but strategically disconnected.

SCAN for (in priority order):
  1. CLAUDE.md / .claude/ config     — existing agent context
  2. Build log / changelog           — history of what was built and when
  3. README.md                       — project description and setup
  4. Package manifest                — dependencies reveal tech stack
     (package.json, requirements.txt, Cargo.toml, go.mod, etc.)
  5. Source directory structure       — architecture patterns
  6. Database schema / migrations    — data models
  7. API routes / endpoints          — interface contracts
  8. Test files                      — what's tested, what's not
  9. CI/CD config                    — deployment pipeline
  10. Git log (last 30 commits)      — recent development direction

FOR each source found:
  READ and extract relevant information
  NOTE: what's present vs. what's missing

Project Identity:

• What is this project? (name, purpose, one-liner)
• Who is it for?
• What stage is it at? (prototype, MVP, production, etc.)

Tech Stack (derived from dependencies and code):

• Language / runtime
• Frontend framework (if applicable)
• Backend framework (if applicable)
• Database
• Auth approach
• Hosting / deployment
• Key third-party integrations

Architecture (derived from file structure and code patterns):

• Architecture pattern (monolith, microservices, serverless)
• Directory organization
• Key modules and their responsibilities
• Data flow patterns

Data Models (derived from schema files, migrations, or ORM models):

• Entities and their fields
• Relationships
• Current migration state

Existing Features (derived from routes, components, and build log):

• List of implemented features with status (complete, partial, broken)
• Known issues or technical debt (from build log, TODOs, issues)

Conventions (derived from code patterns):

• Naming conventions
• File organization patterns
• Testing patterns
• Error handling patterns

Present findings to user for validation:

RESPOND:
  "I've scanned {project_name}. Here's what I found:

  **Tech Stack**: {summary}
  **Architecture**: {summary}
  **Features**: {count} implemented, {count} partial
  **Data Models**: {count} entities
  **Known Issues**: {count} from build log / TODOs

  Does this match your understanding? Anything I'm missing or got wrong?"

AWAIT: User validation and corrections
INCORPORATE: User's corrections into baseline