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

package/plugins/skills/context-continue/references/internal-procedures/skill-source-scope.md

@@ -0,0 +1,402 @@
+---
+name: skill-source-scope
+description: >
+  Internal procedure invoked by the public Context continuation entry; not a user slash 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
+  [skill-source-scope/references/capture-source.md](skill-source-scope/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. 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, not body
+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 [skill-source-scope/references/capture-source.md](skill-source-scope/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 [skill-source-scope/references/capture-source.md](skill-source-scope/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.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/skills/context-init/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: context-init
+description: >
+  Initialize a Context knowledge workspace. Use the local `context` CLI for workspace writes.
+tools:
+  - Bash
+---
+
+# Init
+
+Public Context entry for agents that expose skills instead of slash commands.
+
+- Public entry: `context-init`
+- 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
+
+Initialize a Context workspace with the global CLI, then continue only through
+safe mechanical setup steps until the first human decision gate.
+
+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.
+
+Use the procedure in `references/internal-procedures/skill-init-workspace.md` end to end. It owns
+the `context init` invocation, dependency install follow-up, generated
+`AGENTS.md` handoff, status handoff, and stop conditions.
+
+Do not add extra project-local agent setup. Do not infer repo sources or
+extraction scope from the surrounding monorepo after setup.

package/plugins/skills/context-init/references/internal-procedures/skill-continue-workflow.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
+  `skill-source-scope.md`.
+- Delegate review to `skill-review-gate.md`.
+- Delegate package output choices to
+  `skill-package-output.md`.
+- Delegate document investigation and structure confirmation to
+  `skill-prose-align.md`.
+- Delegate source-bound prose compile requests to
+  `skill-prose-compile.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
+   `skill-source-scope.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
+   `skill-prose-align.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
+   `skill-prose-compile.md`.
+4. If status says `compile-ready-for-review` or review is needed, follow
+   `skill-review-gate.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 `skill-package-output.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/plugins/skills/context-init/references/internal-procedures/skill-init-workspace.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 `skill-continue-workflow.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
+   `skill-continue-workflow.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>