feat: demote context startup priority

- cap contexts to 10 per account - align MCP and onboarding context guidance - keep contexts optional unless obviously relevant
2026-04-13 12:18:47 +10:00
parent 96c72fc908
commit 5dcb2b7df6
15 changed files with 150 additions and 41 deletions
@@ -10,7 +10,7 @@ description: "Use for graph read, write, connect, classify, or traverse operatio
 1. Search before create to avoid duplicates.
 2. Always try to include a natural description that clearly says 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 contexts only when they are explicit and helpful. One node gets at most one context. If explicit context is missing on create, leave it empty instead of guessing.
+4. Apply context only when it is an obvious match to one of the user's existing contexts and genuinely helpful. One node gets at most one context. If explicit context is missing on create, leave it empty instead of guessing.
 5. Do not rely on dimensions. Node quality comes from title, description, source, metadata, and strong edges.
 5. Create edges when relationships are meaningful; edge explanations should read as a sentence.
 6. For user-authored ideas, notes, or dictated thoughts, preserve the user's wording in `source` as fully as possible with only minimal cleanup.
@@ -22,7 +22,7 @@ description: "Use for graph read, write, connect, classify, or traverse operatio
 - `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 idea capture from chat, the `source` should usually be the raw user thought, not a compressed assistant summary.
 - `link`: external source URL only.
- `context_id`: the node's primary context. Prefer setting it when the scope is explicit. Leave it null rather than guessing.
+- `context_id`: the node's primary context. Prefer setting it only when it is an obvious existing match. Leave it null rather than guessing.
 - `metadata`: use the canonical node metadata contract when metadata is needed:
  - `type`
  - `state` (`processed` or `not_processed`)
@@ -7,7 +7,7 @@ description: "Use for new-user setup, empty or near-empty graphs, or major reset

 ## Your Job

-Three things: help the user understand the basic structure of the system, help them start building useful context in it, and bootstrap the context capsule when durable cross-session facts become clear.
+Three things: help the user understand the basic structure of the system, help them start building useful graph data in it, and bootstrap the context capsule when durable cross-session facts become clear.

 Adapt to the user.

@@ -67,7 +67,7 @@ Explain the structure in simple terms:

 Then say:

-> "If you know specifically how you'd like to create your context corpus, feel free to tell me what you'd like to add and I can help you set things up. Otherwise, I can guide you through bootstrapping your context with a few suggested prompts."
+> "If you know specifically what you'd like to add, tell me and I can help you capture it. Otherwise, I can guide you through bootstrapping the graph with a few suggested prompts."

 Also explain one practical thing early:

@@ -101,7 +101,7 @@ Keep it conversational. Use these buckets and adapt based on what the user gives
 Work these in naturally when they are relevant:

 - **First node creation** — explain that a node is one concrete thing worth keeping: a project, source, person, belief, decision, or idea.
- **Contexts** — explain that contexts are the primary folders or scopes for the graph.
+- **Contexts** — explain that contexts are optional helpers, not required setup. If the user has none, that is fine.
 - **MCP connection** — if the user mentions Claude Code or external agents, offer a quick setup path and point them to the MCP docs/skill flow rather than reciting a giant config block immediately.
 - **What to do after setup** — once the graph has a few solid nodes, the next useful move is usually one of:
  - connect related nodes with explicit edges
@@ -113,7 +113,7 @@ Work these in naturally when they are relevant:
 Do your best to build the graph as useful context emerges.

 - Add nodes when the user mentions concrete things worth keeping.
- Assign a primary context when one is clear. Prefer leaving context empty over low-confidence guessing.
+- Assign a context only when it is an obvious match to one of the user's existing contexts. Prefer leaving context empty over low-confidence guessing.
 - Add edges when relationships are clear enough to explain well.
 - Explain what you're adding in plain language so the user understands the structure as it develops.

@@ -125,7 +125,7 @@ Before writing anything, call `readSkill('db-operations')` for full quality stan

 - Search before creating — avoid duplicates from day one
 - Every description must be concrete: what it IS and why it matters to them, not what it "explores" or "discusses"
- Contexts should hold the primary scope when clear, otherwise leave them empty
+- Contexts are optional and should only be used for an obvious existing match; otherwise leave them empty
 - Every edge needs an explicit explanation sentence

 ## Propose Before Writing