@c4a/context-cli 0.6.1 → 0.6.3

package/plugins/claude/skills/skill-package-output/SKILL.md

@@ -1,180 +0,0 @@
----
-name: skill-package-output
-description: >
-  Internal procedure invoked by the public Context continuation entry; not a user slash command.
-  Explains package output choices, prefers kb packages, declares selected
-  package builders, builds, and inspects generated package structure.
-tools:
-  - Bash
----
-
-# skill-package-output
-
-Choose and build a package output from approved knowledge.
-
-## TL;DR
-
-- Package output is a human choice. Do not add package builders just because an
-  example exists.
-- In explicitly authorized current-conversation fully managed mode, resolve
-  this choice from the user's stated deliverable: use an agent knowledge-base
-  package for an Agent-facing knowledge workspace, an LLM text bundle only
-  when a text/RAG bundle was requested, and skip only when the user asked to
-  keep approved Markdown without a package. Do not persist this preference.
-- Recommend an agent knowledge-base package first for agent consumption.
-- Present an LLM text bundle as an alternative for a single text/RAG import
-  bundle.
-- Do not use `kbPackage()` or `llmsPackage()` as user-facing option labels.
-  Mention those API names only after the user chooses an output shape.
-- Do not offer `both` as a shortcut. Add one output, build, inspect, then ask
-  before adding another.
-- Build happens after review and deterministic close. If status says
-  `compile-close-needed`, run `context close --format json` before build.
-- Package templates may customize navigation and query guidance, but coverage,
-  gap, scope, or known-limit claims must cite approved knowledge,
-  `knowledge/structure.yaml`, or `context-build-inventory.json`.
-- Generated package structure, not `context build` alone, proves usability.
-
-<reference>
-
-## Output Shapes
-
-Recommended first output:
-
-```text
-dist/<name>-kb/
-├── AGENTS.md
-├── skills/
-│   └── knowledge-query/
-│       └── SKILL.md
-└── wikis/
-    ├── index.md
-    ├── <group>/
-    │   ├── index.md
-    │   └── ...
-    └── ...
-```
-
-Alternative:
-
-```text
-dist/<name>-llms/
-└── llms.txt
-```
-
-</reference>
-
-<procedures>
-
-### Step 1 — Read Package Docs
-
-Before editing package declarations or templates, read:
-
-```text
-node_modules/@c4a/context/docs/guides/package-outputs.md
-node_modules/@c4a/context/docs/reference/package-templates.md
-```
-
-### Step 2 — Explain The Choice
-
-Explain in the user's conversation language:
-
-- an agent knowledge-base package creates copied approved knowledge pages and
-  reusable query guidance under `dist/<name>-kb/`;
-- the default `knowledge-query` skill teaches agents how to query and cite those
-  copied approved knowledge pages;
-- the kb template must keep `wikis/index.md` as the OKF bundle entry page;
-- the default `wikis/index.md` is intentionally shallow: it describes the
-  bundle and links to next-level directories;
-- `context build` maps internal production collections into OKF roots and
-  generates child directory indexes such as `<okf-root>/<group>/index.md`, so
-  users can browse from OKF root -> group -> page; `wikis/index.md` is the
-  required default OKF root entry, while selected `guides/`, `rules/`, or
-  `feats/` roots get their own indexes too;
-- the exact mapping is `codegraph`/`business`/`product` -> `wikis/`,
-  `architecture`/`sop`/`faq`/`decision`/`incident` -> `guides/`,
-  `standards`/`test` -> `rules/`, and `feats` -> `feats/`;
-- `wikis/` is the structured entity-and-relationship layer; guides and rules
-  may explain, operationalize, or constrain it, but co-location does not prove
-  a relationship;
-- an LLM text bundle creates one text/RAG import bundle under
-  `dist/<name>-llms/`;
-- the user can customize `src/package-templates/kb/` before build;
-- template variables and examples are documented in
-  `node_modules/@c4a/context/docs/reference/template-variables.md`;
-- build writes a package inventory such as `context-build-inventory.json`, which
-  templates may cite when describing package coverage. Its edge section reports
-  the structural edge contract and the evidence status from `context verify`;
-- the user can skip package output for now and keep only `knowledge/`.
-
-Outside managed mode, ask which single output to create first using the host's
-native multi-choice tool when available. Use semantic option labels:
-
-- Agent knowledge-base package: for agents to query and cite approved knowledge pages.
-- LLM text bundle: for one text/RAG import bundle.
-- Skip package output for now: keep approved Markdown only.
-
-### Step 3 — Declare The Selected Package
-
-After the user chooses, read the template variable guide if the template needs
-navigation changes:
-
-```text
-node_modules/@c4a/context/docs/reference/template-variables.md
-```
-
-Then edit `src/index.ts` and package templates according to the SDK docs. For
-kb output, prefer a clear package name such as `<source-name>-kb`.
-
-### Step 4 — Build And Inspect
-
-If status says close is required, run:
-
-```bash
-context close --format json
-```
-
-Do not build from unclosed approved knowledge.
-
-Run:
-
-```bash
-context build
-```
-
-Inspect the generated `dist/<name>-kb/` or `dist/<name>-llms/` structure against
-[Output Shapes](#output-shapes). For kb packages, inspect every selected
-OKF root that appears in `context-build-inventory.json`, not only
-`wikis/`.
-If templates are placeholders or knowledge pages are thin, say that plainly and
-stop for user direction.
-
-If build reports that a template path collides with copied knowledge, do not
-retry blindly. Explain that template files and selected knowledge cannot render
-to the same path, then rename the template file or ask whether to exclude that
-knowledge path.
-
-If build reports a template-boundary diagnostic, repair the template by
-referencing approved knowledge, `knowledge/structure.yaml`, or
-`context-build-inventory.json` for coverage/gap/scope/known-limit statements.
-Do not patch `dist/` as the durable fix; edit the template under
-`src/package-templates/`.
-
-### Step 5 — Self-verify Checklist
-
-- [ ] The user selected the package output, or explicit current-conversation
-  managed mode resolved it from the stated deliverable. If not, return to
-  **Step 2**.
-- [ ] Only one output was added first. If not, ask before continuing with more.
-- [ ] A kb package template contains `wikis/index.md` and at least one
-  `SKILL.md`.
-- [ ] For kb output, the generated OKF root indexes link to next-level
-  directories, and child directory indexes exist when selected knowledge has
-  subdirectories.
-- [ ] Template paths do not collide with copied knowledge paths.
-- [ ] Template coverage/gap/scope/known-limit claims cite approved knowledge,
-  `knowledge/structure.yaml`, or build inventory.
-- [ ] Generated structure was inspected after build. If not, return to
-  **Step 4**.
-
-</procedures>

package/plugins/claude/skills/skill-prose-align/SKILL.md

@@ -1,322 +0,0 @@
----
-name: skill-prose-align
-description: >
-  Internal procedure invoked by the public Context continuation entry; not a user slash command.
-  Uses Context document evidence views to propose, validate, and confirm
-  `unapproved/structure.yaml` without reading raw snapshots directly.
-tools:
-  - Bash
----
-
-# skill-prose-align
-
-Turn captured document evidence into confirmed structure.
-
-## TL;DR
-
-- Use this after document capture, or when the user asks to split, merge,
-  reorganize, classify, or relate document evidence.
-- When status is `captured-ready-to-classify`, run every returned capture-phase
-  evidence command before editing `src/index.ts`. Use the collection-neutral
-  title tree, span index, and exact text to propose a mainline collection; wait
-  for user confirmation, then declare matching align/compile/review phases.
-- The first product output is a structure draft, not final page body.
-- Read source material only through CLI evidence views: `read-plan`,
-  `source-index`, `span-detail`, `span-text`, `schema`, and
-  `structure-summary`. Additional views are diagnostic surfaces; use the route
-  and view set returned by the CLI.
-- Write and validate `context.structure.v1` into `unapproved/structure.yaml`.
-  Stop for user confirmation before compile.
-- Before semantic judgment, use the CLI `semantic-rules` View to page through
-  only `semantic_rules.required`. Use each selection `reason` to keep unrelated
-  rules out of the current judgment.
-- Plan source evidence as Sections before promoting any heading to a Node/View.
-  Promotion depends on source-backed standalone retrieval identity, not on a
-  hard-coded section kind or collection name.
-- Do not produce or validate a structure payload from this entry file alone. A
-  ruleset already present in the active context may be reused only when both its
-  `handle` and `digest` match. If the context was compacted, the digest changed,
-  or the rule content is no longer present, resume the CLI rule-page sequence.
-- When status reaches `structure-ready` or `needs-prose-compile`, hand off to
-  `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.md`.
-- Compile, review, close, verify, and build remain separate gates.
-
-<reference>
-
-## User-Facing Gates
-
-Use semantic labels, not SDK function names:
-
-| Gate | Say this | Do not say this first |
-|---|---|---|
-| Collection classification | "I have inspected the captured evidence. Based on these source characteristics, I recommend this knowledge category; please confirm before I configure compilation." | Guessing from a filename, URL, or SDK collection enum before investigation |
-| Material investigation | "I will read the evidence index and source spans through Context, then propose a structure draft." | `alignProse`, `source-index`, `context.structure.v1` |
-| Structure confirmation | "Confirming this structure freezes page paths, section ownership, and relationships for this compile round." | `unapproved/structure.yaml` as a raw parameter |
-| Compile handoff | "The structure is confirmed; I will switch to source-bound compile for draft pages." | Continuing to edit structure in compile |
-
-## Runtime Discipline
-
-`skill-continue-workflow` owns global state routing; this Skill owns only the
-align phase selected by that route. Use CLI evidence/rule/diagnostic Views,
-follow their exact continuation commands, and treat hints as subordinate to
-`next_action`. Evidence reads may be parallel; stage, confirm, Review apply,
-close, and build writes remain serial. Never reconstruct digest values or
-inspect CLI-managed state files as a substitute for a View.
-- 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/`, or package output directories.
-- If a validation or view response includes `reason_code`, `path`, `missing[]`,
-  `diagnostics`, `repair_hints`, or `agent_hints`, treat those fields as the
-  repair contract. Do not recover by replaying a stale manual route, editing
-  rendered files, or guessing schema aliases.
-
-## Evidence Views
-
-Recommended read order:
-
-```bash
-context run align:<type>:<source>:<collection> --view read-plan --format json
-context run align:<type>:<source>:<collection> --view source-index --compact --format json
-context run align:<type>:<source>:<collection> --view span-detail --span <source-ref> --format json
-context run align:<type>:<source>:<collection> --view span-text --span <source-ref> --format json
-context run align:<type>:<source>:<collection> --view schema --format json
-context run align:<type>:<source>:<collection> --view structure-summary --input <structure.yaml> --format json
-```
-
-Use CLI-returned `next_command` values for pagination. Do not reconstruct
-documents with ad hoc `cat`, `grep`, or scripts against `sources/` or `.tmp`.
-
-## Structure Contract
-
-The structure draft uses `schema_version: context.structure.v1` and lives at
-`unapproved/structure.yaml` after staging. It contains:
-
-- lifecycle state such as validated/confirmed and frozen snapshot metadata;
-- concept `nodes[]` with stable `node_ref`, `node_type`, title/summary, and
-  ownership;
-- materialized `views[]` with `view_ref`, collection, path, section plans, and
-  evidence refs;
-- typed edges using the closed set defined by the CLI;
-- unresolved items when evidence is weak, conflicting, or the target node is
-  missing.
-
-Confirmed structure is a human gate. Validation passing is not the same as
-confirmation. Do not write `lifecycle.state: confirmed`, `confirmed_by`,
-`confirmed_at`, or `structure_digest` until the user has explicitly confirmed
-the structure proposal in the conversation.
-
-When the current conversation explicitly authorizes fully managed operation,
-use the CLI-returned `--stage --managed` command after successful validation.
-The CLI records `confirmed_by: managed-session`; validation errors and unresolved
-evidence still block confirmation. Never persist managed mode in `defineProject`
-or reuse it in another conversation.
-
-## Procedure References
-
-These are current structure planning rules. They define the source-bound
-semantic gates for Node planning, section ownership, and relationship handling.
-
-| Decision | Reference |
-|---|---|
-| Structure planning, Node ownership, density, candidate resolution | [references/internal-procedures/structure-planning.md](references/internal-procedures/structure-planning.md) |
-| Node type, title, tags, fake entity, action/domain gates, edge gates | [references/internal-procedures/structure-planning/references/gates.md](references/internal-procedures/structure-planning/references/gates.md) |
-| Source density and coarse reading judgment | [references/internal-procedures/structure-planning/references/density-profile.md](references/internal-procedures/structure-planning/references/density-profile.md) |
-| Candidate anomalies, stable ids, paths, duplicates, and conflicts | [references/internal-procedures/structure-planning/references/candidate-resolution.md](references/internal-procedures/structure-planning/references/candidate-resolution.md) |
-
-</reference>
-
-<procedures>
-
-### Step 1 — Open Material Investigation
-
-Run:
-
-```bash
-context run align:<type>:<source>:<collection> --view read-plan --format json
-```
-
-Use the returned views, budgets, snapshot hash, and next actions. If the CLI
-reports a missing or stale snapshot, route back to source capture/refresh. Do
-not read the snapshot file yourself.
-
-### Step 2 — Read Evidence Through The Index
-
-Read a compact index before requesting exact spans:
-
-```bash
-context run align:<type>:<source>:<collection> --view source-index --compact --format json
-```
-
-For exact evidence, copy CLI-returned source refs or next commands:
-
-```bash
-context run align:<type>:<source>:<collection> --view span-detail --span <source-ref> --format json
-context run align:<type>:<source>:<collection> --view span-text --span <source-ref> --format json
-```
-
-Keep a short note of what evidence supports each proposed node, section, and
-edge. If the evidence is weak or conflicting, keep it as unresolved instead of
-turning it into a fact.
-
-Before drafting structure, read:
-
-- [references/internal-procedures/structure-planning.md](references/internal-procedures/structure-planning.md)
-- [references/internal-procedures/structure-planning/references/gates.md](references/internal-procedures/structure-planning/references/gates.md)
-- [references/internal-procedures/structure-planning/references/density-profile.md](references/internal-procedures/structure-planning/references/density-profile.md)
-- [references/internal-procedures/structure-planning/references/candidate-resolution.md](references/internal-procedures/structure-planning/references/candidate-resolution.md)
-
-Do not treat this as optional background. These files contain the current
-semantic gates for source-bound structure planning. A structure payload drafted
-without the applicable references is incomplete, even if the CLI schema accepts
-its shape.
-
-### Step 3 — Draft And Validate Structure
-
-Request the schema:
-
-```bash
-context run align:<type>:<source>:<collection> --view schema --format json
-```
-
-Create a `context.structure.v1` YAML file. The draft may include a one-page-per
-source shape, but that is represented as ordinary nodes and sections; it does
-not bypass structure confirmation.
-
-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 phase state and
-must not be read back as a substitute for CLI views.
-
-Validate:
-
-```bash
-context run align:<type>:<source>:<collection> --validate --input <structure.yaml> --format json
-```
-
-Validation returns a compact summary and writes a temporary HTML report under
-`.tmp/context-runtime/reports/`. A validation report with
-`confirmation_ready=false` is an Agent repair artifact, not a user review gate:
-do not ask the user to approve it. The staged report produced after
-`confirmation_ready=true` is the final review surface; use its
-`structure_report.file_url` as the primary user-facing link and include
-`structure_report.absolute_path` as a copyable fallback.
-If the user needs a focused view, run:
-
-```bash
-context run align:<type>:<source>:<collection> --view structure-summary --input <structure.yaml> --format json
-```
-
-The explicit `structure-summary` View returns the full summary for focused
-debugging. For user confirmation, prioritize the default first-screen fields:
-`review_notice`, `structure_report`, and `structure_summary_compact`. A valid
-user-facing confirmation prompt must include the report `file_url`, the absolute
-path fallback, and a compact summary of collections/views/unresolved/diagnostics.
-Do not ask the user to confirm from counts alone.
-
-Repair diagnostics by routing them to the right decision:
-
-- source ref or snapshot mismatch -> reread evidence views or refresh capture;
-- unsupported node/section/edge -> remove it or mark unresolved;
-- duplicate/conflict -> ask the user which structure should win;
-- illegal edge type, missing target node, or edge without source refs -> fix the
-  structure or keep the relation unresolved;
-- stale structure -> regenerate from the current snapshot hash.
-
-When validation returns `repair_confirmation_blockers`, follow its exact repair
-route without stopping for human confirmation. `--repair suggested-splits`
-mechanically splits non-contiguous source mirror Sections; write its
-`repaired_payload` to a scratch YAML file and validate again. For oversized
-Views, use the returned child-View and contains-edge suggestions, but classify
-each child Node from evidence instead of mechanically inheriting the parent
-type. Repair other diagnostics from evidence and validate again. Ask the user only when evidence
-supports multiple incompatible semantic choices, and label that question as a
-structure-design choice rather than final review. Do not stage until
-`confirmation_ready=true`.
-
-### Step 4 — Review Structure Before Confirmation
-
-After validation reports `confirmation_ready=true`, stage the draft. The stage
-command opens the final report. Then show the user:
-
-- node list and planned paths;
-- section ownership;
-- typed edges and unresolved relation candidates;
-- expected compile order;
-- downstream impact: these choices freeze paths, section ownership, and
-  relationships for this compile round.
-- the `structure_report.file_url` generated by validate or `--view
-  structure-summary`;
-- the `structure_report.absolute_path` fallback in case the host cannot click
-  file URLs.
-
-If the CLI stage result includes `next_action.human_gate: true`, treat it as a
-hard stop for structure review. Do not ask for a blind "confirm structure"
-reply. Surface the report `file_url`, absolute path, and enough structured
-summary for the user to inspect what will be confirmed.
-
-Do not turn `confirmation_blockers` into a preliminary approval round. A
-validator-required page split, continuous-source split, ref repair, or
-structure-spine connection is work to resolve before staging. If a genuinely
-ambiguous semantic choice needs the user, ask only that choice and then resume
-repair; it does not replace the final report-based confirmation.
-
-Use the host's multi-choice question tool when available. If unavailable, use a
-short Markdown fallback. Good options are:
-
-- Confirm this structure and continue to compile.
-- Revise the structure with additional guidance.
-- Go back to source scope or capture because the evidence set is wrong.
-
-Only after confirmation, run the CLI confirmation command, normally:
-
-```bash
-context run align:<type>:<source>:<collection> --confirm --format json
-```
-
-If confirming a structure file other than `unapproved/structure.yaml`, pass it
-with `--input <structure.yaml>`. A draft stage in `unapproved/structure.yaml` is
-not confirmation. Do not edit `unapproved/structure.yaml` after confirmation to
-change meaning; return to this gate instead.
-
-### Step 5 — Handoff To Compile
-
-After the user confirms the structure and the CLI reports `structure-ready` or
-`needs-prose-compile`, stop this procedure and follow:
-
-```text
-${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.md
-```
-
-Do not keep editing structure while compiling. If compile diagnostics show the
-planned structure is wrong, return to this align gate and ask the user to
-confirm the corrected structure.
-
-### Step 6 — Self-verify Checklist
-
-- [ ] Evidence came only from Context evidence views.
-- [ ] `context.structure.v1` was validated before user confirmation.
-- [ ] User confirmed the structure before compile.
-- [ ] Compile was delegated to `skill-prose-compile`; this procedure did not
-  write draft page body.
-- [ ] Relationships are expressed as structure edges or unresolved items.
-- [ ] No direct edits were made to `sources/`, `.tmp`, `unapproved/`,
-  `knowledge/`, review HTML, or `dist/`.
-
-### Final Report
-
-Report in the user's language. Include only:
-
-- evidence views actually read;
-- proposed and confirmed node count, section count, edge count, and unresolved
-  count;
-- user confirmation outcome;
-- validation warnings that still matter for compile;
-- next route reported by status or the align phase.
-
-Do not report payload digests, snapshot hashes, source-ref hashes, absolute
-paths, or scratch file paths unless the CLI explicitly asks the user to repair
-one.
-
-</procedures>