@c4a/context-cli 0.5.41-beta.6 → 0.6.0-alpha.1

package/plugin/skills/skill-compile-draft/references/refresh-and-update.md

@@ -1,71 +0,0 @@
-# Refresh and update
-
-Consult this reference when **any** of the following holds:
-
-- `existing.sections[]` is non-empty (Node already has active knowledge; this is a refresh, not a first compile).
-- `incremental.status` is `unchanged` or `full-context` (non-default incremental signals).
-- `incremental.locator_only_changes[]` is non-empty (locator-only deltas without content changes).
-
-For first compile of a fresh Node with `incremental.status === "changed-only"`, skip this file.
-
-## Incremental status handling
-
-| `incremental.status` | What to do |
-|---|---|
-| `changed-only` (default) | Normal path — main SKILL.md procedure applies as written. |
-| `unchanged` | Emit exactly one `skip` action with a brief reason. Do not iterate snippets. |
-| `full-context` | Draft from the full fallback. **Preserve `unknown_inputs[]` reasons** in any abort/retry explanation so the caller sees why the fallback was needed. |
-
-The CLI may deterministically skip unchanged output or update locator-only evidence before writing. **Do not force rewrites to bypass fingerprint skip** — those skips are part of the protocol, not a problem to route around.
-
-## Locator-only changes
-
-`incremental.locator_only_changes[]` entries always carry `agent_action: "none"` and `handled_by: "compile-close"`. **Do not emit a draft action for those Sections** unless the same Section also appears in `changed_blocks[]` with a real content change.
-
-## Reconciling with `existing.sections[]`
-
-When `existing.sections[]` is non-empty, every `section-N` id you read here is a potential `update` / `supersede` / `deprecate` target. Walk the existing Sections in order and decide:
-
-| Raw evidence vs existing Section | op |
-|---|---|
-| Raw still supports the existing claim unchanged | Emit nothing (or one summarising `skip`) |
-| Raw clarifies or rephrases without changing meaning | `update` — same `section-N` stays active |
-| Raw changes meaning (new spec value, reversed decision) | `supersede` — old flips to `deprecated`; new gets fresh `section-N+k` |
-| Raw removes the supporting evidence | `deprecate` with `reason` |
-
-### `supersede` vs `update` semantics
-
-`supersede` preserves the audit trail so readers see the prior policy — **critical for specs / decisions / principles**. Use `supersede` whenever the new statement *replaces* the old one's content; use `update` only for typo / wording fixes / detail additions that do not change meaning.
-
-`deprecate` is for "old rule removed without replacement". It needs a `reason`.
-
-### `update` / `supersede.new` mechanics
-
-- `update` keeps the same `section-N` id; provide `source_block_ids[]` / `source_refs[]` for changed evidence and omit `content` when the new cited raw should be mirrored. Include `content` only for an intentional reader-surface rewrite. Do not include `kind` unless the kind itself is changing.
-- `supersede.new` is a fresh Section; it needs `kind` plus citation evidence. Omit `content` when cited raw should be mirrored; include `content` only for an intentional reader-surface rewrite. It may carry `summary`, `refers_to_nodes[]`, and `confidence` per the same rules as `add`.
-- `deprecate` only needs `target_section_id` and `reason`. Do not pass `content`, `source_block_ids[]`, or `source_refs[]`.
-
-## Output schema (refresh ops)
-
-```jsonc
-	{
-	  "actions": [
-	    { "op": "update", "target_section_id": "section-3",
-	      "summary": "...",
-	      "refers_to_nodes": null,
-	      "source_block_ids": ["c0d4e5f61728"] },
-	    { "op": "supersede", "target_section_id": "section-5",
-	      "reason": "raw published a new retention value",
-	      "new": { "kind": "spec", "summary": "...",
-	               "refers_to_nodes": ["..."],
-	               "source_block_ids": ["9d1e2f3a4b5c"] } },
-    { "op": "deprecate", "target_section_id": "section-2", "reason": "..." }
-  ]
-}
-```
-
-## How this slots into the main procedure
-
-- **Step 1 — Sanity-check**: when `existing.sections[]` is non-empty, read every `section-N` id and `status` (active vs deprecated) before classifying snippets. When `incremental.status` is `unchanged`, short-circuit with one `skip`.
-- **Step 2 — Classify**: still walk the kind priority chain for each citation-eligible snippet; the reconciliation table above governs which `op` to emit for snippets that map to an existing Section.
-- **Step 5 — Self-verify**: every `update` / `supersede` / `deprecate` targets a known `section-N` from `existing.sections[]`. If not, return here.

package/plugin/skills/skill-compile-draft/references/structural-challenges.md

@@ -1,76 +0,0 @@
-# Structural and ownership challenges
-
-Consult this reference when the cited evidence **cannot be written as a Section under the current align structure**:
-
-- The evidence describes a coherent process that should be its own `action` Node (not a Section here).
-- The evidence implies a missing `depends_on` edge between Nodes.
-- The evidence belongs under a different parent Node.
-- A finalized shared-block split leaves this Node with only secondary, non-citable evidence.
-- A visible `context_only` or secondary-shared block contains facts that need citation, requiring an ownership upgrade.
-
-In these cases, do **not** force the content into a Section. Emit a challenge action instead; the CLI stores it as a workflow payload and compile-close exposes it as debt until an align resolution handles it.
-
-## When to challenge vs. when to skip
-
-| Situation | Action |
-|---|---|
-| Evidence is a repeatable procedure with steps that clearly warrant a sub-Action | `structure_challenge` with `kind: missing_action_node` |
-| Evidence depends on a Node that the current align graph does not link to this Node | `structure_challenge` with `kind: missing_depends_on_edge` |
-| Evidence belongs under a different parent | `structure_challenge` with `kind: wrong_parent` |
-| A finalized shared block split removed all primary evidence from this Node | `structure_challenge` with `kind: wrong_shared_block_split` |
-| The Node should not exist (its evidence belongs elsewhere) | `structure_challenge` with `kind: extra_action_node` |
-| A `context_only` or secondary-shared block holds facts this Node needs to cite | `pending_ownership_challenge` with `requested_role: "shared"` or `"owned"` |
-
-Supported `structure_challenge.kind` values: `missing_action_node`, `extra_action_node`, `wrong_shared_block_split`, `missing_depends_on_edge`, `wrong_parent`.
-
-`pending_ownership_challenge.requested_role` is `owned` (the Node should be sole author) or `shared` (the Node should join an existing owners list).
-
-## Required fields
-
-```jsonc
-{
-  "op": "structure_challenge",
-  "challenge_id": "ch_0001",
-  "kind": "missing_action_node",
-  "node_slug": "<matches node.slug>",
-  "action_tag": "rollout-runbook",
-  "summary": "The cited evidence is a repeatable procedure.",
-  "source_ref": "src-1#ops L40-55@c0d4e5f61728",
-  "reason": "Align must review structure before compile writes process prose."
-}
-```
-
-```jsonc
-{
-  "op": "structure_challenge",
-  "challenge_id": "ch_0002",
-  "kind": "wrong_shared_block_split",
-  "node_slug": "<matches node.slug>",
-  "unresolved_target": "rollout-runbook",
-  "reason": "The finalized shared block split leaves this Node with only secondary, non-citable evidence."
-}
-```
-
-```jsonc
-{
-  "op": "pending_ownership_challenge",
-  "challenge_id": "och_0001",
-  "node_slug": "<matches node.slug>",
-  "block_id": "2f4b8c1e9a03",
-  "requested_role": "shared",
-  "reason": "A visible context_only or secondary shared block contains facts that need citation."
-}
-```
-
-Different `kind` values demand different sub-fields. On shape errors, follow the CLI's top-level diagnostics / `expected_shape` / returned repair `next_action` instead of guessing. `agent_hints[]`, when present, is only a cutover mirror and must not be the source of truth.
-
-## What these are NOT
-
-- **Not a substitute for `skip`** when raw simply has no write-worthy fact for this Node.
-- **Not a Section.** Challenges never appear in active knowledge; they only travel through workflow state.
-- **Not a free upgrade path.** `request_full_text` may expose visible evidence text for inspection, but it does not change citation eligibility. If you need to cite secondary content, emit `pending_ownership_challenge` — do not paraphrase the secondary content into a Section.
-
-## How this slots into the main procedure
-
-- **Step 3 — Build actions**: when evidence implies a missing Action, missing `depends_on`, wrong parent, or needed ownership upgrade, emit the corresponding challenge instead of writing a Section.
-- **Step 5 — Self-verify**: no Section write cites a `context_only` or secondary-shared block; if any did, replace the Section with a `pending_ownership_challenge`.

package/plugin/skills/skill-compile-judge/SKILL.md

@@ -1,112 +0,0 @@
----
-name: skill-compile-judge
-description: >
-  Packaged skill invoked by `/context:compile`; not a user slash command. Consumes the budget-safe compile prepare summary
-  and candidate detail views, judges each draft action's raw evidence support and relation to listed candidates,
-  and emits a compile.judge-decisions.v2 document for `context reconcile review`.
-tools:
-  - Bash
----
-
-# skill-compile-judge — judge compile support and relation
-
-Decide whether each prepared compile item is supported by cited raw evidence
-and how it relates to the candidate Sections listed by the CLI. Emit judge
-decisions only; the CLI reviews, applies, and writes every workspace change.
-
-## TL;DR — Non-negotiables
-
-- Invoke this skill only when the active prepare summary contains `judge_handoff` or the returned diagnostics explicitly ask for compile support/relation judgment. A `review_reconcile_decisions` envelope by itself is not enough: if the command is accepting safe defaults or the remaining work is compact `{ item_id, accept_default: true }`, follow that review path instead. If the active envelope asks for `patch_compile_draft`, `continue_compile_cycle`, or another action, stop and follow that `next_action.command` instead.
-- Input is the budget-safe compile prepare summary. If `page.has_more` is true, follow `next_command` until every prepare item is listed.
-- The summary is an index: use `item_detail_command` only when the full proposed content, raw evidence, or source_ref details are needed.
-- For items with candidates, load only that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`.
-- Do not inspect workspace storage directly or run ad-hoc scripts to reconstruct candidates. Use only `items[]`, `evidence[]`, raw/source_ref diagnostics, `candidates[]`, `previous_decisions[]`, and `judge_handoff`.
-- Output exactly one JSON or YAML document with `schema_version: "compile.judge-decisions.v2"` and `decisions[]`.
-- Keep one decision per `judge_handoff.items[].item_id`, preserving prepare order. Do not emit decisions for mechanical safe-default items that the caller will pass through `--accept-safe-defaults`.
-- For support, output `support_verdict: supported | weak | unsupported` plus `support_reason`.
-- For relation, output `relation_verdict: new | duplicate | supersede | conflict | merge_into` plus `relation_reason`.
-- Compare only the candidates listed on that item. Do not perform workspace-wide BM25, grep, or source-file searches.
-- Fill `compared_section_ids` with every visible candidate Section id you inspected and set `compared_count` to the total candidate count inspected across pages. If candidates are paged, continue until `compared_count >= candidate_total` before final output.
-- Escape hatch: when an item has no candidates, `relation_verdict: new` with `compared_section_ids: []` and `compared_count: 0` is valid and expected.
-- For `duplicate`, `supersede`, `conflict`, or `merge_into`, set `target_section_id` to the matched candidate Section id.
-- Same `source_ref` can support different Section kinds only when the semantic role differs. Detect and explain same-source-ref multi-kind cases instead of treating them as automatic duplicates.
-- Raw/source_ref diagnostics are mechanical evidence checks, not a keyword gate. A supported judge verdict comes from the cited raw evidence semantically covering the claim.
-- Evidence-boundary errors remain blocking evidence issues. Section kind precision, example formatting, and summary style are advisory unless the active CLI `next_action` explicitly blocks on them.
-- Weak support is a warning-level verdict, not permission to invent missing facts. Unsupported support should normally pair with `conflict` or a later user question rather than a write decision.
-
-<reference>
-
-## Output Shape
-
-```yaml
-schema_version: "compile.judge-decisions.v2"
-mode: compile
-decisions:
-  - item_id: claim-001
-    support_verdict: supported
-    support_reason: "The cited raw block explicitly states the same invoice handling behavior."
-    relation_verdict: new
-    relation_reason: "No listed candidate covers this claim."
-    compared_section_ids: []
-    compared_count: 0
-```
-
-For a relation against an existing candidate:
-
-```yaml
-schema_version: "compile.judge-decisions.v2"
-mode: compile
-decisions:
-  - item_id: claim-002
-    support_verdict: supported
-    support_reason: "The cited evidence covers the correction."
-    relation_verdict: supersede
-    relation_reason: "section-3 states the older behavior and should be replaced."
-    target_section_id: section-3
-    compared_section_ids: [section-3, section-7]
-    compared_count: 2
-```
-
-## Verdict Meanings
-
-| field | value | Meaning |
-|---|---|---|
-| `support_verdict` | `supported` | Cited raw evidence covers the claim. |
-| `support_verdict` | `weak` | The evidence plausibly supports an ordinary summary, but review may ask for confirmation. |
-| `support_verdict` | `unsupported` | The claim adds facts or boundaries not present in cited raw evidence. |
-| `relation_verdict` | `new` | No listed candidate already covers the proposed knowledge. |
-| `relation_verdict` | `duplicate` | A listed candidate already covers the same claim. |
-| `relation_verdict` | `supersede` | A listed candidate is stale or wrong and should be replaced by the new claim. |
-| `relation_verdict` | `conflict` | The prepared claim and candidate disagree and need user resolution. |
-| `relation_verdict` | `merge_into` | The prepared claim should update or refine one listed candidate. |
-
-</reference>
-
-<procedures>
-
-### Step 1 — Load Prepare Summary And Candidate Details
-
-Use the caller-provided compact prepare output. For every item with candidates,
-load its candidate detail view before judging relation. Do not infer missing
-candidates from memory or bypass the candidate detail view.
-
-### Step 2 — Judge Support
-
-For each item, read the proposed content and cited evidence. Use
-Use raw/source_ref diagnostics only as evidence pointers; final support is your
-semantic verdict from the cited raw evidence.
-
-### Step 3 — Judge Relation
-
-Compare the proposed claim against each listed candidate. Track every
-visible candidate Section id in `compared_section_ids`, and set
-`compared_count` to the total candidate count inspected across pages. If the
-candidate list is empty, emit `new` with an empty compared list and
-`compared_count: 0`.
-
-### Step 4 — Emit Judge Decisions
-
-Return only the `compile.judge-decisions.v2` document. The caller passes it
-directly to `context reconcile review --decisions -`.
-
-</procedures>

package/plugin/skills/skill-context-query/SKILL.md

@@ -1,233 +0,0 @@
----
-name: skill-context-query
-description: >
-  Packaged skill invoked by `/context:query`; not a user slash command.
-  Uses structure-first strategy: inspect orientation, resolve unknown Nodes with node_lookup,
-  open known Nodes with node_view, then query Section details with section_search. Always
-  cite Node slug and Section id.
-  Activates when `/context:query` is invoked or when an agent needs to
-  answer a question using local Context workspace knowledge with citations.
-tools:
-  - Bash
----
-
-# skill-context-query — structure-first knowledge exploration with citations
-
-Answer user questions by exploring the local Context workspace structure first,
-then retrieving specific content within that structure. The CLI is the only source
-of local knowledge; never read workspace files directly.
-
-## TL;DR — Non-negotiables
-
-- **Structure first**: When problem is vague, don't do semantic search; inspect `orientation`, use `node_lookup` only to find a slug, and use `node_view` to open a known Node.
-- **CLI only**: Use only `context query` output as evidence. Never Read/Glob/Grep/Write workspace files.
-- **Route by intent**: Classify problem intent (vague / clear Node / relationship / detail) and choose the right command; see Query Route table below.
-- **Orientation is navigation**: `context query --intent orientation` returns a budgeted `[Slug Map]` plus optional `[Summary]` hints for scope choice only; it is not direct answer evidence.
-- **Cite structure**: Every conclusion cites `[node/slug]` or `[node/section]`. If evidence does not support a claim, mark as gap.
-- **Expand raw when needed**: Query summaries help recall and scope choice; factual answers should rely on returned Section content or CLI-provided raw/source_ref expansion commands when a hit is marked raw-assisted or raw-expandable.
-- **Handle diagnostics**: If CLI returns `select`, `miss`, `broad`, `raw-only`, or `truncated`, follow the hint: show user structure to choose from, ask for narrower scope, or suggest workflow.
-
-<reference>
-
-## Evidence Shape
-
-Primary evidence comes from the default `context query` output. Treat each
-returned row as a small evidence card.
-
-| Column / text | Use |
-|---|---|
-| `node` | Required citation handle for Section rows |
-| `section` | Required citation handle for Section rows |
-| `kind` | Section kind; use it to avoid overstating description/spec/warning content |
-| `content` | Evidence text for answer claims |
-| `refers_to_nodes` | Optional supplemental anchors when present |
-| `slug` | Candidate handle when the output is asking you to choose a Node |
-| `message` | Miss, broad-query, blocked, or narrowing guidance |
-| `raw_expand_command` / `raw_evidence_preview` | Pointer to expand raw/source_ref evidence when the hit needs factual confirmation |
-| `visibility` / `visible:` footer | Completeness signal for `node_view`; when `complete=true` / `visible: complete`, the shown Node Sections are exhaustive and there is no pagination |
-
-Supplemental context can come from:
-
-```text
-context query --intent node_view --scope <slug>
-context query --intent impact_analysis --scope <slug>
-context query --intent node_view --refers-to <slug>
-context query --intent section_search --scope <slug> --query "<keywords>"
-```
-
-## Query Route Decision Table
-
-Choose the `context query` command based on problem intent. **Structure queries take priority.**
-
-| Problem intent | Primary command | When to use |
-|---|---|---|
-| **Vague question, no Node named** User asks "what is X" / "what are the X types" | `context query --intent orientation` or `context query --intent node_lookup --query "<keyword>"` | User unsure which Node to focus on; show structure first |
-| **Node explicitly named** User mentions a specific service/system | `context query --intent node_view --scope <slug>` | User wants to open a specific known Node |
-| **Relationship / impact** User asks what depends on X / impact of changing X | `context query --intent impact_analysis --scope <slug>` | User asks about how a Node connects to others |
-| **Detail within known scope** (only after Node chosen) User asks for specific feature/behavior within chosen Node | `context query --intent section_search --scope <slug> --query "<detail>"` | User wants specific detail within an already-chosen Node |
-| **Very specific fact** (fallback, rarely needed) User asks for exact implementation location | `context query "$ARGUMENTS"` | Semantic fallback when structure queries don't suffice |
-| **Archive / reconciliation** User asks "find duplicates" / "check coverage" | `context query --intent recall --profile <reconcile-dedupe\|reconcile-support\|reconcile-refresh> --query "..."` | Only when user explicitly asks for audit/reconciliation |
-
-## Orientation output and budget
-
-`context query --intent orientation` is a navigation surface, not answer evidence.
-
-- JSON output keeps full Node `summary` fields when present.
-- Text output targets about 2000 tokens total. It prints `[Slug Map]` first, then `[Summary]`.
-- `[Slug Map]` uses finalized structure relationships and is for choosing the next `--scope <slug>`. If the workspace is too large, deeper layers are folded first.
-- `[Summary]` is truncated before the map. If output is still over budget, the command prints a continuation note. Drill down with scoped queries; there is no page-token pagination.
-- Use `context query --intent node_view --scope <slug>` for a Node overview, or `context query --intent section_search --scope <slug> --query "<keywords>"` for details inside that Node.
-- Use `context query --intent orientation --tag <tag>` or `context query --intent orientation --domain <slug>` to reduce the map before choosing a scope.
-- When `slug` and `title` are equivalent after normalization (for example `payment-api` and `Payment API`), text output shows only the slug.
-
-## BM25 Search Strategy
-
-When using `section_search`, `recall`, or `node_lookup`, the CLI uses BM25 (keyword-based, not embedding-based) for matching. BM25 requires explicit keyword coverage, so queries must be precise:
-
-- **Mix bilingual keywords**: Include both Chinese and English terms when querying—e.g., `"<chinese-term> <english-equivalent>"`, `"<product-name> <alternate-name>"`
-- **Include synonyms & aliases**: BM25 is keyword-literal, so if your query doesn't match Section content exactly, try related terms
-- **Use specific terminology**: Add version numbers, API names, or domain-specific terms to narrow results
-- **Scope to reduce noise**: Use `--scope <slug>` to focus on a single Node; broad queries may be blocked or produce low-quality matches
-
-Query intents that use BM25:
-- `context query --intent node_lookup --query "<short-keyword>"` — find candidate Nodes from slug, title, summary, aliases, and tags when direct slug/title/alias matching does not resolve the query
-- `context query --intent section_search --scope <slug> --query "<keywords>"` — find Section details using keyword matching within a known Node
-- `context query --intent recall --profile <profile> --query "<keywords>"` — archive audit and reconciliation queries using keyword matching
-
-Do NOT use BM25 strategy for:
-- `context query --intent node_view --scope <slug>` or `--node <slug>` — uses structure, not keywords
-- `context query --intent orientation` — uses structure, not keywords
-- `context query --intent impact_analysis` — uses structure, not keywords
-
-## Answer citation shape
-
-Use compact citations keyed to evidence type:
-
-```text
-Node identity/title:        <claim> [slug]
-Section claim:              <claim> [node/section]
-Relationship/edge:          X → Y [relationship_type]
-Multiple sources:           <claim> [node/section, node/section]
-```
-
-If multiple Sections support the same claim, cite the strongest one or two.
-Summarize what each cited Section supports; do not list citations without explanation.
-
-## Gap shape
-
-Use a visible gap when the CLI evidence cannot support the requested fact:
-
-```text
-Gap: local knowledge did not return evidence for <missing point>.
-```
-
-If the likely cause is stale workflow state, suggest the relevant context
-workflow (`/context:align` or `/context:compile`) only when the CLI output or
-the user's wording indicates newly captured material is not yet knowledge.
-
-</reference>
-
-<procedures>
-
-### Step 1 — Classify Problem Intent
-
-Determine what the user is trying to learn. Choose the appropriate command from the Query Route table above.
-
-**Classification:**
-
-- **Vague problem** — user unsure which Node to focus on
-  - Indicators: asks "what is X", "what are the X types", "how to understand X", or question without Node anchor
-  - Action: Run `context query --intent orientation` to show available Nodes and structure; then pick a Node or ask for narrower scope
-  - **Note**: `node_lookup` resolves unknown Node names; `node_view` opens known Node structure; orientation always works regardless of workspace content
-
-- **Node explicitly named** — user mentions a specific service/system/concept
-  - Indicators: user names a specific Node or system, "tell me about X", "show me X"
-  - Action: Run `context query --intent node_view --scope <slug>` to explore that Node
-
-- **Relationship / impact** — user asks how Nodes relate or what breaks if X changes
-  - Indicators: "what depends on X", "impact of X", "relationship between X and Y"
-  - Action: Run `context query --intent impact_analysis --scope <slug>` to show dependencies/relationships
-
-- **Detail within known scope** — user already chose a Node, now asking for specific detail
-  - Indicators: (comes after Node is selected) user asks "how does X handle [feature]", "what features does X support"
-  - Action: Run `context query --intent section_search --scope <slug> --query "<detail-keywords>"` — use BM25 keywords for precise matching
-
-- **Archive / reconciliation** — user explicitly asks for dedup/audit/coverage
-  - Indicators: "find duplicates", "check source coverage"
-  - Action: Run `context query --intent recall --profile <reconcile-*> --query "..."`
-  - ❌ Never use for ordinary questions
-
-### Step 2 — Execute Query And Interpret Response
-
-Run the command from Step 1. Read the CLI output carefully.
-
-**Route based on response:**
-
-- ❌ **Command fails** → Report error and stop
-- ❌ **`miss`** (no knowledge found) → Report no local knowledge and stop
-- ⚠️ **`select`** (multiple candidate Nodes) → Show candidates to user; ask which Node to focus on
-  - Then: loop back to Step 1 with chosen Node scope
-- ⚠️ **`broad` / `blocked` recall** → Ask user for narrower scope (specific Node, term, version)
-  - Then: loop back to Step 1
-- ⚠️ **`raw-only` / `uncompiled`** → Say "raw source found but not yet in compiled knowledge"
-  - Only suggest `/context:align` + `/context:compile` if user wants it compiled
-- ⚠️ **`truncated`** (entries cut off) → Mark answer as "non-exhaustive"
-  - Proceed to Step 3; ask for narrowing only if user needs complete inventory
-- ✓ **`node_view` says `visible: complete` / `visibility.complete=true`** → Do not run `section_search` merely to check completeness; use `section_search` only when you need keyword narrowing or ranking inside the Node
-- ✓ **Entries returned** → Proceed to Step 3
-
-### Step 3 — Compose Answer From Returned Structure
-
-Use only the returned Node/Section structure and content. Do not synthesize beyond what was returned.
-
-**Response structure:**
-
-1. **Start with core answer** — what the structure directly shows
-2. **Cite every claim** — `[node/slug]` for Node identity, `[node/section]` for facts
-3. **Include "Used nodes:" line** — if question named specific Nodes: "Using nodes: `<slug>`, `<slug>`"
-4. **Mark gaps** — if user asked for something not in returned structure: "Gap: no evidence for X"
-5. **Note truncation** — if CLI said `truncated`: "Non-exhaustive result — further narrowing available"
-
-**Example for structure-first query:**
-```
-User asks: "What systems handle X in our architecture?"
-
-Better query (structure-first):
-  context query --intent orientation  # Shows all available Nodes
-
-Returns several candidate Nodes matching the question.
-
-Response:
-"Systems that handle X:
-- **<Node Title 1>** [<slug-1>] — responsibility and scope
-- **<Node Title 2>** [<slug-2>] — responsibility and scope
-
-To dive deeper into any system, ask me for more details or let me know which Node you want to explore."
-```
-
-**Why show structure first?** Even when you know keywords, structure queries reveal the full landscape.
-Agents should explore Nodes first, then use section_search for details within a chosen Node.
-
-### Step 4 — Explore Further When Requested
-
-Once Node scope is clear, user may ask for deeper exploration.
-
-**Supplemental query triggers:**
-
-- User asks about Node's relationships/dependencies → `context query --intent impact_analysis --scope <slug>`
-- User asks for full Node content after partial answer → `context query --intent node_view --scope <slug>`
-- User asks specific detail within chosen Node → `context query --intent section_search --scope <slug> --query "<keywords>"`
-  - **Use BM25 strategy**: mix Chinese and English keywords for better matching (e.g., mix synonym or translated forms of the search term)
-- User names another Node in `refers_to_nodes` and asks about its relationship → `context query --intent node_view --refers-to <slug>`
-
-**BM25 tips for supplemental queries:**
-- When searching for a detail, include both native and translated forms of terms
-- If first query is too broad, add more specific keywords or domain terminology instead of generic terms
-- Scope helps narrow BM25 results: `--scope <slug> --query "<specific-term> <synonym>"` is more precise than an unscoped broad query
-
-**Safety:**
-- ❌ Do NOT auto-fetch all `refers_to_nodes`; only query if user asks
-- ❌ Do NOT read workspace files to discover new Nodes
-- ✓ Only supplement with slugs already in returned structure or user's explicit question
-
-</procedures>