User Story

As a tech lead or PM about to greenfield-rewrite an existing application (different language, framework, or architecture), I want a skill that scans the existing codebase + docs and extracts a structured Feature Inventory — so I can hand the catalogue to the rewrite team as the "what we must preserve" specification, instead of reverse-engineering features by spelunking the old codebase one route at a time.

Acceptance Criteria

Skill

• New /extract-features slash command at .claude/skills/extract-features/SKILL.md
• Argument: /extract-features <project-name> (defaults to current managed-project context if cwd is inside workspace/<name>/)
• Walks six discovery axes in parallel:
  • HTTP routes / entry points — Express / Fastify / NestJS / FastAPI / Flask / Django / Rails / Gin / Echo / Axum / etc. Detect via framework signatures.
  • Data models / DB schema — Prisma / TypeORM / Sequelize / SQLAlchemy / Active Record / Drizzle. Detect via schema files + migrations.
  • Async jobs / queue handlers — BullMQ / Celery / Sidekiq / Inngest / SQS handlers / cron job definitions
  • Test names (= user-facing flows) — describe/it strings, def test_* names, RSpec it strings. Test names are the cheapest signal for what the system DOES.
  • UI screens / forms / interactions — React/Vue/Svelte component tree, route definitions in router config, form fields
  • Documented features — README feature lists, docs/features/, CHANGELOG.md "Added" entries
• Uses LSP semantic walks when ENABLE_LSP_TOOL=1; falls back to grep + Read transparently
• Writes to projects/<name>/feature-inventory.md with these sections:
  • Date + scope — when extracted, what subdirs covered, what was skipped (vendored / generated / test fixtures)
  • Consolidated feature matrix (top-level table): Feature / Surface / Status / Source / Notes
  • Per-axis findings — one subsection per discovery axis with the raw enumeration
  • Coverage gaps — what the skill couldn't determine (e.g. business rules that exist only in code logic, integration patterns that aren't surfaced by routes)
  • Recommended next steps — typically: review with the previous owner; write user stories for each feature; identify the smallest-coherent-subset for v1 of the greenfield rewrite
• Persists via the audit-history-like pattern? No — feature inventory is a one-off scan per project, not a recurring audit. Just write the markdown file directly; if re-run, OFFER (default-no) to overwrite

Override semantics

• If a custom-templates/extract-features.md exists in the private repo (per [Feature] Custom templates layer in private repo with override semantics #244's template-override layer), use it as the artefact template. Otherwise use the framework default.

Sibling skills

• CLAUDE.md notes that /extract-features complements /handover — handover produces a high-level project assessment; /extract-features produces the granular feature catalogue suitable for a greenfield-rewrite spec

Tests

• Smoke test on /extract-features against a synthetic codebase fixture covering at least 2 framework signatures (e.g. Express routes + Prisma schema) → produces a valid inventory with both axes populated

Docs

• CLAUDE.md ## Skills reference table gains a row
• docs/getting-started.md or docs/multi-project.md mentions the skill alongside /handover as the greenfield-rewrite path

Design Notes

Why test names are gold. Test names are the cheapest, most accurate signal of what a system DOES — they're written by humans deliberately describing behaviour. Routes describe HTTP shape; models describe data shape; tests describe behaviour. Walking test names surfaces features that routes + models can't (e.g. "user can recover password via email", "admin can bulk-delete users with confirmation").

Why not auto-generate user stories from this. The skill produces an inventory, not a spec. Translating "GET /api/orders" into "As a customer, I want to view my orders" is a human task — the inventory is the input to that translation, not a substitute.

Why not also produce a migration plan. Scope creep. Migration planning involves trade-offs (what to drop, what to redesign, what to keep as-is) that depend on stakeholder priorities, not on what the scanner finds. The skill stops at "here's what exists"; migration planning is downstream.

LSP-aware where possible. Route discovery, model discovery, test-name enumeration all benefit from LSP's documentSymbol queries — faster + more accurate than grep on large codebases. Where LSP isn't enabled, grep fallback works on framework signatures.

Out of Scope

• Quality scoring of the existing code (use /code-review per-PR or /launch-check for that)
• Auto-generated migration plan (downstream of the inventory; stakeholder work, not skill work)
• Automated rewrite of any feature into a new tech stack (way out of scope)
• Per-feature complexity / effort estimation (the skill can list features but not size them — sizing is implementation-strategy work)
• Cross-system / multi-app inventory (the skill scans one project at a time; portfolio-wide aggregation is a separate ticket if needed)

Effort Estimate

TBD — likely 1 day. Framework-signature detection is the bulk of the work; per-axis walkers are mostly pattern matching.