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

package/plugins/cursor/skills/skill-source-scope/SKILL.md

@@ -0,0 +1,406 @@
+---
+name: skill-source-scope
+description: >
+  Internal procedure invoked by the public Context continuation entry; not a user command.
+  Handles source registration, monorepo source boundaries, extract phase
+  declaration, no-write scope preview, and the pre-extraction confirmation gate.
+tools:
+  - Bash
+---
+
+# skill-source-scope
+
+Choose and validate what may become draft knowledge.
+
+## TL;DR
+
+- Missing source means the next product action is "add a knowledge source".
+  Explain that in user-facing language before showing any CLI command.
+- Ask what source the user wants to add: local code repo/package, remote Git
+  repo/package, local Markdown/MDX document/folder, article/documentation repo as a
+  file source, or Lark/Feishu document. Current CLI can execute repo sources,
+  local file sources, and Lark document capture through the declared flow.
+- Treat source registration as a knowledge-boundary decision, not a parameter
+  prompt. Explain that the source name becomes a stable namespace in source
+  refs, phase ids, and package naming. Approved knowledge paths are derived
+  later from collection, containment, and slug. Give concrete examples before
+  asking for confirmation.
+- If the user already provided a path and only the source name is missing, still
+  explain what that name means. Do not ask "confirm source name" without saying
+  whether the boundary is a single package/module or a parent monorepo/subspace
+  namespace.
+- Do not infer a source from cwd, parent directories, package names, monorepo
+  layout, or git remote.
+- In monorepos, one source may conceptually be the whole repo/subspace or one
+  package/subdirectory. If the user wants one package manual, prefer the
+  package/subdirectory. If the user wants one unified knowledge product across
+  modules, explain that the source name becomes the repo/source identity and
+  may be used in codegraph NodeRefs such as `codegraph/product-ui/...` when the
+  extraction rules derive those refs. Current repo extraction
+  still requires choosing a concrete single-module extraction boundary before
+  running extraction; do not run extraction against an ambiguous multi-module
+  source.
+- `extractTs.include` filters files inside the selected source; it is not a
+  package/module selector.
+- Use `context source inspect <source-name> --format json` for module choices.
+- Before first real extraction, generate a no-write preview and show module
+  counts plus `knowledgeTree` / `knowledgePathExamples` to the user. Use
+  `--dry-run` only in the command you execute, not as the user-facing label.
+- Human-facing explanations must describe the extraction impact first: what code
+  files are read, what symbols become draft knowledge, what is skipped, and what
+  review gate follows. Do not lead with `extractTs`, `include`, `exportedOnly`,
+  or `reviewValidity`.
+- Document capture has its own gate. After a file or Lark source is registered,
+  ask for permission before reading the source body, then show the capture
+  summary before handing off to material investigation and structure drafting.
+  Do not default to one page per document, and do not create final draft pages
+  directly from capture.
+- For capture routing, output handling, missing dependency recovery, and final
+  reporting discipline, read the source capture procedure at
+  [references/capture-source.md](references/capture-source.md). Its judgment
+  rules use only the declared source/capture phase flow in this skill.
+- Do not use unsupported source lifecycle shortcuts. There is no direct
+  source deletion or purge command in this workflow, and agents must not delete
+  `sources/`, `knowledge/`, `unapproved/`, `dist/`, or `.tmp` to simulate one.
+  If the user asks to retract, remove, or purge a source, stop and explain that
+  the current plugin exposes no approved gate for that operation.
+
+<reference>
+
+## Source Type Guide
+
+When the workspace has no source, do not ask with a raw placeholder command.
+Ask for a knowledge source in plain language and map it to the supported path:
+
+| User source | What to ask for | Current handling |
+|---|---|---|
+| Local code repo | knowledge boundary, stable source name, and local repo path | Register with `context source add repo <name> --local <path>`. CLI records git root + optional `subpath`; `sources/repo/<name>` becomes an ignored symlink to the chosen repo/subdir view. |
+| Local monorepo package/module | whether the source is the whole repo/subspace or one package/subdir; stable source name; chosen path | Register the chosen boundary as the repo source. If the user wants one package manual, register that package/subdir. If the user wants a unified subspace manual, register the subspace. Do not use `extractTs.include` as a package selector. |
+| Remote Git repo | knowledge boundary, stable source name, remote URL, pinned commit/ref, desired package/subdir, and permission to clone | CLI does not clone automatically. After explicit user approval, the agent may clone/checkout to an ignored local path, then register that local checkout. Cloned source content must not be committed. |
+| Local Markdown / document file or folder | document boundary, stable source name, local path, include glob if needed, and permission to read the source body | Register with `context source add file <name> --local <path>`, declare the matching capture phase, then hand off to material investigation and structure drafting after capture. Do not run capture before the user confirms read permission. |
+| Lark / Feishu document | document URL/token, intended collection, and permission to read remotely | Register with `context source add lark <name>` plus exactly one of `--url`, `--doc-token`, or `--wiki-token`; declare the matching capture phase, then hand off to material investigation and structure drafting after capture. Explain that capture writes a committed snapshot under `sources/lark/<name>/`, supports offline verify/fresh clone reproduction, and does not write credentials. Do not fetch through ad hoc scripts. |
+
+</reference>
+
+<procedures>
+
+### Step 1 — Register Only User-Chosen Sources
+
+If no source is registered, tell the user that the next step is adding a
+knowledge source. Use the user's language and explain that this is a boundary
+choice:
+
+```text
+You are choosing what one source means for this knowledge workspace.
+The source name becomes part of source refs and phase ids. Approved knowledge
+paths are derived later from collection, containment, and slug. NodeRef and
+ViewRef are identity fields, not path strings.
+
+If the source is one package:
+knowledge/codegraph/component-lib/...
+repo:component-lib#symbol:...
+capture:file:component-lib
+dist/component-lib-kb/
+
+If the source is one document source:
+knowledge/architecture/entity/example.md
+file:product-docs/getting-started.md#span:...
+align:file:product-docs:architecture
+dist/product-docs-kb/
+
+If the source is a parent monorepo/subspace namespace, later multi-module
+outputs can be shaped like:
+knowledge/codegraph/product-ui/component-web/...
+knowledge/codegraph/product-ui/component-lynx/...
+```
+
+If the source already points at one package/module root, the path uses the
+source name once. An extra module/package segment is only expected when the
+chosen source boundary intentionally covers multiple modules. In the current workflow, treat that
+parent source as a planning/inspection boundary first; choose a concrete
+package/subdirectory source before real extraction.
+
+When the user has already provided a path, describe the current interpretation
+before asking for the name:
+
+```text
+I am treating this path as the source boundary:
+<path>
+
+If this path is one package/module, the source name will be used directly:
+source refs such as repo:<source-name>#...
+
+If this path is a parent monorepo/subspace that contains multiple modules, the
+source name becomes the parent source namespace for grouped codegraph NodeRefs
+when extraction derives those refs:
+knowledge/codegraph/<source-name>/<module-name>/...
+
+For the current extraction flow, a multi-module parent source is used for
+inspection/planning first. Before reading code, we still need a concrete
+package/subdirectory boundary.
+```
+
+Then ask for one of:
+
+- local code repo or package path;
+- remote Git repo URL plus pinned commit/ref and target package/subdir;
+- local document path;
+- Lark/Feishu document URL.
+
+Do not ask "what is the source name?" as the first or only question. Ask what
+they want the knowledge source to cover, then propose a source name derived from
+that boundary and explain the path impact.
+
+Good user-facing wording:
+
+```text
+Next we need to add a knowledge source.
+
+If you only want a manual for the component package, choose that package
+directory as the source boundary, for example:
+name: component-lib
+path: /repo/packages/component-lib
+
+If you want one manual for the whole subspace, choose the subspace root:
+name: product-ui
+path: /repo/subspaces/product-ui
+
+The name is not just a label. It will appear in source refs such as
+repo:component-lib#... and in phase ids such as extract:component-lib:codegraph.
+Approved paths are derived from collection, containment, and slug. NodeRef and
+ViewRef are identity fields, not path strings.
+
+For a unified subspace package shape, a parent source name such as `product-ui`
+lets the output group child modules under that namespace:
+knowledge/codegraph/product-ui/component-web/...
+knowledge/codegraph/product-ui/component-lynx/...
+
+Current extraction can inspect a parent source, but it should extract from a
+confirmed single package/subdirectory source. If this path is a parent source,
+I will show the module tree first and ask which package(s) to use before
+reading code.
+```
+
+Mention the CLI command only as an implementation detail after the user chooses
+a supported repo source.
+
+For a local repo source, ask for:
+
+- source boundary and stable source name;
+- local repo or package/subdirectory path;
+- remote/ref only when not inferable or when the user wants an explicit pin.
+
+After the user provides the choice, run:
+
+```bash
+context source add repo <name> --local <repo-or-subdir>
+context source ensure
+```
+
+Add `--remote` / `--ref` only when the user gave explicit values.
+
+For a remote Git repo source, ask for permission before clone/checkout. If the
+user approves, clone to an ignored local path, checkout the requested commit,
+then register that local checkout with `context source add repo`. Do not commit
+cloned source content.
+
+For local Markdown/MDX document sources, after the user confirms the boundary, run:
+
+```bash
+context source add file <name> --local <file-or-folder>
+```
+
+Default file capture handles Markdown. If `context source add file`,
+`context source inspect`, `context status`, or capture output reports that the
+source looks like an MDX documentation site, stop at the source boundary gate
+and ask the user to confirm that interpretation before changing `src/index.ts`.
+For MDX documentation sites that use `_meta.json` route metadata, declare
+`captureFile({ source: source("<name>"), processor: mdxJsonDocs() })` in
+`src/index.ts`; included `_meta.json` files are route metadata, and the CLI
+generates `__context_route_metadata.md` as mechanical route evidence. Use
+`--include` only when the approved boundary is narrower than the folder. Then
+explain that the next operation reads the approved document files and writes a
+committed snapshot under `sources/file/<name>/`. After the user confirms read
+permission, summarize the `src/index.ts` change or show an equivalent diff
+summary, and run the capture phase.
+Apply [references/capture-source.md](references/capture-source.md) for route
+selection, dependency recovery, output handling, and final reporting, using the
+current capture phase command returned by `context status`.
+
+For Lark/Feishu document sources, register the source but do not fetch content
+with ad hoc scripts. Explain which remote document or wiki token will be read,
+that the snapshot is written under `sources/lark/<name>/`, that committed
+snapshots enable offline verify and fresh-clone reproduction, that whether to
+add extra ignore rules is a business repository decision, and that access
+credentials are not written to the workspace. Use the declared capture/align
+flow only after the user confirms remote reading. After declaring
+`captureLark({ source: source("<name>") })`, summarize the `src/index.ts`
+change or show an equivalent diff summary.
+Apply [references/capture-source.md](references/capture-source.md) for route
+selection, dependency recovery, output handling, and final reporting, using the
+current capture phase command returned by `context status`.
+
+### Step 2 — Handle Monorepos
+
+If a registered source may contain multiple packages, run:
+
+```bash
+context source inspect <source-name> --format json
+```
+
+Present the detected module/package paths from that CLI output as a tree. Explain
+the choices without exposing internal API names first:
+
+- for the current executable flow, register one package/subdirectory as its
+  own source when the user wants a focused package manual;
+- if the user is designing a unified subspace knowledge base, keep the
+  parent source name as the namespace decision, but do not run extraction until
+  the concrete module extraction boundary is confirmed.
+
+Wait for the user to choose. If the user chooses `packages/button`, register it
+as a separate source such as:
+
+```bash
+context source add repo button --local <repo>/packages/button
+```
+
+Do not model a monorepo package choice as `include: ["packages/button/src/**"]`
+on the parent source.
+
+### Step 3 — Review Captured Document Summary
+
+When status is `captured-ready-to-investigate`, or after a capture phase
+completes, do not immediately create draft pages or compile actions. Present
+the capture summary first:
+
+- document count;
+- title tree, heading tree, or source span distribution from the CLI output;
+- available reading budget and evidence views;
+- snapshot path under `sources/file|lark/<source-name>/`;
+- the fact that approved pages are planned through
+  `unapproved/structure.yaml` before compile;
+- whether the source is local file/folder evidence or Lark/Feishu evidence.
+
+Then explain the next semantic gate in user-facing terms:
+
+```text
+The source body has been captured into a committed snapshot.
+
+Next we investigate the material and propose a structure draft:
+- which knowledge pages should exist;
+- which source spans support each section;
+- which relationships are supported by evidence;
+- what remains unresolved or weak.
+
+No approved Markdown is written at this point. Compile can start only after the
+structure is validated and you confirm it.
+```
+
+If the user wants to influence the shape before the Agent drafts it, ask a
+small semantic question with host-native multi-choice support when available:
+
+- Continue material investigation and propose a structure draft.
+- First add a reference structure or preference, such as expected domains,
+  page naming, or relationship focus.
+- Narrow or correct the captured source before planning.
+
+Do not use SDK factory names as user-facing option labels. If the user asks for
+one page per source document, represent that as a degenerate structure draft
+and still route through structure confirmation plus compile. Then follow
+`../skill-prose-align/SKILL.md`.
+
+### Step 4 — Declare Extract And Review
+
+Read the SDK guide before editing:
+
+```text
+node_modules/@c4a/context/docs/guides/agent-dialogue.md
+node_modules/@c4a/context/docs/guides/agent-guide.md
+node_modules/@c4a/context/docs/reference/project-api.md
+```
+
+Before editing, explain the proposed extraction in product terms. Use wording
+like:
+
+```text
+The source is ready and resolves to one package/module.
+
+Proposed extraction:
+- read TypeScript/TSX files under `src/`;
+- include exported symbols such as components, functions, types, and props;
+- create draft candidates for human review;
+- write no approved Markdown until the review payload is applied.
+
+This skips files outside `src/` and non-exported/internal helpers. If you want
+docs, tests, examples, or internal APIs included, say that before extraction.
+
+I will first generate a preview without writing candidates. The preview will
+show counts plus the planned `knowledge/` tree.
+```
+
+Only after the user confirms this product-level scope, declare the chosen source
+with `source("<name>")`, add the TypeScript extraction phase, and add the human
+review phase. Use `include` only for a file-level filter within the chosen
+source boundary. Mention the internal API names only in code-change summaries,
+or when the user asks for implementation details.
+
+### Step 5 — Show The Pre-extraction Preview
+
+Before real extraction, run the CLI no-write preview:
+
+```bash
+context run <extract-phase-id> --dry-run --format json
+```
+
+Show the user:
+
+- resolved source and module/package list;
+- file, symbol, and candidate estimate counts;
+- `knowledgeTree`;
+- several `knowledgePathExamples`.
+
+Explain that approved pages will land under paths derived from collection,
+containment, and slug; NodeRef/ViewRef are identity fields, not path strings:
+
+```text
+knowledge/<collection>/<containment>/<slug>.md
+```
+
+If source name, package name, module list, candidate estimate, or path shape is
+not what the user expects, stop and repair the source boundary or source name
+before extraction.
+
+For a single-module code source, a repeated path like
+`knowledge/codegraph/<source-name>/<package-name>/...` is usually a schema
+problem or a wrong source boundary. Stop before extraction if the preview shows
+that shape unexpectedly.
+
+Do not present this as a CLI option or as "Context default options" to the
+user. Present it as the actual proposed knowledge impact: code area read,
+exported-symbol policy, candidate count, and final path shape. The user-facing
+phrase is "preview without writing".
+
+### Step 6 — Run Extraction Only After Scope Is Clear
+
+If the user already confirmed the exact source/scope and the no-write preview
+matches it, run:
+
+```bash
+context run <extract-phase-id>
+```
+
+If the preview reports modules outside the confirmed source boundary, do not
+run extraction. Ask the user to choose the corrected source boundary.
+
+### Step 7 — Self-verify Checklist
+
+- [ ] Source choice came from the user, not inference. If not, return to
+  **Step 1**.
+- [ ] Monorepo package selection is represented as source boundary. If not,
+  return to **Step 2**.
+- [ ] Captured document summary was shown before structure/compile. If not, return to
+  **Step 3**.
+- [ ] No-write tree/path preview was shown before first real extraction. If not,
+  return to **Step 5**.
+
+</procedures>

package/plugins/cursor/skills/skill-source-scope/references/capture-source.md

@@ -0,0 +1,180 @@
+---
+name: capture-source
+description: >
+  Capture local Markdown or Lark/Feishu document sources through registered
+  Context sources and declared capture phases. Use the local `context` CLI for
+  workspace writes.
+tools:
+  - Bash
+---
+
+# Capture
+
+Current capture discipline for document sources. The executable path is source
+registration plus the declared capture phase flow:
+
+- local Markdown/MDX file source: `context source add file <name> --local <path>`
+  followed by `context run capture:file:<name> --format json`;
+- Lark/Feishu source: `context source add lark <name> ...` followed by
+  `context run capture:lark:<name> --format json`;
+- refresh: rerun the same declared capture phase after status or the user asks
+  for recapture.
+
+Use only commands surfaced by the current status output or capture phase.
+
+---
+
+## Workflow
+
+Capture is entirely CLI-driven — your role is to register the right source,
+declare the matching capture phase, run the current `context run capture:*`
+command, and relay its output. Never hand-write captured source snapshots: the
+CLI owns normalisation (NFC, BOM strip, line endings) and the `content_hash`
+contract, so any manual edit breaks idempotency.
+
+### Code capture diagnostics
+
+Do not run hand-written dependency preflight commands before code extraction or
+document capture. The CLI owns configured runner/plugin resolution and returns
+structured `agent_hints[]` when a runner or remote-document helper is missing or
+misconfigured.
+
+If code extraction capture fails with install or runner hints, surface the CLI's `agent_hints[]` command exactly as printed. Ask the user once whether to run that command on their behalf when it touches shared state. If approved, run the exact command from `agent_hints[0].command`, then retry the same capture command. If declined, leave the command visible so the user can run it manually. Do not inline extraction packages, do not hand-write code snapshots, and do not continue with partial capture.
+
+Invocation note: document capture and code extraction do not run through `npx`.
+Use the installed `context` CLI and the declared phase command returned by
+`context status` or the phase view. When external helpers are missing, surface
+the CLI's structured install hints instead of substituting your own package
+manager or version.
+
+### Route by source boundary
+
+Before choosing a local Markdown capture route, honor the surrounding task context. Driver documents such as run instructions, handbooks, READMEs, plans, feedback issues, corpus/index/manifests, and batch lists are not Context sources unless the user explicitly asks to ingest them. Capture only ingest targets that are already explicit in the user request; if they are missing, ask one clarification instead of capturing the driver document.
+
+- One or more local `.md` / `.mdx` files or a local documentation folder to ingest →
+  register one file source with the user-confirmed source name and boundary:
+  `context source add file <name> --local <file-or-folder>`. For an explicit
+  batch inside a broader folder, preserve the user's include list on source
+  registration. Default file capture handles `.md`. If the CLI reports
+  document-site files such as `.mdx`, `_meta.json`, sidebars, or docs config,
+  stop and confirm whether the selected boundary is a documentation site before
+  changing capture configuration. For MDX documentation sites that use
+  `_meta.json`, declare `mdxJsonDocs()` on `captureFile` in `src/index.ts`;
+  keep `_meta.json` only when it is route metadata for the selected document
+  folder. The CLI captures it as metadata and generates
+  `__context_route_metadata.md` as mechanical route evidence; it also extracts
+  static MDX component props/children into `__context_mdx_component_text.md`
+  when components carry user-facing text. Declare
+  `captureFile({ source: source("<name>"), processor: mdxJsonDocs() })`, then
+  run `context run capture:file:<name> --format json`. If the selected MDX page
+  is empty or only mounts runtime-rendered content, tell the user that capture
+  found a document-site shell and ask for the rendered-site or data-source
+  boundary instead of inventing body text.
+- A Lark/Feishu URL, doc token, or wiki token → register one Lark source:
+  `context source add lark <name> --url <url>` or the matching token flag.
+  Declare `captureLark({ source: source("<name>") })`, then run
+  `context run capture:lark:<name> --format json`.
+- Mixed local document and Lark document batches are separate sources unless
+  the current CLI explicitly offers a combined source contract. Do not write an
+  Agent-side URL/file loop.
+- Refresh or recapture request for an already registered file/Lark source →
+  rerun the same declared capture phase. The CLI appends a new snapshot only
+  when content changes and never overwrites prior snapshots.
+- Code package extraction is not document capture. Route code source selection
+  through `skill-source-scope` extraction preview and the declared extract
+  phase. Do not invent a document capture path for code.
+- Conversation notes, decisions, and revision intents are not document capture
+  sources in the current workflow unless the CLI status or project-specific
+  phase exposes an explicit note source contract. If absent, record the user
+  guidance in the conversation and use it as pre-align hints, not as a snapshot
+  write.
+
+Do not discover files with `find` / `ls` when the user already supplied paths.
+If the include set is large, summarize it and ask for confirmation before
+registration; do not read file bodies before capture permission is clear.
+
+### Output Handling
+
+Report the CLI output verbatim. If the CLI reports `N sources changed`, suggest the right next step:
+
+- Run `context status --format json` and use its `state`, `routing`, and
+  `next_commands`.
+- If status reports `captured-ready-to-investigate`, suggest the returned
+  `context run align:<type>:<source>:<collection> --view read-plan --format json`
+  command and hand off to `skill-prose-align`.
+- If status reports `needs-structure` or `structure-ready`, follow the returned
+  align/compile command instead of naming a generic slash command.
+- If status reports `compile-ready-for-review`, route to the review gate.
+- If the source was code-only and status reports pending code projection,
+  follow the CLI-owned extract/compile route returned by status.
+
+Never suggest prose compile or hand-built document knowledge for a code-only
+source. Code sources become active knowledge only through the declared
+extraction/review route returned by `context status`.
+
+If capture is rejected because another phase or write gate is active, do not
+discard it automatically. Explain the active state from `context status`, follow
+that phase when it is the intended task, and ask the user before discarding
+in-progress work when a current project command exists. If the user expected a
+different repository/workspace, change to the confirmed workspace root before
+retrying capture.
+
+## Final Report
+
+Report in the user's conversation language. Translate section headings into the user's language instead of copying the English labels below verbatim. Optimize for human readability: use document titles instead of source ids, package names instead of internal source id strings, and human-readable kind labels ("local markdown", "Feishu doc", "code package") instead of internal tokens. Do not surface content hashes, snapshot digests, internal payload identifiers, or absolute file paths.
+
+Stable structure:
+
+1. Completion headline. Single line with the action verb plus core counts: how
+   many sources were captured this round, broken down by `new` / `updated` /
+   `unchanged`. Capture data from the current `context run capture:* --format
+   json` result summary, or per-source statuses when no aggregate is returned.
+2. Per-source list grouped by status. Show each captured source under one of three groups (`new` / `updated` / `unchanged`); within each group list the document title (`source.title`), kind label, and a short delta indicator for updated sources (for example added/removed line counts when the CLI returns them; otherwise "content changed"). Cache-hit code packages belong in `unchanged`. Omit groups that are empty.
+3. Pending phase signals. When `context status --format json` reports follow-up
+   work tied to this capture (sources pending align, sources pending compile,
+   refreshed sources pending recompile, code sources pending projection),
+   summarize each as a single line naming the work and which sources are
+   affected. Omit the section entirely when there is no pending follow-up.
+4. Next step. Single command suggestion driven by status: the returned
+   `context run align:<type>:<source>:<collection> ...` command when structure work is
+   pending, the returned `context run compile:<type>:<source>:<collection> ...`
+   command when prose compile work is pending, or the CLI-owned code projection
+   command when code projection is pending. If nothing is pending, say so
+   explicitly.
+
+Do not include raw CLI diagnostics, agent_hints content, schema names, or phase
+payload identifiers in the report. Those belong in earlier troubleshooting
+output, not in the completion summary.
+
+## Reference
+
+### Missing Dependency Recovery
+
+If the CLI returns `agent_hints[]` for a missing code runner or plugin package, stop and surface the hint. Ask the user once for permission to run `agent_hints[0].command` (the CLI has already picked the correct package manager — `npm install -g` or `bun install -g` — based on how `context` itself was installed). If approved, run that exact command via `Bash` and then retry the same capture; if declined, leave the command visible for manual install. Never substitute a different package manager or version.
+
+If the CLI prints a missing-dependency error like `lark-cli not installed`, walk the user through installation:
+
+1. Ask once up-front whether to proceed with install. If no → stop and tell the user to install manually from the tool's official README, then re-run.
+2. `WebFetch` the tool's official README (for `lark-cli` that's `https://github.com/larksuite/cli/blob/main/README.md#quick-start-ai-agent`).
+3. For each command the README prescribes for the user's platform, show the command then call `Bash`. The host's per-tool permission prompt is the user's confirmation surface; don't add extra y/n questions between commands.
+4. Stop on any failure; surface stderr verbatim.
+5. After success, tell the user to rerun the current Context command that
+   failed.
+
+### Language Policy
+
+Your prose to the user follows the user's conversation language. CLI commands, flag names, URLs, env-var names, binary names, source-ids stay English.
+
+### Invariants
+
+- Captured source snapshots are immutable post-write — the CLI only ever appends new snapshots.
+- The source registry is authoritative; derived index files are not Agent phase
+  inputs.
+- Local `.md` / `.mdx` source identity follows the captured file's stable origin path, not its H1/title. If the user edits the title but captures the same path again, the CLI appends a new snapshot to the same `local:*` source.
+- In `--format json`, code capture runner cache state is authoritative in `result.runner.cacheMode`: `prepared` means a workspace runner was prepared, `cached` means workspace cache hit, and `bypass` means `--no-runner-cache` used a temporary runner directory instead of the workspace runner cache.
+- Code extraction runner evidence is derived by the CLI from emitted source files. Do not ask users to configure `evidence.mode`; rerun capture after fixing the runner emit output.
+- Code extraction snapshots ship with `evidence.mode: none`; symbols/files/edges are indexed inside the code bucket. Do not ask users to inspect or repair a code `.evidence` manifest.
+- Code extraction/projection is separate from document capture. Materialize code
+  knowledge through the declared extract/code projection flow before prose align
+  attaches documentation to code Nodes.
+- On duplicate capture of the same URL: identical `content_hash` → CLI skips with `unchanged`; different hash → CLI appends a new snapshot.

package/plugins/skills/context-continue/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: context-continue
+description: >
+  Inspect the Context workspace, decide the next useful action, and proceed. Use the local `context` CLI for workspace writes.
+tools:
+  - Bash
+---
+
+# Continue
+
+Public Context entry for agents that expose skills instead of slash commands.
+
+- Public entry: `context-continue`
+- Host command names are installation-specific; use the command or skill surfaced by the current host instead of deriving a filesystem path from an example name.
+- CLI primitive prefix: `context ...`
+- Internal procedures live under `references/internal-procedures/`; read each referenced file in full before following that step.
+
+---
+
+## Workflow
+
+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 procedure in `references/internal-procedures/skill-continue-workflow.md` 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.