extract

Extract — Code Pattern Capture

Reads existing implementation and produces a system.md describing how the code is actually built — not how it should be. This is descriptive, not prescriptive.

Output: design/extracted/<system-or-area>.md

---

Purpose / When to Run

Run when:

• A brownfield project has working code but no design docs
• /reverse-document is running and needs the extracted patterns as input
• The team wants a "this is how we currently do it" snapshot before making a change

Distinct from /design-system (which authors a forward-looking PRD) and /architecture-decision (which records a deliberate decision). This skill captures observed reality so a future PRD or ADR can be written against an honest baseline.

Inputs

• Required: a path or glob pointing to the source files to analyze (e.g., src/screens/auth/, lib/features/onboarding/**/*.dart)
• The framework (read from .claude/docs/technical-preferences.md)

Outputs

• design/extracted/<system-name>.md

---

Phase 1: Resolve Scope

If no path was passed, ask:

• Prompt: "Which area of code should I extract patterns from?"
• Options:
  • Screens / pages — src/screens/**, lib/features/**, app/Sources/**/Views/
  • State management — wherever the app's stores / view models live
  • Networking / API client — fetchers, interceptors
  • Navigation — routing config, deep links
  • Specific subdirectory — free text path

Use Glob to confirm the target exists and resolve to a list of files. Cap at ~50 files for one extraction; if more, sample and ask whether to chunk.

Determine the system name from the path (e.g., src/screens/auth/ → auth).

---

Phase 2: Read & Skim

Read each file. For each, classify by role: screen, component, hook/composable, store, service, util, type definition, test.

While reading, build a fact table per file:

• Imports (which dependencies and from where)
• Exported names
• State shape (if a store)
• Side effects (network calls, persistence reads/writes, navigation)
• Error handling pattern