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

package/plugins/cursor/skills/skill-prose-align/references/internal-procedures/structure-planning.md

@@ -0,0 +1,243 @@
+---
+name: structure-planning
+description: "Internal procedure for the current align gate. Reads CLI-guided align evidence, applies semantic Node classification gates, and emits context.structure.v1 payloads for CLI validation/stage."
+---
+
+# Structure Planning Procedure
+
+## TL;DR
+
+Run `context run align:<type>:<source>:<collection> --view read-plan --format json`, follow the top-level `next_action.command` to read the CLI-selected evidence path, produce a `context.structure.v1` structure payload, and continue following top-level `next_action`. The CLI owns route, validation, repair commands, and stage guards; this skill owns only semantic classification and source-bound structure judgment.
+
+<reference>
+
+## Canonical Data
+
+- The current phase view result is authoritative. Branch on `next_action.kind`,
+  execute `next_action.command`, and treat listed views as detail reads rather
+  than a checklist.
+- `allowed_actions[]` describes capabilities on the current view result; it is
+  not a menu of alternate write paths and does not override `next_action`.
+- `agent_hints[]`, when present, are diagnostics. Do not prefer them over
+  top-level `next_action`.
+- Schema names and enum values come from
+  `context run align:<type>:<source>:<collection> --view schema --format json`. Use
+  that schema as the authoring contract for `context.structure.v1`.
+- Existing approved knowledge and `knowledge/structure.yaml` are the lookup
+  registry exposed through current CLI/status/query views. Do not read
+  `knowledge/**` or create a separate registry file.
+- Code projection Nodes are reusable knowledge handles. When document evidence belongs on a code symbol, reuse the code slug instead of creating a parallel document Node.
+- Validation diagnostics are the mechanical structure ownership source of
+  truth. Non-content spans such as navigation references, placeholders, front
+  matter, marker quotes, embed tags, and embedded assets should not become
+  reader-facing Sections unless the evidence itself is the cited knowledge.
+- When relation hints are present, inspect them before finalizing graph
+  structure. Use existing/current matches for typed `edges[]`; keep unresolved
+  target ref/title hints deferred in `unresolved[]` and do not write dangling
+  parent, child, or edge refs. Ordinary source-bound views require at least one
+  source-backed planned section. The only empty-section exception is a generated
+  parent index view: it must use `generated: parent_index`, `sections: []`, and
+  source-backed `contains` edges to child views. For navigation-only /
+  placeholder-only sources, keep useful source/page identities as `unresolved[]`
+  notes until there is source-backed section evidence, a supported edge target,
+  a valid parent-index container, or a later compile `skip` decision. If a
+  placeholder/relation source is skipped entirely, leave its relation clues in
+  `unresolved[]` only when they still matter; otherwise omit them.
+- `views[]` and diagnostics distinguish citable evidence from supporting context. Do not promote supporting/context-only material into cited Sections unless a later ownership correction makes it citation-eligible.
+- Keep cache-friendly prompt order: fixed protocol/schema first, existing knowledge lookup second, source evidence views third, current semantic payload last. Preserve CLI JSON order and do not add timestamps, random ids, scratch paths, or host paths to generated payloads.
+- Structure digests and snapshot hashes are stale guards. Follow returned
+  `next_action.command` and do not invent digest values.
+- Node type, tag, fake-Entity, `domain`, and `action` gates are in `structure-planning/references/gates.md`.
+- Coarse reading density and neutral signal rules are in `structure-planning/references/density-profile.md`.
+- Candidate anomaly handling, stable references, duplicate handling, and
+  conflict handling are in
+  `structure-planning/references/candidate-resolution.md`.
+
+</reference>
+
+<procedures>
+
+Use this only inside the current align gate.
+
+### Step 1 — Start From The Envelope
+
+Run `context run align:<type>:<source>:<collection> --view read-plan --format json`.
+Confirm the response is the current prose align view result, then identify
+`next_action`, available views, source metadata, and diagnostics.
+
+If the host truncates a view result but the preview includes top-level
+`next_action.command`, run that command. If `next_action` is not visible, rerun
+the current view command; do not recover host tool-result files.
+
+If no current phase view result is present, stop and surface the CLI output; do
+not reconstruct an align route from prior prompt memory.
+
+### Step 2 — Follow The Evidence Read Path
+
+Run the returned `next_action.command`. For structural align work this is
+normally `read-plan`; after that, follow the evidence view's `next_action.command`
+or `next_command`.
+
+`read-plan` is the navigation surface. It chooses whether the next evidence read
+is `source-index`, `span-detail`, `span-text`, or another current evidence view.
+Read those views and then author the requested
+`context.structure.v1` payload yourself. Never pipe evidence text into validate.
+
+If an evidence view is truncated, `page.has_more: true`, or the CLI returns a
+`next_command`, run that command before authoring.
+
+Read evidence through semantic CLI views, not shell parsing. Follow `page.next_command` for pagination. If the command contains `--read-cursor`, treat it as opaque continuation state and run it exactly; do not replace it with hand-written `--source`, `--heading`, `--window`, or `--range` selectors. Use `--source`, `--heading`, `--window`, `--range`, and `--token-budget` as view filters only. `--unwrap` removes workflow metadata; it does not expand a compact view into full detail.
+
+If an evidence view returns `page.has_more`, `truncated: true`, or a
+view-specific incomplete-read diagnostic, treat that response as a partial
+read. Do not decide source-wide ownership or dense planned Sections from
+headings alone; continue the current detail view only when `page.next_command`
+is explicitly needed, otherwise return to the CLI-designated navigation view.
+
+### Step 3 — Reuse Existing Knowledge
+
+Query existing knowledge for reusable names before proposing new term/service/system/action Nodes. Exact title/slug/alias hits should usually become references to the existing Node, not duplicate candidates.
+
+When a code projection Node already represents the object, reuse its slug for prose evidence and plan only prose-owned Sections for the current source evidence.
+
+### Step 4 — Route Collection, Then Classify Semantic Structure
+
+Before choosing Node type or Section kind, route each evidence unit to its
+internal collection. The phase `<collection>` is only the entry profile for the
+current run; it is not a cap on what this structure may contain. A mixed source
+can produce multiple `views[]` in one confirmed structure when source evidence
+supports them.
+
+Use collection routing first:
+
+- product intent, user story, requirement, roadmap, or product scenario ->
+  `product`;
+- architecture, service/module/system design, runtime dependency, code-adjacent
+  prose -> `architecture`; if an existing code projection already owns the
+  object, reuse its NodeRef/ViewRef instead of creating a `codegraph` prose
+  view;
+- SOP, runbook, operation drill, workflow, or how-to procedure -> `sop`;
+- FAQ, question/answer, support notes -> `faq` only when the evidence is an
+  independent FAQ page or cross-cutting support knowledge; a single Q&A or
+  scattered support note stays as a `faq` Section under the owning view;
+- standards, policy, rules, conventions, reusable constraints -> `standards`;
+- decision record, trade-off, migration conclusion -> `decision` only when it
+  is an independent decision record with owner/date/lifecycle or cross-cutting
+  decision scope; one-off conclusions stay as `decision` Sections under the
+  owning view;
+- incident, postmortem, outage, fault timeline, action item -> `incident` only
+  when it has incident identity, timeline, follow-up, or tracking lifecycle;
+  isolated warnings/failures/action items stay as `incident` or `warning`
+  Sections under the owning view;
+- test plan, validation scenario, acceptance case -> `test`;
+
+Do not route prose align views to `codegraph` or `feats`: `codegraph` is
+produced by code extraction / AST projection, and `feats` is reserved for the
+dedicated feature workflow. For section-vs-collection overlap, keep a local
+`faq`, `decision`, or `incident` as a Section kind under the owning view unless
+the source is independently queryable across the package and has its own
+lifecycle, ownership, timeline, or cross-cutting scope.
+
+After collection routing, apply `structure-planning/references/gates.md` before
+authoring Nodes: classify Node type in order (`action` scale + process evidence,
+then concrete/term `entity`, then child-bearing `domain`), reject fake Entities
+only when at least two suspicious signals match, keep `term` separate from
+concrete tags, and provide required gate evidence.
+
+Preserve shared-source intent when the same source span legitimately supports
+multiple views. Do not copy the span text into multiple rewritten bodies; cite
+the same CLI `source_ref` in each supported view and let structure-summary mark
+the shared evidence.
+
+Source titles and headings are ordinary evidence, not structural authority. Choose titles and summaries that fit the final Node type and the CLI-provided generation policy.
+
+For `node.title` and `node.summary`, follow the workspace/source language
+surfaced by the current view or the user's instruction. In Chinese workspaces,
+translate descriptive scaffold words such as architecture, strategy, lifecycle,
+overview, scheduling, high availability, and warning into Chinese while
+preserving product names, code identifiers, CLI flags, slugs, source_ref tokens,
+and citation tokens exactly when needed. Do not copy an English source title
+into `node.title` merely because the source is English.
+
+Do not classify a broad architecture/system/方案 source as `domain` just because the title sounds like a scope. If it has writable Sections but no resolvable current/existing child Nodes, use an `entity` tag such as `system` or `application`; reserve `domain` for grouping child Nodes through typed `edges[]` with supported child targets.
+
+For large or batched payloads, use
+`structure-planning/references/density-profile.md` and
+`structure-planning/references/candidate-resolution.md` as judgment aids.
+They do not create additional workflow stages or alternate payloads.
+
+### Step 5 — Build The Payload Requested By `next_action`
+
+Use `context run align:<type>:<source>:<collection> --view schema --format json` to
+shape the payload. Treat that schema as the authoring contract.
+
+Produce one `context.structure.v1` document with semantic Nodes, planned
+Sections, typed edges, unresolved items, lifecycle state, sources, and evidence
+snapshot hash. Section identities are part of the structure gate: choose stable
+section ids such as `overview`, `behavior`, `constraints`, or a source-backed
+domain-specific name when the evidence supports it.
+
+Use only CLI-provided `source_refs[]` for section and edge evidence. Do not
+invent heading/range/window selectors inside the structure. Treat source heading
+changes as section-planning signals: sibling sub-headings under a shared parent
+may stay in one Section when they form one coherent semantic topic; headings
+with no shared parent should usually split unless you intentionally want one
+Section to span them. If a semantic section would require non-contiguous or
+cross-source evidence, split it during align or return the issue to the
+structure gate. Current compile writes approved knowledge by mirroring source
+spans; it does not use rewritten multi-ref sections to compress unrelated
+evidence.
+
+When the cited source sentence itself is uncertain, preserve that uncertainty on
+the edge with `confidence: possible` or `confidence: hypothesis`. This is only
+for source-authored uncertainty such as "可能", "疑似", "may", or "might". If
+you are unsure whether the source supports the relation, do not add an uncertain
+edge; move the relation to `unresolved[]`.
+
+No-write/navigation-only/placeholder-only material should become `unresolved`
+at align time when it has retrieval or graph value but lacks source-backed
+section evidence. Do not turn relation-only navigation into a factual Section.
+Do not submit `sections: []` for an ordinary source-bound view. Use
+`sections: []` only for a generated parent index view, and only when it has
+`generated: parent_index` plus source-backed `contains` edges to child views.
+If the relationship matters but evidence or a target node is missing, keep it
+unresolved instead of writing a dangling edge.
+
+Emit `depends_on` edges only when cited source refs explicitly say one Node
+consumes, requires, calls, is configured by, or is downstream of another Node as
+a prerequisite, capability provider, upstream input, runtime dependency, or
+data-flow source. Direction is consumer/downstream -> provider/upstream. Do not
+create `depends_on` for parent/child containment, `Related`/`See also` lists,
+sibling co-occurrence, shared table membership, name similarity, or a plain
+mention without a dependency predicate. `edges[].source_refs[]` must include the
+source ref that states the dependency; if the relationship matters but evidence
+is missing, leave the edge unresolved instead of guessing.
+
+Prefer the strongest source-backed `section_kind` using the current schema's `section_kind_priority` and `section_kind_triggers`; avoid planning an entire dense source as `description` when the evidence clearly contains fenced examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Use `example` for fenced command/config/code or literal sample blocks, not ordinary scenario prose. Use `incident` only for dated or timestamped failure evidence with impact scope plus root cause, mitigation, or handling record. Use `decision` only when the source surfaces two or more alternatives or options plus the chosen path and rationale. Treat kind precision as a drafting quality preference, not a reason to block an otherwise source-backed write. Keep only raw-backed semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
+
+There is no parallel candidate-body authoring path. Emit only the
+`context.structure.v1` payload accepted by the current schema view.
+
+### Step 6 — Validate And Submit
+
+Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns blocking diagnostics, repair the exact paths it reports and rerun validate. After validation, show the structure to the user with the structure summary and `structure_report.path`. If validation returns `confirmation_blockers[]` or `will_block_confirmation`, repair those blockers before asking the user to confirm. If you stage a draft structure first, the stage result is still a human review gate: show the returned report/summary and ask the user to inspect it before confirming. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
+
+After stage succeeds, do not rerun the same write command to confirm success.
+Use `context status --format json` or the returned result for read-only
+confirmation; then continue with the returned `next_action.command`, normally
+`context run compile:<type>:<source>:<collection> --view read-plan --format json`.
+
+If any write is rejected, follow the returned `next_action` and `reason_code`.
+Do not retry by guessing direct/batched stages, forcing route bypasses, or
+editing CLI-managed files.
+
+### Step 7 — Self-verify
+
+- [ ] All writes followed top-level `next_action.command`. If not, return to **Step 1**.
+- [ ] Evidence was read through returned `next_action.command`, `next_command`, or current CLI schema/view commands only. If not, return to **Step 2**.
+- [ ] Node classification used the semantic gates in `structure-planning/references/gates.md`. If not, return to **Step 4**.
+- [ ] URL/reference ownership followed CLI diagnostics, not static prompt rules. If not, return to **Step 5**.
+- [ ] The requested align payload passed `context run align:<type>:<source>:<collection> --validate --input - --format json` before stage. If not, return to **Step 6**.
+- [ ] No `sources/`, `unapproved/`, `knowledge/`, `dist/`, `.tmp`, host tool-results, or CLI-managed files were read or written with generic tools. If violated, restart from **Step 1**.
+
+</procedures>

package/plugins/cursor/skills/skill-prose-compile/SKILL.md

@@ -0,0 +1,265 @@
+---
+name: skill-prose-compile
+description: >
+  Internal procedure invoked by the public Context continuation entry; not a user command.
+  Uses confirmed Context document structure to create source-bound draft prose
+  candidates through `context.compile-actions.v1`, without reading raw
+  snapshots directly.
+tools:
+  - Bash
+---
+
+# skill-prose-compile
+
+Compile confirmed document structure into reviewable draft knowledge.
+
+## TL;DR
+
+- Use this after `context status` reports `structure-ready` or
+  `needs-prose-compile`, or when the user explicitly asks to compile confirmed
+  prose structure into draft pages.
+- The input is already confirmed `context.structure.v1`; do not redesign node
+  ownership, page paths, or relationships here. Return to prose align if those
+  are wrong.
+- Read compile context through CLI views only: `read-plan`, `node-context`, and
+  `schema`. Use align evidence views only when the compile view or validation
+  output gives a specific source ref that needs exact text.
+- Emit `context.compile-actions.v1`; the CLI mirrors source spans, derives
+  `content_mode`, writes review candidates, and enforces source-bound evidence.
+- The `summary` field in each action is the Agent-authored behavior half only:
+  compact source-backed recall text for the cited section. The CLI separately
+  renders the reachability half from confirmed typed edges into review metadata;
+  do not invent edge summaries or relation fields in the action payload.
+- Default to omitted `content` so the CLI mirrors the cited source span.
+  Do not write explicit `content`. If the evidence cannot be represented as a
+  faithful mirrored continuous span, split the section or return to prose align
+  for a confirmed structure change.
+- Before choosing section kind, summary, skip/update, weak-evidence handling, or
+  structure repair, read the current procedure references listed by the CLI as
+  `semantic_reference_files`. These are the migrated compile judgment rules, not
+  summaries.
+- Do not produce or validate compile actions from this entry file alone. If the
+  relevant `semantic_reference_files` have not been read in the current turn,
+  stop and read them first.
+
+<reference>
+
+## User-Facing Gates
+
+Use semantic labels, not SDK function names:
+
+| Gate | Say this | Do not say this first |
+|---|---|---|
+| Compile context | "I will inspect the confirmed structure and each node's planned evidence before drafting sections." | `node-context`, `context.compile-actions.v1` |
+| Source-bound draft | "I will mirror supported source spans into reviewable draft pages and attach summary/kind metadata." | `compileProse` |
+| Non-mirror evidence | "This section cannot be compiled as-is because the evidence is not one faithful source mirror; we need to split or revise the structure." | "The agent can rewrite this automatically." |
+| Structure mismatch | "This compile cannot proceed because the confirmed structure no longer matches the evidence; we need to return to structure confirmation." | Editing `knowledge/` or `unapproved/` directly |
+
+## Runtime Discipline
+
+- Follow `context status`, `routing.next_commands`, compile view
+  `next_action`, and validation diagnostics. Treat CLI commands as the source
+  of truth.
+- Use only the returned `next_action.command` for the next required write.
+  Treat `allowed_actions[]` as permission for read-only insertions; it is not a
+  menu of alternate write paths.
+- Treat `agent_hints[]` as temporary diagnostics. If an agent hint conflicts
+  with a status route, compile view `next_action`, or validation result, follow
+  the top-level route.
+- Do not use direct file tools, shell scripts, `jq`, `sed`, `cat`, `head`,
+  `tail`, Python, or Node.js to inspect `sources/`, `unapproved/`,
+  `knowledge/`, `dist/`, or CLI-managed `.tmp` as a substitute for Context
+  views.
+- Run one write at a time. Do not parallelize compile stage, review apply,
+  close, or build writes.
+- Compile does not get a second, looser rule set. If a rule conflicts with the
+  current CLI schema or diagnostics, follow the CLI and repair the payload.
+- Write digest/hash flags are stale guards. Use values returned by the CLI; do
+  not parse stdout fragments or host tool-result files to reconstruct them.
+- If a payload is too large for a heredoc, stage it under
+  `.tmp/agent-payloads/<run-id>/...` in the workspace root and redirect stdin
+  from that file. Never reuse fixed `/tmp/c4a-*` names, and never place agent
+  scratch payloads under CLI-managed `.tmp/context-cli/`, `sources/`,
+  `unapproved/`, `knowledge/`, `dist/`, review output, or package output
+  directories.
+
+## Compile Views
+
+Recommended read order:
+
+```bash
+context run compile:<type>:<source>:<collection> --view read-plan --format json
+context run compile:<type>:<source>:<collection> --view node-context --source <view-ref> --format json
+context run compile:<type>:<source>:<collection> --view schema --format json
+```
+
+Use CLI-returned `available_view_refs`, `planned_sections`, `local_sources`, and
+`next_action.command`. Do not reconstruct the structure by opening
+`unapproved/structure.yaml` or `knowledge/structure.yaml` directly.
+
+## Procedure References
+
+These are current compile rules for source-bound drafting, judgment, semantic
+repair, and close handoff.
+
+| Decision | Reference |
+|---|---|
+| Compile action drafting, section kind, coverage, summaries, content intent | [references/internal-procedures/compile-actions.md](references/internal-procedures/compile-actions.md) |
+| Action/domain compile gates | [references/internal-procedures/compile-actions/references/action-domain-gates.md](references/internal-procedures/compile-actions/references/action-domain-gates.md) |
+| Notes, refresh/update, and structural challenges | [references/internal-procedures/compile-actions/references/notes.md](references/internal-procedures/compile-actions/references/notes.md), [references/internal-procedures/compile-actions/references/refresh-and-update.md](references/internal-procedures/compile-actions/references/refresh-and-update.md), [references/internal-procedures/compile-actions/references/structural-challenges.md](references/internal-procedures/compile-actions/references/structural-challenges.md) |
+| Support, duplicate, replacement, conflict, weak evidence, and relation judgment | [references/internal-procedures/compile-judgment.md](references/internal-procedures/compile-judgment.md), [references/internal-procedures/semantic-judgment.md](references/internal-procedures/semantic-judgment.md) |
+| Leakage, ownership, temporal evidence, disposition, omit, and user confirmation | [references/internal-procedures/semantic-judgment/references/leakage-and-ownership.md](references/internal-procedures/semantic-judgment/references/leakage-and-ownership.md), [references/internal-procedures/semantic-judgment/references/temporal-and-evidence.md](references/internal-procedures/semantic-judgment/references/temporal-and-evidence.md), [references/internal-procedures/semantic-judgment/references/disposition-semantics.md](references/internal-procedures/semantic-judgment/references/disposition-semantics.md), [references/internal-procedures/semantic-judgment/references/scope-review-and-omit.md](references/internal-procedures/semantic-judgment/references/scope-review-and-omit.md), [references/internal-procedures/semantic-judgment/references/user-confirmation.md](references/internal-procedures/semantic-judgment/references/user-confirmation.md) |
+| Close gate and current close output boundaries | [references/internal-procedures/close-gate.md](references/internal-procedures/close-gate.md) |
+
+## Compile Contract
+
+The compile action payload uses `schema_version: context.compile-actions.v1`.
+Compile may:
+
+- mirror source spans as `verbatim`;
+- emit `skip` decisions when no source-backed body should be written. `skip`
+  does not produce a placeholder candidate; generated parent-index pages use
+  the parent-index compile path, not an action payload placeholder.
+
+Relationships and cross references do not go into verbatim body. In current
+output they stay in `structure.yaml` typed edges; this workflow does not render
+relationship reference blocks.
+
+</reference>
+
+<procedures>
+
+### Step 1 — Open Compile Context
+
+Run:
+
+```bash
+context run compile:<type>:<source>:<collection> --view read-plan --format json
+```
+
+Use the returned node list, source overview, and next action. If the CLI says
+the structure is missing, unconfirmed, stale, frozen against the wrong
+snapshot, or invalid, return to prose align or source capture as indicated.
+
+### Step 2 — Inspect One Node
+
+For each node that should become draft knowledge, run:
+
+```bash
+context run compile:<type>:<source>:<collection> --view node-context --source <view-ref> --format json
+context run compile:<type>:<source>:<collection> --view schema --format json
+```
+
+Read the compile references listed by `semantic_reference_files` before
+classifying section kind, summary, support, skip/update, weak evidence, or
+structure repair.
+
+Do not treat those references as optional background. They are the current
+compile drafting, judgment, and semantic-repair procedures.
+
+When exact evidence text is needed, use the CLI-returned source ref with the
+current evidence view. Do not open snapshot files directly.
+
+### Step 3 — Draft And Validate Actions
+
+Create a `context.compile-actions.v1` payload for the selected view. Prefer
+omitted `content` with `source_refs[]` so the CLI mirrors source spans.
+If the source evidence is non-contiguous or contains separable examples,
+configuration blocks, lists, or procedures, split the compile actions when the
+confirmed structure supports that split. If the structure is too coarse, return
+to prose align and ask the user to confirm a section split instead of writing
+summarized body text. Explicit `content` / `content_intent` is not part of the
+current compile contract.
+
+For small payloads, use stdin/heredoc. For larger payloads, write a scratch file
+under `.tmp/agent-payloads/<run-id>/` and pass it through `--input`. Scratch
+files are disposable agent working files; they are never compile state and must
+not be read back as a substitute for CLI views.
+
+Validate:
+
+```bash
+context run compile:<type>:<source>:<collection> --validate --input <compile-actions.yaml> --format json
+```
+
+Repair diagnostics by routing them to the right decision:
+
+- source ref or planned-section mismatch -> reread node-context, or return to
+  structure confirmation if ownership is wrong;
+- unsupported kind or op -> use the schema view and current compile references;
+- explicit content -> omit `content` and mirror source, or return to align for
+  a section split;
+- weak evidence, duplicate, conflict, omit, or scope issue -> use the compile
+  judgment / semantic judgment references and ask the user when required;
+- frozen structure mismatch -> rerun status and return to align/capture as
+  directed.
+
+Use typed diagnostics as the repair contract:
+
+- `reason_code`, `path`, and `missing[]` identify what to fix;
+- warnings are not write blockers unless the response marks them blocking or
+  the next action says so;
+- weak evidence, duplicate, conflict, temporal, leakage, ownership, and scope
+  issues are semantic review issues, not formatting problems;
+- raw/source-ref pointer diagnostics are evidence checks, not content-quality
+  judges.
+
+When validation returns a new `next_action.command`, follow that exact command.
+When it returns blocking diagnostics without a write command, repair and
+validate again. Do not stage a compile payload just because the YAML shape looks
+valid.
+
+### Step 4 — Stage Draft Candidates
+
+Stage only after validation has no errors:
+
+```bash
+context run compile:<type>:<source>:<collection> --stage --input <compile-actions.yaml> --format json
+```
+
+After staging, return to `context status`. If status reaches
+`compile-ready-for-review`, delegate review to
+`../skill-review-gate/SKILL.md`.
+
+### Step 5 — Close Handoff
+
+After review apply, return to `context status`. If status says
+`compile-close-needed`, run deterministic close:
+
+```bash
+context close --format json
+```
+
+Close derives `knowledge/structure.yaml` and edge projection from approved
+knowledge, then runs the final verify gate. It must not rewrite approved
+verbatim body. References, changelog, package index, and section fingerprint
+rebuilds are not current close output.
+
+Then route to package output when status reaches `ready-to-build`.
+
+### Step 6 — Self-verify Checklist
+
+- [ ] Compile started from confirmed structure, not a new structure proposal.
+- [ ] Node context and schema came from compile phase views.
+- [ ] Compile references were read before choosing kind/summary/support.
+- [ ] Actions mirror source by default and do not invent body text.
+- [ ] No explicit reader-visible `content` was written by the Agent.
+- [ ] Relationships are expressed as structure edges, not inserted into
+  verbatim text.
+- [ ] No direct edits were made to `sources/`, `.tmp`, `unapproved/`,
+  `knowledge/`, review HTML, or `dist/`.
+
+### Final Report
+
+Report in the user's language. Include only:
+
+- view refs compiled in this round;
+- candidate ids staged and whether they contain verbatim or empty sections;
+- validation warnings that still matter for review;
+- whether review, close, verify, or build is the next status route.
+
+Do not report internal payload digests, source-ref hashes, internal workspace
+paths, absolute paths, scratch file paths, or raw CLI JSON unless the user asks
+for debug output.
+
+</procedures>

package/plugins/cursor/skills/skill-prose-compile/references/internal-procedures/close-gate.md

@@ -0,0 +1,132 @@
+---
+name: close-gate
+description: >
+  Internal procedure invoked by the current compile/continue flow; not a user
+  slash command. Runs after review apply. Triggers `context close --format json`,
+  which derives knowledge/structure.yaml, projects approved edges, and runs the
+  final verify gate. Agent intervention is limited to interpreting CLI output
+  and routing verify errors back to source capture, align structure, compile
+  actions, or review as appropriate. The skill never hand-edits rendered
+  knowledge.
+tools:
+  - Bash
+---
+
+# close-gate — approved structure projection + final verify
+
+Close a compile run. The CLI does the work; the skill reads the
+CLI's output and routes any failure back to the correct upstream
+command. It does not hand-edit rendered knowledge.
+
+## TL;DR — Non-negotiables
+
+- CLI-driven. `context close --format json` derives `knowledge/structure.yaml`,
+  projects approved edges, and verifies the final workspace including edge
+  source refs. Use the command's stdout + exit code; that's the close's full
+  output.
+- **Agent NEVER edits rendered knowledge from the close stage.** The CLI is the
+  sole writer for approved structure projection. If verify reports an error
+  here, route it back, not around:
+  - Content / Section issues → re-run the current compile gate for the affected
+    node after fixing compile actions.
+  - Structural issues → return to the align structure gate and reconfirm.
+  - Source/evidence issues → recapture the affected source, then rerun align or
+    compile as status instructs.
+- Exit 0 → summarise approved node count, approved edge count, structural edge
+  contract status, and verify status. References, changelog, package index,
+  section fingerprints, and full incremental cache rebuilds are not current
+  close output.
+- Exit 2 → report the full issue list verbatim + point at the right re-entry command above. Do not hand-open the affected rendered article.
+- Materialized knowledge means approved Markdown plus its approved
+  `knowledge/structure.yaml` projection. A compile skip action records reviewed
+  evidence, but it does not by itself materialize an arbitrary finalized Node.
+- Never re-run compile actions from close to paper over verify failures. Draft
+  failures belong in the compile loop.
+- Do not use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect `sources/`, `unapproved/`, `knowledge/`, or `dist/` files.
+- Current close can self-heal stale or malformed `knowledge/structure.yaml`
+  projection by deriving it again from approved Markdown and approved edge
+  sources. It must not rewrite verbatim section body.
+- LLM-assisted repair (`--fix-with-llm`) is not a current close action.
+- Output language: summary prose matches the user's language; CLI output, issue codes, file paths stay as printed.
+- Current align state is internal CLI state, not a file protocol. The CLI owns
+  this lifecycle — the agent must not move, delete, or archive workspace output
+  files by hand.
+- Semantic decisions are applied and recorded before close. Compile-close does
+  not judge or rewrite semantic decisions; it only verifies the already-applied
+  workspace and rebuilds approved structure projection.
+
+<reference>
+
+## Stages inside `context close --format json`
+
+Close is one in-process command with one exit code:
+
+1. **Approved knowledge scan** — reads approved Markdown only through CLI
+   project readers.
+2. **Structure projection** — writes deterministic `knowledge/structure.yaml`
+   with nodes, approved edge projection, input hash, and structural edge
+   contract status.
+3. **Workspace verify** — runs the final verify gate. Any error prevents close
+   readiness.
+4. **Status receipt** — reports whether close is ready and which upstream gate
+   owns any failure.
+
+## Outcome routing
+
+| Outcome | Agent action |
+|---|---|
+| Ready, verify pass | Summarise approved nodes, approved edges, structural edge contract, and verify status. Stop. |
+| Ready, verify warnings only | Summarise warning codes and state that build may proceed when warnings are allowed by status/build gate. |
+| Verify error in approved section content/evidence | Surface the issue list and route back to compile actions or source recapture as indicated by status. Do not edit approved Markdown. |
+| Verify error in approved structure projection | Run `context close --format json` once more only when status says the projection is close-repairable; otherwise return to align structure. |
+| Source/evidence stale or missing | Route to source capture/refresh, then rerun align/compile as status instructs. |
+
+The close stage never edits rendered knowledge on the agent side. Every verify
+error routes back to the correct upstream gate (source capture, align
+structure, compile actions, or review), never sideways into a hand Edit. Use
+the CLI issue code and hint printed by `context close --format json` for the
+error→command mapping.
+
+References, changelog, section fingerprints, and package index rebuilds are not
+current close outputs.
+
+</reference>
+
+<procedures>
+
+### Step 1 — Invoke close
+
+Run `context close --format json`. The caller may have already invoked it;
+check for existing output before re-running.
+
+### Step 2 — Interpret
+
+Use stdout + stderr. The exit code selects the path via [Outcome routing](#outcome-routing).
+
+### Step 3 — Route errors to the correct upstream command
+
+For each error in the CLI's report, classify via [Outcome routing](#outcome-routing) and name the re-entry command in your report. Do NOT hand-edit rendered knowledge — that violates the CLI-sole-writer principle and masks the real upstream fix. Specifically:
+
+- Section / content issue → rerun the current compile gate for that node.
+- Structure issue → return to align structure and user confirmation.
+- Source/evidence issue → recapture the affected source, then rerun align or
+  compile as status instructs.
+
+One pass. If the CLI reports multiple errors, list them all and let the user choose the order; do not loop the close stage itself.
+
+### Step 4 — Report
+
+Summarise in the user's language:
+
+- Approved node count.
+- Approved edge count and structural edge contract status.
+- Verify result: pass / pass-with-unverifiable-evidence / fail, with issue
+  codes verbatim.
+
+Stop. Do not auto-invoke follow-on commands.
+
+### Step 5 — Final guardrails
+
+Run close once, surface every error with its re-entry command, and never inspect or edit rendered knowledge outside the CLI.
+
+</procedures>