feat: port contexts layer and MCP parity

apps/mcp-server-standalone/skills/audit.md

@@ -1,9 +1,6 @@
 ---
 name: Audit
-description: "Run a structured audit of graph quality, skill quality, and operational consistency."
-when_to_use: "User asks for review, QA, cleanup, or governance checks."
-when_not_to_use: "Simple one-off write/read requests."
-success_criteria: "Findings are prioritized, concrete, and tied to actionable fixes."
+description: "Use for structured review, QA, cleanup, or governance checks across graph quality, skill quality, and operational consistency."
 ---
 
 # Audit
@@ -27,3 +24,5 @@ success_criteria: "Findings are prioritized, concrete, and tied to actionable fi
 - Prefer specific evidence over generic commentary.
 - Propose the smallest high-leverage fixes first.
 - Separate defects from optional polish.
+- Node descriptions must read like natural prose while still making what / why / status clear.
+- Flag any node description missing a clear why or status component as a high-priority quality issue.

apps/mcp-server-standalone/skills/calibration.md

@@ -3,7 +3,7 @@ name: Calibration
 description: "Run periodic check-ins to recalibrate goals, projects, preferences, and graph structure."
 when_to_use: "User asks for a check-in, reset, review, or strategic recalibration."
 when_not_to_use: "Single isolated question with no strategic update needed."
-success_criteria: "Graph reflects current reality: updated hubs, changed priorities, and explicit deltas."
+success_criteria: "Graph reflects current reality: updated contexts, changed priorities, and explicit deltas."
 ---
 
 # Calibration
@@ -14,7 +14,7 @@ Re-anchor the graph to the user's current state.
 
 ## Check-in Sequence
 
-1. Review major hub nodes and active project nodes.
+1. Review major contexts, anchor nodes, and active project nodes.
 2. Ask what changed: goals, priorities, constraints, beliefs, preferences.
 3. Identify stale nodes and missing nodes.
 4. Propose precise updates: update existing vs create new.

apps/mcp-server-standalone/skills/db-operations.md

@@ -1,9 +1,6 @@
 ---
 name: DB Operations
 description: "Use this for all graph read/write operations with strict data quality standards."
-when_to_use: "Any request to read, create, update, connect, classify, or traverse graph data."
-when_not_to_use: "Pure conversation with no graph interaction needed."
-success_criteria: "Writes are explicit and correct; descriptions are concrete; edges and dimensions are high-signal."
 ---
 
 # DB Operations
@@ -11,7 +8,7 @@ success_criteria: "Writes are explicit and correct; descriptions are concrete; e
 ## Core Rules
 
 1. Search before create to avoid duplicates.
-2. Every create/update must include an explicit description of WHAT the thing is and WHY it matters.
+2. Every create/update should aim for a natural description that makes clear what the thing is and any surrounding context available, but description quality is guidance only. RA-H should never block or rewrite a write because of description quality.
 3. Use event dates when known (when it happened, not when saved).
 4. Apply dimensions deliberately; prefer existing dimensions over creating noisy new ones.
 5. Create edges when relationships are meaningful; edge explanations should read as a sentence.
@@ -19,9 +16,10 @@ success_criteria: "Writes are explicit and correct; descriptions are concrete; e
 ## Write Quality Contract
 
 - `title`: clear and specific.
-- `description`: concrete object-level description, not vague summaries.
-- `notes/content`: extra context, analysis, supporting detail.
+- `description`: natural prose, not labels. It should still make what / why / status clear when possible.
+- `source`: full verbatim or canonical content of the node (transcript, article text, book passage, user's thoughts). This is what gets chunked and embedded for semantic search. For user-authored ideas or dictated notes, preserve the user's original wording with minimal cleanup.
 - `link`: external source URL only.
+- `metadata`: prefer canonical keys `type`, `state`, `captured_method`, `captured_by`, and `source_metadata`.
 
 ## Execution Pattern
 
@@ -29,9 +27,11 @@ success_criteria: "Writes are explicit and correct; descriptions are concrete; e
 2. Decide: create vs update vs connect.
 3. Execute minimum required writes.
 4. Verify result reflects user intent exactly.
+5. If description framing was materially inferred, complete the write first and then invite one concise user feedback pass instead of blocking creation.
 
 ## Do Not
 
 - Create duplicate nodes when an update is correct.
 - Write vague descriptions ("discusses", "explores", "is about").
+- Replace a user's raw idea/source with a thin summary.
 - Create weak or directionless edges.

apps/mcp-server-standalone/skills/node-context-enrichment.md

@@ -0,0 +1,36 @@
+---
+name: Node Context Enrichment
+description: "Use to rewrite thin node descriptions into natural prose that still makes what, why, and status clear, with dimension review and edge suggestions."
+---
+
+# Node Context Enrichment
+
+Use this when a node already exists but its description is thin, generic, or missing personal context.
+
+This skill should not silently rewrite and move on when contextual framing is inferred. If the enrichment depends on interpretation, update the node and then explicitly invite the user to correct or refine the contextual framing.
+
+## Goal
+
+Replace weak descriptions with a single clean natural description that captures:
+
+1. What the artifact literally is
+2. Why it is in Brad's graph
+3. Status in Brad's workflow
+
+Also review whether the node needs dimension fixes or obvious edge suggestions.
+
+## Workflow
+
+1. Load the node and inspect title, description, source, link, metadata, dimensions, and nearby edges.
+2. Search for adjacent context before rewriting.
+3. Infer the best available "why" from that context.
+4. Rewrite the full description from scratch in natural prose. Do not append to the old text or use labels like WHAT:, WHY:, or STATUS:.
+5. Review dimensions.
+6. Suggest 1-3 high-signal edges when obvious.
+7. Update the node once the description is strong enough to be useful.
+8. After the update, tell the user what changed and ask whether they want to refine the important framing:
+   - what it is
+   - why it belongs in the graph
+   - status / current relevance / workflow position
+
+The user feedback pass is required whenever the enriched "why" or status was inferred rather than directly stated in the node/source.

apps/mcp-server-standalone/skills/onboarding.md

@@ -3,7 +3,7 @@ name: Onboarding
 description: "Onboard a new user by mapping goals, projects, worldview, and preferences into a strong initial graph."
 when_to_use: "New user setup or major reset of account context."
 when_not_to_use: "User asks for a narrow tactical operation only."
-success_criteria: "User has an initial hub-node structure and clear next steps for graph growth."
+success_criteria: "User has an initial context structure, anchor candidates, and clear next steps for graph growth."
 ---
 
 # Onboarding
@@ -22,13 +22,14 @@ Understand the user deeply enough to bootstrap a useful externalized context gra
 
 ## Graph Bootstrap
 
-1. Propose 3-6 hub nodes with clear rationale.
-2. Propose starter dimensions that reflect real domains.
-3. Create initial edges between hubs and active projects.
-4. Confirm with user before writing.
+1. Propose 3-6 primary contexts with clear rationale.
+2. Identify one strong anchor candidate per context.
+3. Propose starter dimensions as secondary metadata and filters.
+4. Create initial edges between anchor nodes and active project nodes.
+5. Confirm with user before writing.
 
 ## Output
 
-- Initial hub map
+- Initial context map
 - Suggested first write actions
 - Suggested weekly maintenance rhythm