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