domain-extract

name	domain-extract
description	Extract domain knowledge from existing project sources and generate domain rules. Also handles vault sync and domain listing.
context	fork

Domain Extract

Analyze existing project sources to propose domain knowledge rules for approval.

Dispatch

Based on $ARGUMENTS after "domain":

• domain extract → Step 1-5 (full extraction)
• domain list → Step 6 (list only)
• domain sync-vault → Step 7 (vault sync only)

---

Step 1: Gather sources

Read these project sources (skip any that don't exist):

1. CLAUDE.md — sections below <!-- forge:custom --> (user-written content)
2. Auto-memory — resolve the project's memory directory:
   • Compute project path hash: the memory lives in ~/.claude/projects/-<path-with-dashes>/memory/
   • Read MEMORY.md index, then read each linked memory file
   • Filter: keep only entries with business/domain content (not purely technical)
3. CLAUDE_ERRORS.md — read all entries. Flag errors where the root cause is "Claude didn't know X about the business"
4. Agent memory — read .claude/agent-memory/implementer/*.md and .claude/agent-memory/architect/*.md
   • Filter: keep domain-relevant learnings (business logic, API behavior, deployment procedures)
5. Existing rules — read all .claude/rules/*.md. Identify files that mix domain + technical content
6. Git log — run git log --oneline -50 to identify domain-related commits (keywords: fix, deploy, API, auth, config)

Step 2: Classify findings

For each piece of domain knowledge found, classify:

• Category: deploy, api-integration, business-logic, data-model, auth-flow, external-service, workflow
• Source: which file(s) it came from
• Confidence: high (explicit in CLAUDE.md/rules), medium (in memory/errors), low (inferred from git)
• Overlap: does it duplicate existing .claude/rules/domain/*.md content?

Discard:

• Pure technical patterns (import order, test fixtures, lint rules)
• Already covered by existing domain rules
• One-time fixes that won't recur

Step 3: Generate proposals

Group findings by category. For each group, propose a domain rule file:

═══ DOMAIN EXTRACT ═══
Project: {{project_name}}
Sources analyzed: {{count}}
Existing domain rules: {{count in .claude/rules/domain/}}

── PROPOSED DOMAIN RULES ──

{{number}}. {{filename}}.md (from: {{sources}})
   globs: {{suggested glob patterns}}
   Content preview:
     "{{3-5 line summary of what the rule will contain}}"
   → Create? (y/n/edit)

Also propose a Role section if CLAUDE.md doesn't have ## Role yet:

── ROLE SECTION ──
Detected role from project context:
  "{{proposed role description}}"
  → Add to CLAUDE.md ## Role? (y/n/edit)

And a Domain section if CLAUDE.md doesn't have ## Domain yet:

── DOMAIN SECTION ──
Detected domain context:
  "{{proposed domain summary}}"
  → Add to CLAUDE.md ## Domain? (y/n/edit)

Step 4: Wait for user approval

STOP and WAIT for the user to respond to each proposal (y/n/edit).

If the user says "edit", ask what to change and regenerate that specific proposal. If the user says "all", approve all proposals.

Step 5: Create approved files

For each approved domain rule:

1. Create .claude/rules/domain/ directory if not exists
2. Write the file with frontmatter:

   ---
   globs: "{{patterns}}"
   description: "{{one-line description}}"
   domain: {{category}}
   last_verified: {{today YYYY-MM-DD}}
   ---
   

3. Content: imperative mood, concise facts, <40 lines per file
4. All content in English (Claude-consumed content rule)

For approved Role/Domain sections:

1. Read current CLAUDE.md
2. If ## Role marker exists, replace content. If not, add section before ## Arquitectura
3. If ## Domain marker exists, replace content. If not, add section after ## Role

Show summary:

═══ DOMAIN EXTRACT — DONE ═══
Created: {{N}} domain rules in .claude/rules/domain/
Updated: CLAUDE.md (Role: ✓/✗, Domain: ✓/✗)
Total domain knowledge: {{N}} files

---

Step 6: Domain list (for /forge domain list)

List all files in .claude/rules/domain/ with metadata:

═══ DOMAIN RULES ═══
File              Domain    Globs                          Last Verified   Status
─────────────────────────────────────────────────────────────────────────────────
ratios.md         trading   **/*ratio*,**/*price*          2026-03-15      ⚠ stale (>90d)
deploy-vps.md     infra     **/*deploy*,docker-compose*    2026-03-25      ✓ current
jira-api.md       jira      **/*jira*,**/*issue*           2026-03-20      ✓ current

Status rules:

• ✓ current — last_verified within 90 days
• ⚠ stale — last_verified older than 90 days
• ✗ no date — missing last_verified field

If no .claude/rules/domain/ exists: "No domain rules found. Run /forge domain extract to generate from existing sources."

---

Step 7: Vault sync (for /forge domain sync-vault)

For each file in .claude/rules/domain/ that has domain_source: vault://... in frontmatter:

1. Resolve path: replace vault:// with ~/vault/
2. Read the vault note at that path
3. Compare key facts in the vault note vs the domain rule
4. If differences found:

   ══ VAULT SYNC ══
   File: ratios.md
   Source: vault://decisions/ratio-engine.md
   
   Changes detected:
     + New: "ONs use factor 0.001 for sub-peso bonds"
     ~ Changed: exit ratio now uses mid-price, not ask
   
   → Update domain rule? (y/n/edit)
   

5. If approved: update the domain rule content, set last_verified to today
6. If vault note not found: warn and skip

If no files have domain_source: "No vault-linked domain rules found. Add domain_source: vault://path to a domain rule frontmatter to enable sync."

---

Constraints

• NEVER auto-create files without user approval — always show proposals first
• Domain rules go in .claude/rules/domain/, never in .claude/rules/ root
• All generated content must be in English (Claude-consumed)
• Keep each domain rule file under 40 lines
• Frontmatter fields: globs (required), description (required), domain (required), last_verified (required), domain_source (optional)
• If a project has no meaningful domain knowledge in its sources, say so honestly — don't generate empty placeholder files