architect

Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. ops/derivation-manifest.md — vocabulary mapping, platform hints

   • Use vocabulary.notes for the notes folder name
   • Use vocabulary.note / vocabulary.note_plural for note type references
   • Use vocabulary.topic_map / vocabulary.topic_map_plural for MOC references
   • Use vocabulary.inbox for the inbox folder name
   • Use vocabulary.cmd_reflect for connection-finding command name
   • Use vocabulary.cmd_reweave for backward-pass command name
   • Use vocabulary.cmd_verify for verification command name
   • Use vocabulary.architect for the command name in output

2. ops/config.yaml — processing depth, pipeline chaining, automation settings

3. ops/derivation.md — original derivation record (the design intent baseline)

If these files don't exist, use universal defaults and warn the user.

EXECUTE NOW

Target: $ARGUMENTS

Parse immediately:

• If target names a specific area (e.g., "schema", "processing", "MOC structure"): focus analysis on that area
• If target is empty: run full-system analysis across all dimensions
• If target is --dry-run: run analysis but do not offer implementation

Execute these phases sequentially:

1. Locate system files and detect platform
2. Read derivation record for design intent
3. Analyze health data (recent report or live check)
4. Scan for friction patterns across operational surfaces
5. Consult research to ground evidence in specific claims
6. Generate 3-5 ranked recommendations with full evidence chains
7. Present to user and implement on approval

START NOW. Reference below defines the seven-phase workflow.

Philosophy

Evidence beats intuition. Research beats habit.

Every rule in the context file was a hypothesis. Every skill workflow was a design choice. Hypotheses need testing against operational reality. This skill connects three evidence streams — health data, friction patterns, and research claims — to produce specific, actionable recommendations.

You are not guessing what might help. You are diagnosing what IS happening (health + friction) and prescribing what research says SHOULD happen. Every recommendation traces to specific evidence. "I think this would be better" is not a recommendation. "Health shows 12 orphans, friction log shows repeated orphan complaints, research claim [[orphan notes decay faster than connected ones]] supports adding a condition-triggered reweave pass" — THAT is a recommendation.

The 25% meta-work budget: In a 60-minute session, at most 15 minutes should be spent on system evolution. If a recommendation estimates >15 minutes to implement, the recommendation should be "defer to next session." The system serves the work, not the other way around.

INVARIANT: Architect NEVER auto-implements. Every recommendation requires explicit user approval before any files are modified. This prevents the cognitive outsourcing failure mode — the human must remain in the judgment loop for system evolution.

PHASE 1: Locate

Automated. No user interaction needed.

Detect the platform and find the system's key files:

Check filesystem:
  .claude/ directory exists         -> platform = "claude-code"
  Neither                           -> platform = "minimal"

Locate these files (paths vary by domain vocabulary):

If ops/derivation.md does not exist: Warn the user: "No derivation record found. Recommendations will be based on current state analysis only, without historical context of design decisions."

If ops/config.yaml does not exist: Warn: "No config file found. Using observed behavior to infer current configuration."

Record all file locations for use in subsequent phases.

PHASE 2: Read Derivation

Read ops/derivation.md to understand the system's original design intent. This is the baseline against which drift is measured.

Extract from derivation:

Also read ops/config.yaml — this is the live operational config that may have drifted from derivation. Compare dimension positions between derivation and config:

For each of the 8 dimensions:
  derivation_value = [from ops/derivation.md]
  config_value = [from ops/config.yaml]
  drifted = derivation_value != config_value

Record any drift for Phase 6. Drift is not inherently bad — it may represent healthy evolution. But UNRECOGNIZED drift creates incoherence.

If a specific focus area was requested ($ARGUMENTS), note which dimensions and failure modes are most relevant to that area and prioritize them in subsequent phases.

PHASE 3: Health Analysis

Check for a recent health report in ops/health/:

# Find health reports from the last 7 days
find ops/health/ -name "*.md" -mtime -7 2>/dev/null | sort -r | head -1

If a recent report exists: Read it fully. Extract every FAIL and WARN item as structured evidence:

For each FAIL/WARN:
  category: [schema | orphan | link | description | stale | moc | boundary | throughput]
  severity: [FAIL | WARN]
  detail: [specific finding — which notes, which fields, which links]
  count: [how many instances]

If no recent report exists: Run a live health assessment. Check each category:

Live check implementation:

# Count total notes
NOTE_COUNT=$(ls -1 {vocabulary.notes}/*.md 2>/dev/null | wc -l | tr -d ' ')

# Find orphans (notes with no incoming links)
for f in {vocabulary.notes}/*.md; do
  NAME=$(basename "$f" .md)
  LINKS=$(grep -rl "\[\[$NAME\]\]" {v