@c4a/context-cli 0.5.29-beta.20 → 0.5.29-beta.22

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

@@ -1,10 +1,10 @@
 ---
 name: skill-context-query
 description: >
-  Packaged skill invoked by `/context:query`; not a user slash command. 
-  Uses structure-first strategy: explore Node structure via node_search/orientation first,
-  then narrow to specific Nodes, then explore relationships. Semantic queries are secondary
-  and only when structure queries cannot find the target Node. Always cite Node slug and Section id.
+  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:
@@ -19,7 +19,7 @@ of local knowledge; never read workspace files directly.
 
 ## TL;DR — Non-negotiables
 
-- **Structure first**: When problem is vague, don't do semantic search—explore Node structure via `node_search` or `orientation` to let user choose which Node to focus on.
+- **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.
@@ -42,14 +42,15 @@ returned row as a small evidence card.
 | `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 |
+| `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_search --scope <slug>
+context query --intent node_view --scope <slug>
 context query --intent impact_analysis --scope <slug>
-context query --intent node_search --refers-to <slug>
-context query --intent description_search --scope <slug> --query "<keywords>"
+context query --intent node_view --refers-to <slug>
+context query --intent section_search --scope <slug> --query "<keywords>"
 ```
 
 ## Query Route Decision Table
@@ -58,10 +59,10 @@ Choose the `context query` command based on problem intent. **Structure queries
 
 | 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_search --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_search --scope <slug>` | User wants to explore a specific known Node |
+| **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 description_search --scope <slug> --query "<detail>"` | User wants specific detail within an already-chosen Node |
+| **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 |
 
@@ -73,13 +74,13 @@ Choose the `context query` command based on problem intent. **Structure queries
 - 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_search --scope <slug>` for a Node overview, or `context query --intent description_search --scope <slug> --query "<keywords>"` for details inside that Node.
+- 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 `description_search`, `recall`, or `node_search --query`, the CLI uses BM25 (keyword-based, not embedding-based) for matching. BM25 requires explicit keyword coverage, so queries must be precise:
+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
@@ -87,13 +88,13 @@ When using `description_search`, `recall`, or `node_search --query`, the CLI use
 - **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_search --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 description_search --scope <slug> --query "<keywords>"` — find Section details using keyword matching within a known Node
+- `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_search --scope <slug>` or `--node <slug>` — uses structure, not keywords
-- `context query --intent orientation` — uses structure, not keywords  
+- `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
@@ -135,11 +136,11 @@ Determine what the user is trying to learn. Choose the appropriate command from
 - **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_search` uses structure not BM25; orientation always works regardless of workspace content
+  - **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_search --scope <slug>` to explore that Node
+  - 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"
@@ -147,7 +148,7 @@ Determine what the user is trying to learn. Choose the appropriate command from
 
 - **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 description_search --scope <slug> --query "<detail-keywords>"` — use BM25 keywords for precise matching
+  - 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"
@@ -170,6 +171,7 @@ Run the command from Step 1. Read the CLI output carefully.
   - 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
@@ -188,7 +190,7 @@ Use only the returned Node/Section structure and content. Do not synthesize beyo
 ```
 User asks: "What systems handle X in our architecture?"
 
-Better query (structure-first): 
+Better query (structure-first):
   context query --intent orientation  # Shows all available Nodes
 
 Returns several candidate Nodes matching the question.
@@ -202,7 +204,7 @@ To dive deeper into any system, ask me for more details or let me know which Nod
 ```
 
 **Why show structure first?** Even when you know keywords, structure queries reveal the full landscape.
-Agents should explore Nodes first, then use description_search for details within a chosen Node.
+Agents should explore Nodes first, then use section_search for details within a chosen Node.
 
 ## Step 4: Explore further (if user requests)
 
@@ -211,10 +213,10 @@ 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_search --scope <slug>`
-- User asks specific detail within chosen Node → `context query --intent description_search --scope <slug> --query "<keywords>"` 
+- 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_search --refers-to <slug>`
+- 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

package/plugin/skills/skill-semantic-reconcile/SKILL.md

@@ -26,6 +26,7 @@ only; the CLI performs every write.
 - Every `merge_update` / `supersede` / `keep_separate` / `split_then_reanchor` write must be supported by **one** valid `proposed.source_ref` covering the final content. Preserve raw evidence's domain terms, numbers, code literals, and named entities; do not introduce acronyms, translations, or aliases the cited evidence does not define. Do not cite a title, `Relations` / `Parent` / `Children` / `Related` navigation line as the sole support for a substantive claim.
 - Unresolved conflicts and low-confidence support → `action: ask_user`. Never expose `src-N`, Section ids, or source refs as the user-facing choice; they belong only in the structured payload.
 - `decided_by: user` only after a specific recent user message answering the specific question for the specific item. Auto mode, blanket "continue," and long-running permissions are **not** user confirmation. Never mark yourself.
+- `decided_by: delegated_agent` is CLI-owned. Do not emit it manually; it appears only when the current compile workflow was created with user-authorized `--delegated`.
 - `omit` is never an automatic decision. If an item looks redundant or low-value, follow the Scope Review pass in [references/scope-review-and-omit.md](references/scope-review-and-omit.md); only a user-confirmed no-write outcome may become `action: omit` with `decided_by: user`.
 - `apply` consumes the ready review artifact for the current workflow scope: run plain `context reconcile apply`. There is no input file; do not extract `apply_document` with scripts.
 - Stable output: preserve prepared item order; the CLI rejects unknown fields (timestamps, random ids, storage paths, host absolute paths) and canonicalises stored payloads. Fixed rules and schema come from this skill; only the prepared context varies between repeated review calls.
@@ -37,7 +38,7 @@ only; the CLI performs every write.
 | `prepare.mode` is `drop` or `refresh` (covers `remove_unsupported` mode semantics, `reanchor`, `split_then_reanchor`) | [references/mode-semantics.md](references/mode-semantics.md) |
 | review returned `support_confirmation`, `omit_confirmation`, `scope_review_required`, or any `ask_user` you need to upgrade to an executable decision | [references/user-confirmation.md](references/user-confirmation.md) |
 | review returned `agent_hints[]` with `code: "context-only-leakage-high"` | [references/leakage-and-ownership.md](references/leakage-and-ownership.md) |
-| items carry `temporal_prior` / `source_captured_at` / `temporal_disposition`, `source_support.evidence_block_*`, `proposed.detail`, or review returned `example_detail_preservation` | [references/temporal-and-evidence.md](references/temporal-and-evidence.md) |
+| items carry `temporal_prior` / `source_captured_at` / `temporal_disposition`, `source_support.evidence_block_*`, or prepared long `proposed.content` / `proposed.summary` | [references/temporal-and-evidence.md](references/temporal-and-evidence.md) |
 | considering `action: omit`, or items look redundant / low-value / scope-wrong | [references/scope-review-and-omit.md](references/scope-review-and-omit.md) |
 
 If none of the above hold, you are on this skill's main path: refresh/drop/non-compile reconcile, or compile scope-review fallback with no special review-time signals. Ordinary compile prepare relation/support judgment remains `skill-compile-judge`.
@@ -82,9 +83,9 @@ Edge-case actions (`reanchor`, `split_then_reanchor`, `remove_unsupported`, `omi
 | action | Required fields | Validation |
 |---|---|---|
 | `duplicate_skip` | `target` | Exact duplicate or already-applied no-op only. |
-| `merge_update` | `target`, `proposed.content`, `proposed.source_ref`, `proposed.detail` when present in prepare | Final content must be supported by cited evidence; `proposed.kind`, when present, must match target kind. |
-| `supersede` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.detail` when present in prepare | New Section claim must be supported by cited evidence. |
-| `keep_separate` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.detail` when present in prepare | New orthogonal claim must be supported by cited evidence. Weak support is allowed only after explicit user confirmation (`decided_by: user`). |
+| `merge_update` | `target`, `proposed.content`, `proposed.source_ref`, `proposed.summary` when present in prepare | Final content must be supported by cited evidence; `proposed.kind`, when present, must match target kind. |
+| `supersede` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.summary` when present in prepare | New Section claim must be supported by cited evidence. |
+| `keep_separate` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.summary` when present in prepare | New orthogonal claim must be supported by cited evidence. Weak support is allowed only after explicit user confirmation (`decided_by: user`). |
 | `ask_user` | `user_confirmation.required: true` | Use when business meaning or support cannot be decided from prepared evidence. |
 
 Source-support gate: if the proposed claim cannot honestly point at one range covering every sentence, split the claim or ask the user instead of forcing it into an incorrect `source_ref`. If a useful reader summary would combine adjacent evidence, first broaden `proposed.source_ref` so the cited range covers every sentence; if that broadening would require unrelated content, split. See [references/temporal-and-evidence.md](references/temporal-and-evidence.md) for evidence-block repair hints.

package/plugin/skills/skill-semantic-reconcile/references/mode-semantics.md

@@ -29,7 +29,7 @@ These appear only in drop prepare items. They handle "a Section that the drop wo
 | Item shape | Decision |
 |---|---|
 | Drop item still **fully** supported by surviving source | `reanchor` + `reanchor` — repoint `proposed.source_ref` at the surviving evidence, keep target unchanged. |
-| Drop item **partly** supported (one fact survives, another does not) | `reanchor` + `split_then_reanchor` — split into `proposed.sections[]`, each with independent `kind` / `content` / `source_ref` / `detail`. |
+| Drop item **partly** supported (one fact survives, another does not) | `reanchor` + `split_then_reanchor` — split into `proposed.sections[]`, each with independent `kind` / `content` / optional `summary` / `source_ref`. |
 | No surviving support | `unsupported` + `remove_unsupported` (physical remove on drop apply). |
 
 `split_then_reanchor` requires each split Section to be independently supported by its own cited evidence. The CLI rejects splits where any sub-Section's `source_ref` does not cover its `content`.

package/plugin/skills/skill-semantic-reconcile/references/temporal-and-evidence.md

@@ -4,8 +4,7 @@ Consult this reference when prepare items carry **any** of:
 
 - `temporal_prior` / `proposed.source_captured_at` / candidate `source_captured_at` / `last_reconciled_at` / `temporal_disposition`
 - `source_support.evidence_block_candidates[]` or `source_support.evidence_block_*` repair hints
-- `proposed.detail` with command / config / code fence content
-- `agent_hints[]` with `code: "example_detail_preservation"`
+- prepared long `proposed.content` / `proposed.summary`, especially with command / config / code fence content
 
 For prepare items that have none of the above, ignore this file.
 
@@ -42,25 +41,26 @@ These are **repair hints**, not automatic broadening permission. Rules:
 
 The support gate exists to prevent orphan claims and false evidence links, not to optimize retrieval. Prefer preserving a precise raw-backed claim over rewriting content into a smoother summary.
 
-## `proposed.detail` preservation
+## Long `proposed.content` / `proposed.summary` preservation
 
-When the prepare item carries `proposed.detail`, treat it as load-bearing:
+When the prepare item carries long `proposed.content` or a `proposed.summary`, treat both as load-bearing:
 
-- `detail` carries long-form prose, examples, and code blocks.
-- Dropping `detail` silently loses knowledge.
-- Preserve it **exactly** on executable write decisions (`merge_update`, `supersede.new`, `keep_separate`, `split_then_reanchor` sub-Sections).
-- The only legitimate way to clear `detail` is an update-style decision that explicitly emits `detail: null` as the chosen outcome.
+- `content` carries the active Section knowledge, including long-form prose, examples, URLs, tables, commands, config, and code blocks.
+- `summary` is the short reader/query aid for long content.
+- Dropping either field silently loses knowledge or query UX.
+- Preserve prepared `content` and `summary` on executable write decisions (`merge_update`, `supersede.new`, `keep_separate`, `split_then_reanchor` sub-Sections) unless the decision intentionally rewrites the user-facing content.
+- The only legitimate way to clear `summary` is an update-style decision that explicitly emits `summary: null` as the chosen outcome.
 
-## `example_detail_preservation` repair
+## Example content preservation repair
 
-If review returns `example_detail_preservation`, the cited example evidence contains a command / config / code fence that did **not** appear in `proposed.detail`. Repair:
+If review reports that a cited example evidence contains a command / config / code fence missing from `proposed.content`, repair:
 
-- **Preferred**: regenerate the decision with the relevant fenced block included in `proposed.detail` (preserve language, fences, and exact code).
+- **Preferred**: regenerate the decision with the relevant fenced block included in `proposed.content` (preserve language, fences, and exact code).
 - **Fallback only after user confirmation**: keep a prose-only example summary, mark the final decision `decided_by: user` per `references/user-confirmation.md`. Auto mode is not user confirmation.
 
 ## How this slots into the main procedure
 
 - **Step 1 — Consume**: scan prepare items for the signal fields above; flag affected items for the relevant repair path.
 - **Step 3 — Decide**: temporal priors inform `rationale` but never the action choice; evidence-block hints may justify broadening the cited range.
-- **Step 4 — Emit**: rerun `context reconcile review` after broadening ranges or restoring `detail`; only then proceed to apply.
-- **Step 5 — Self-verify**: no executable write strips a prepared `detail`; no temporal field leaks into `proposed`; every broadened `source_ref` has been re-reviewed.
+- **Step 4 — Emit**: rerun `context reconcile review` after broadening ranges or restoring missing example content; only then proceed to apply.
+- **Step 5 — Self-verify**: no executable write strips prepared `content` or `summary`; no temporal field leaks into `proposed`; every broadened `source_ref` has been re-reviewed.

package/plugin/skills/skill-semantic-reconcile/references/user-confirmation.md

@@ -14,6 +14,7 @@ For runs where review emits no questions, ignore this file.
 Only **explicit user reply to a question your agent asked**. The following are **not** confirmation:
 
 - Auto mode being active
+- Delegated mode being active (`--delegated` lets the CLI make scoped low-risk review decisions; it is not user confirmation for a specific question)
 - A blanket "continue" / "yes go ahead" earlier in the session
 - Permission to run shell commands
 - A previous decision applied with `decided_by: user` for a different item
@@ -61,6 +62,7 @@ After user confirmation:
 - `decided_by` is a **top-level** decision field, not a `proposed` sub-field.
 - Final executable decisions must not carry `user_confirmation.required: true`. That flag belongs only on `action: ask_user` items that still need input.
 - User confirmation permits weak support and omit. It does **not** permit unsupported evidence, missing hard facts, or contradictory claims — those still need stricter evidence or stay `ask_user`.
+- `decided_by: delegated_agent` is reserved for CLI-generated decisions inside a delegated compile workflow. Do not emit it from this skill.
 
 ## How this slots into the main procedure