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

package/plugin/commands/continue.md

@@ -0,0 +1,34 @@
+---
+description: "Inspect the Context workspace, decide the next useful action, and proceed."
+argument-hint: "[user intent]"
+allowed-tools: Bash(context:*), Bash(bun:*), Bash(cd *)
+---
+
+## Your Task
+
+Use this as the conversational entry for an existing Context workspace. There is
+no `context continue` CLI primitive; the command runs lower-level `context ...`
+commands only when the workspace state requires them.
+
+If the user is starting a new workspace or a new batch from a raw repository
+root, do not run `context status` first. Use the public Context init entry or
+`context init` to create the workspace, complete the init setup command, then
+return here from the initialized workspace.
+
+If `context status` reports `workspace-not-found` and points at a configured
+`context.workspaceDir`, do not keep working from the host repository root. Enter
+that workspace when it exists, or initialize it through the init workflow after
+confirming with the user.
+
+Language policy: explain, ask, confirm, and summarize in the user's current
+conversation language. Keep CLI commands, flags, paths, ids, status enum values,
+JSONL payload keys, `source_ref` values, and copied CLI output tokens unchanged.
+
+Use the internal `context:skill-continue-workflow` procedure end to end. It owns the
+status loop, safe mechanical next steps, source/scope gate, review gate, package
+gate, and final report rules.
+
+Do not infer repo sources, extraction scope, review decisions, or package output
+choices from surrounding files. Do not call source-repo operations such as
+clone, checkout, reset, fetch, install, build, or test without explicit user
+approval.

package/plugin/commands/init.md

@@ -1,138 +1,21 @@
 ---
-description: "Initialize a context workspace in the current directory."
-argument-hint: "[name] [--layout embedded|root] [--language <text>] [--with-aspects <names>] [--with-all-aspects] [--minimal|--no-aspects] [--focus <text>]"
-allowed-tools: Bash(context:*)
+description: "Initialize a Context knowledge workspace."
+argument-hint: "[project-dir] [--name <name>]"
+allowed-tools: Bash(context:*), Bash(bun:*), Bash(cd *)
 ---
 
-<!--
-This command has no companion skill. Its protocol (the focus multi-choice
-UX before `context init` runs) lives inline here per the slash-command
-length exemption for self-contained slash commands.
--->
-
 ## Your Task
 
-Initialize a context workspace, including layout, default-language, and focus confirmation before creating it.
-
-Language rule: ask every question, option label, option description, and final summary in the user's current conversation language. The English question blocks below are semantic templates, not text to copy unless the conversation itself is English. Keep CLI tokens, file paths, aspect names, and stored values such as `Chinese`, `English`, `embedded`, and `root` unchanged.
-
-### Step 1 — Ask about workspace layout (unless `$ARGUMENTS` already has `--layout`)
-
-Use the host's native multi-choice tool when available (Claude Code `AskUserQuestion`, Codex `ask_user_question`, Cursor Plan Mode `AskQuestion`); fall back to markdown choices otherwise.
-
-Question shape. Do not expose `embedded` / `root` as user-facing option labels; those are CLI tokens only. Translate the user-facing labels and descriptions:
-
-```
-Q. Where should C4A store this workspace?
-  A. Default (.context/) — create a `.context/` data directory inside the current project. (Recommended)
-  B. Current directory — use the current directory itself as the C4A data root.
-```
-
-Explain the tradeoff in the user's conversation language before asking:
-- Default (`.context/`) is for normal code repositories; C4A files live under `.context/`.
-- Current directory is only for a dedicated knowledge repository. The current directory must not already contain `.context/`, `config.yaml`, `raw/`, `knowledge/`, `output/`, `aspects/`, or `inbox/`. Existing `AGENTS.md` / `CLAUDE.md` in the selected C4A data root are kept rather than overwritten.
-
-Map the answer to CLI flags:
-- Default (`.context/`) → pass `--layout embedded`
-- Current directory → pass `--layout root`
-
-### Step 2 — Ask about default language (unless `$ARGUMENTS` already has `--language`)
-
-Ask one multi-choice question in the user's conversation language:
-
-```
-Q. What default language should agents use for user-facing replies in this workspace?
-  A. 中文 — maps to `Chinese`
-  B. English
-  C. Other — please describe.
-```
-
-The option label must be localized, but the stored CLI value should remain stable. Pass the answer as `--language Chinese`, `--language English`, or quote custom text as `--language '<custom text>'`.
-
-### Step 3 — Ask about workspace focus (unless user already passed `--focus`)
-
-Before running `context init`, ask the user **one** multi-choice question about the workspace's focus (the primary intent of this knowledge base). Use the host's native multi-choice tool when available (Claude Code `AskUserQuestion`, Codex `ask_user_question`, Cursor Plan Mode `AskQuestion`); fall back to markdown `A/B/C/D` choices otherwise. Keep it to one question with 2–4 options plus "Other" escape hatch; never dump 5+ at once.
-
-The question shape (translate all user-facing text to the user's conversation language; keep machine tokens English):
-
-```
-Q. What will this workspace mainly hold?
-  A. Business product/R&D knowledge base — business architecture, requirements,
-     technical architecture, business modules and their supporting tech.         (Recommended)
-  B. Team technical knowledge base — tech stack, infra tools, conventions,
-     operations, decisions, on-call memos, etc.
-  C. Product / project user manual — user-facing intro, guides, handbook, Q&A.
-  D. Research / learning library on a topic — framework comparisons, selection
-     notes, wiki-style reading notes.
-  E. Other — please describe.
-```
-
-Interpret the answer:
-- When appending generated or user-provided free text to the shell command, quote it with POSIX single quotes. If the text contains a single quote, escape it as `'\''`; do not use double quotes for free-form values.
-- Chose A–D → generate a 2–3 line focus description in the user's language. Phrase it as
-  "primarily X; supporting materials such as Y may also be filed here" rather than exclusion
-  language — workspaces absorb auxiliary material in practice. Show the exact generated focus
-  text to the user and ask for one confirmation before running `context init`. If the user
-  approves, pass it as `--focus '...'`; if the user edits it, pass the edited text as
-  `--focus '...'`; if the user declines or says to skip, run without `--focus`.
-- Chose E or described freely → pass the user's text verbatim as `--focus '...'`.
-- User says "skip" / "don't care" → run `context init` without `--focus`.
-- `$ARGUMENTS` already contains `--focus <text>` → skip this step entirely.
-
-### Step 4 — Choose aspects (unless `$ARGUMENTS` already has aspect flags)
-
-Skip this step if `$ARGUMENTS` already includes `--with-aspects`, `--with-all-aspects`, `--minimal`, or `--no-aspects`.
-
-If the user request names specific aspects, map that directly:
-- "only code aspect" / "仅启用 code aspect" → append `--with-aspects code`
-- "all aspects" / "全部 aspect" → append `--with-all-aspects`
-- "no aspects" / "不安装 aspect" / "minimal" → append `--no-aspects`
-
-Otherwise ask **one** short single-choice question. Keep the option count to three or fewer; host question tools reject longer option lists. Use the host's free-text `Other` escape hatch when the user needs a custom comma-separated aspect list.
-
-```
-Q. Which aspects should be installed?
-  A. code — scripted local source-code capture. (Recommended)
-  B. all built-in aspects — code, design-system, openapi, graphql.
-  C. skip — install no aspects now; add later with `context init --with-aspects <name>`.
-```
-
-Hard rules when mapping into the host UI:
-
-- Do not present separate options for every built-in aspect; that exceeds host option limits once `skip` is included.
-- Put `code` first and mark it as recommended.
-- Treat the host auto-injected `Other` as a free-text custom list such as `code,openapi`, not as "skip".
-
-Map the answer:
-
-- `code` selected → append `--with-aspects code`.
-- `all built-in aspects` selected → append `--with-all-aspects`.
-- `skip` selected → append `--no-aspects`.
-- Host auto-injected `Other` selected → parse the user's comma-separated aspect names and append `--with-aspects <names>`. If the custom text is empty or invalid, ask once for clarification rather than silently installing all aspects.
-
-Do not silently install all aspects when the user asked for a code-only workspace.
-
-### Step 5 — Run init
-
-Run `context init $ARGUMENTS` with the selected `--layout`, `--language`, `--focus`, and aspect flags appended when those flags were not already present. The CLI handles skeleton build, `.gitignore`, `AGENTS.md`, `CLAUDE.md -> AGENTS.md`, and aspect templates inside the selected C4A data root.
-
-If the CLI errors (e.g. an existing workspace without `--with-aspects`, or root layout blockers), surface the error and the CLI's remediation hint.
-
-To add aspects later in an existing workspace, run `context init --with-aspects <name>` from the workspace root. Use comma-separated names for multiple aspects, for example `context init --with-aspects code,openapi`. Append mode only copies missing aspect templates and does not rewrite workspace config, raw data, or knowledge.
-
-### Step 6 — Summarize
+Initialize a Context workspace with the global CLI, then continue only through
+safe mechanical setup steps until the first human decision gate.
 
-Briefly state in the user's conversation language:
-- Workspace name
-- Layout and data root
-- Default language
-- Installed aspects
-- Whether `AGENTS.md` was created and whether `CLAUDE.md` was linked
-- If the user asks to read the generated workspace instructions, run `context workspace read AGENTS.md --format text`; do not open the data-root file with generic file tools.
-- Whether focus was recorded (show the first line if yes; mention the user can edit `config.yaml` later if not)
-- If the CLI prints a Claude local permission hint, tell the user that `Bash(context:*)` is the recommended scoped allow for heredoc-heavy context workflows. Do not edit `.claude/settings.local.json` unless the user explicitly asks.
-- Suggest `/context:capture` as the natural next step
+Language policy: explain, ask, confirm, and summarize in the user's current
+conversation language. Keep CLI commands, flags, file paths, package names,
+enum values, payload keys, and copied CLI output tokens unchanged.
 
-CLI output, file paths, aspect names, flags, and command names stay as printed.
+Use the internal `context:skill-init-workspace` procedure end to end. It owns
+the `context init` invocation, dependency install follow-up, generated
+`AGENTS.md` handoff, status handoff, and stop conditions.
 
-Do NOT read, write, link, or edit workspace files yourself during init — the CLI is the sole writer for skeleton files, `AGENTS.md`, and `CLAUDE.md`.
+Do not add extra project-local agent setup. Do not infer repo sources or
+extraction scope from the surrounding monorepo after setup.

package/plugin/skills/skill-continue-workflow/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: skill-continue-workflow
+description: >
+  Internal procedure invoked by the public Context continuation entry; not a user slash command.
+  Runs the status-driven Context process, executes safe mechanical next steps,
+  and delegates human gates to source, review, and package procedures.
+tools:
+  - Bash
+---
+
+# skill-continue-workflow
+
+Continue an existing Context workspace from its current state.
+
+## TL;DR
+
+- Use this only inside an initialized Context workspace. If the user is starting
+  a new knowledge workspace or a new batch from a raw project/repo root, do not
+  run `context status` first; use the init workflow and complete setup before
+  returning here.
+- If `context status` reports `workspace-not-found` with a configured
+  `context.workspaceDir`, stop. If the directory exists, enter it and rerun
+  status. If it does not exist, ask whether to initialize it through the init
+  workflow; do not treat the host repository root as the workspace.
+- There is no `context continue` CLI command. Start with `context status`.
+- `context status` and CLI diagnostics are the source of truth.
+- Execute safe mechanical `next:` steps; stop at semantic choices and human
+  gates.
+- Delegate source/scope decisions to
+  `${CLAUDE_PLUGIN_ROOT}/skills/skill-source-scope/SKILL.md`.
+- Delegate review to `${CLAUDE_PLUGIN_ROOT}/skills/skill-review-gate/SKILL.md`.
+- Delegate package output choices to
+  `${CLAUDE_PLUGIN_ROOT}/skills/skill-package-output/SKILL.md`.
+- Delegate document investigation and structure confirmation to
+  `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-align/SKILL.md`.
+- Delegate source-bound prose compile requests to
+  `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.md`.
+- Do not inspect `.tmp`, `unapproved/`, `knowledge/`, `dist/`, or
+  `node_modules/@c4a/context/dist` with ad hoc scripts to decide project state.
+- Only run commands surfaced by the current status route, current phase view,
+  review gate, verify/build gate, or package guidance. Do not invent alternate
+  lifecycle commands from memory.
+
+<reference>
+
+## Safe Mechanical Commands
+
+These can run when already implied by current status and no placeholder/human
+choice remains:
+
+| State / hint | Allowed action |
+|---|---|
+| source already declared | `context source ensure`, `context source list`, `context source get` |
+| declared phase that does not read new source body or require a semantic choice | `context run <phase-id>` |
+| prose align evidence read | `context run align:<type>:<source>:<collection> --view <view>` |
+| prose structure validation | `context run align:<type>:<source>:<collection> --validate --input <structure.yaml>` |
+| prose compile evidence read | `context run compile:<type>:<source>:<collection> --view <view>` |
+| prose compile action validation | `context run compile:<type>:<source>:<collection> --validate --input <compile-actions.yaml>` |
+| copied review payload supplied by user | `context review apply <payload-file>` |
+| close required after review | `context close --format json` |
+| package already declared and close is clean | `context build` |
+| validation requested | `context verify` |
+
+Capture phases are not safe mechanical commands by default. `capture:file:*`
+and `capture:lark:*` read local or remote source bodies and update committed
+snapshots, so they require the source read-permission gate unless the current
+turn already contains explicit user confirmation for that exact source.
+
+## Human Gates
+
+Stop and ask, or wait for user input, for:
+
+- `Human gate:` in CLI output.
+- placeholders such as `<name>`, `<repo-or-subdir>`, `<phase-id>`, `<collection>`.
+- missing source selection.
+- source boundary/name decisions, because they affect `knowledge/` paths and
+  `source_ref` prefixes.
+- source repo operations: clone, checkout, reset, fetch, install, build, test.
+- source scope, package/subdirectory, symbol group, or glob choices.
+- file/Lark capture or refresh, including capture preview, until the user has
+  confirmed which local path or remote document may be read.
+- review approval/rejection decisions.
+- document structure confirmation, section ownership, edge confirmation,
+  rewrite intent, conflict, weak-evidence, or cross-document organization
+  choices unless they are being handled through prose align/compile evidence
+  views and validation.
+- package output type or template choices.
+
+When a human gate has a fixed small option set, use the host's native
+multi-choice tool when available (Claude Code `AskUserQuestion`, Codex's
+available native user-input tool such as `request_user_input` when exposed,
+Cursor Plan Mode `AskQuestion`). If unavailable, fall back to Markdown `A/B/C`
+choices. Each option must include the effect of choosing it.
+
+</reference>
+
+<procedures>
+
+### Step 0 — Confirm Workspace Exists
+
+If the current task is to create a new Context workspace, or the user has not
+identified an initialized Context workspace root for this turn, do not continue
+with this workflow. Initialize through the public Context init entry or
+`context init` first, run the setup command printed by init, then return to this workflow from the
+created workspace.
+
+### Step 1 — Read Status
+
+Run:
+
+```bash
+context status
+```
+
+Use the output as evidence. Explain status and next step in the user's language;
+do not forward a long raw transcript unless requested.
+
+### Step 2 — Route The State
+
+1. If status says `missing-source` or `needs-capture`,
+   source boundary/name is unclear, source scope is unclear, or an extract
+   phase needs first-run scope confirmation, follow
+   `${CLAUDE_PLUGIN_ROOT}/skills/skill-source-scope/SKILL.md`.
+2. If status says `captured-ready-to-investigate` or `needs-structure`, or the
+   user asks to split, merge, classify, relate, or semantically organize
+   document evidence before draft pages exist, follow
+   `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-align/SKILL.md`.
+3. If status says `needs-prose-compile` or `structure-ready`, or the user asks
+   to turn confirmed structure into source-bound draft pages, follow
+   `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.md`.
+4. If status says `compile-ready-for-review` or review is needed, follow
+   `${CLAUDE_PLUGIN_ROOT}/skills/skill-review-gate/SKILL.md`.
+5. If status says `compile-close-needed`, run `context close --format json`
+   unless CLI diagnostics require human repair, then return to **Step 1**.
+6. If status says `ready-to-build`, `built`, `needs-package-output`, or approved knowledge exists but
+   package output is not chosen or declared,
+   follow `${CLAUDE_PLUGIN_ROOT}/skills/skill-package-output/SKILL.md`.
+7. If the next command is safe per [Safe Mechanical Commands](#safe-mechanical-commands),
+   run it and return to **Step 1**.
+8. If the next command crosses a [Human Gate](#human-gates), ask or wait; do not
+   guess.
+
+### Step 3 — Execute Safely
+
+Before editing `src/index.ts` or package templates, read:
+
+```text
+node_modules/@c4a/context/docs/guides/agent-guide.md
+node_modules/@c4a/context/docs/guides/package-outputs.md
+node_modules/@c4a/context/docs/reference/project-api.md
+node_modules/@c4a/context/docs/reference/package-templates.md
+```
+
+Do not write one-off scripts to parse source packages, count extracted symbols,
+or sample candidates. Use `context source inspect` and the extract no-write
+preview command.
+
+### Step 4 — Report
+
+Report only the meaningful state transition: commands run, current status,
+human gate reached, and the precise user decision needed next. Never present
+`context build`, `context verify`, or file counts as proof that a deliverable is
+usable; inspect generated package structure when package output is involved.
+
+### Step 5 — Self-verify Checklist
+
+- [ ] `context status` was run first. If not, return to **Step 1**.
+- [ ] No human gate was crossed. If not, stop and report the protocol error.
+- [ ] No ad hoc file/script probing replaced CLI views. If not, discard that
+  conclusion and use the CLI view.
+
+</procedures>

package/plugin/skills/skill-init-workspace/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: skill-init-workspace
+description: >
+  Internal procedure invoked by the public Context init entry; not a user slash command.
+  Initializes a Context knowledge workspace, executes only safe setup follow-up,
+  then hands off to the next-step workflow until the first human gate.
+tools:
+  - Bash
+---
+
+# skill-init-workspace
+
+Initialize a Context workspace. The CLI creates files; the agent follows safe
+setup hints and stops before source/scope choices.
+
+## TL;DR
+
+- Use `context init`; do not add any extra project-local agent setup.
+- If init prints the standard setup `next:` command, run it instead of only
+  repeating it.
+- After the setup command succeeds, enter the workspace and read `AGENTS.md`
+  before running `context status`.
+- After setup, use `${CLAUDE_PLUGIN_ROOT}/skills/skill-continue-workflow/SKILL.md`
+  for status-driven continuation.
+- Stop at source registration, extraction scope, review, package output, or any
+  external repo operation that needs user choice.
+- Explain in the user's conversation language. Keep CLI commands, flags, paths,
+  status values, JSONL keys, and copied CLI tokens unchanged.
+
+<procedures>
+
+### Step 1 — Run Init
+
+1. If the user gave no directory, run `context init`.
+2. If the user gave a directory, run `context init <project-dir>`.
+3. If the user supplied a project name option, pass it as `--name <name>`.
+4. Read the CLI feedback block and preserve the project root path.
+
+### Step 2 — Execute Safe Setup
+
+1. If CLI prints `next: cd "<project-root>" && bun install`,
+   execute that command.
+2. If install fails, report the failure and stop.
+3. If setup succeeds, read `<project-root>/AGENTS.md`.
+4. After reading `AGENTS.md`, run `context status` from `<project-root>` and
+   treat that output as the current workspace state.
+
+### Step 3 — Handoff Or Stop
+
+1. If status is ready for a safe mechanical step, continue with
+   `${CLAUDE_PLUGIN_ROOT}/skills/skill-continue-workflow/SKILL.md`.
+2. If status is `missing-source`, `Human gate:`, or contains placeholders such as
+   `<name>`, `<repo-or-subdir>`, `<phase-id>`, or `<collection>`, ask for the
+   missing human choice and stop. For missing sources, ask for the knowledge
+   source boundary first; do not ask for a raw source name as an isolated
+   parameter.
+3. Do not infer repo source, source boundary, source name, package, or
+   extraction scope from cwd, parent directories, package names, monorepo
+   layout, or git remote.
+
+### Step 4 — Report
+
+Summarize what was initialized, what setup command ran, current status, and the
+human choice needed next. Do not paste a long raw CLI transcript unless the user
+asks for exact output.
+
+### Step 5 — Self-verify Checklist
+
+- [ ] Safe setup was executed when CLI provided the standard setup `next:`. If
+  not, return to **Step 2**.
+- [ ] No repo source or extraction scope was inferred. If not, stop and ask the
+  user to confirm the source boundary and scope.
+
+</procedures>

package/plugin/skills/skill-package-output/SKILL.md

@@ -0,0 +1,167 @@
+---
+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.
+- 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;
+- 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/`.
+
+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
+
+- [ ] User selected the package output. 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>