@c4a/context-cli 0.7.8 → 0.7.10-alpha.1

package/plugins/cursor/commands/c4a-context.md

@@ -1,5 +1,5 @@
 ---
-description: "Use when the user explicitly invokes Context or continues an explicitly started Context workflow in this conversation to build, inspect, update or package knowledge from code, documents, notes and conversation summaries. Do not auto-start for ordinary planning, design or coding."
+description: "Use when the user explicitly invokes Context, asks to reorganize an existing Context knowledge map or website navigation, or continues a Context workflow to build, inspect, update, recover or package knowledge. Do not auto-start for ordinary planning, design or coding."
 ---
 
 # Context
@@ -10,6 +10,8 @@ reading; use it for workspace writes.
 
 Activate this entry only when the user invokes the Context command or Skill,
 or explicitly starts a Context knowledge workflow in this conversation.
+An explicit request to adjust an existing Context website's navigation or
+knowledge map also activates this entry, including after production is complete.
 Related follow-up requests need no repeated invocation. Ordinary planning,
 design, coding, document editing or discussion of Context implementation does
 not activate it. A workspace, source file, MR or matching phrase alone is not
@@ -27,12 +29,14 @@ Within an active Context workflow, requests include, but are not limited to:
 | Intent | Scope |
 | --- | --- |
 | Build a knowledge base | Clarify the audience and source scope, then create or continue knowledge from selected repositories and documents. |
+| Recover a stuck Context task | Use `context task recover --format json` in the existing workspace; read its recovery Skill even if normal status/Route fails. Repair authorized drafts or restore an available planning baseline; report unresolved failures with the supplied sanitized issue template. |
 | Check progress and results | Explain what is done, where delivered pages are, and what is waiting. |
 | Save notes | Save supplied observations, excerpts or decisions; stop after saving if that is all the user requested. |
 | Preserve conversation insights | Save or use a summary of supplied discussion, not an entire session history. Code-change links are optional. |
 | Update knowledge from source changes | Assess a selected commit, MR/PR or document change against a fixed source version; update affected pages and warranted new topics. |
 | Revise existing content | Correct current drafts or approved pages, including several pages or supported API-table regeneration. |
 | Organize pages and sources | Move pages within a collection, rename supported sources or remove unused sources with reference checks. |
+| Customize the knowledge map | At any time, reorganize the existing site's top navigation, left directory, labels, order or article placements; the same map organizes LLMS. Preserve current production work. |
 | Select or customize indexing | Choose compatible indexing Skills and adjust guidance or templates through the configuration flow. |
 | Deliver a batch early | Review and build complete newly authored pages before all writing finishes. |
 | Package knowledge or adjust output | Build approved content for Agents or LLMs, rebuild a package or change its output template. Rebuilding does not rewrite pages. |
@@ -40,6 +44,68 @@ Within an active Context workflow, requests include, but are not limited to:
 | Commit workspace results | Save selected workspace files in local Git, without pushing or including unrelated changes. |
 | Restore a historical workspace version | Select a saved commit, restore only the agreed workspace scope and make its sources usable again. |
 
+## Read the task before registering sources
+
+For a knowledge-map-only request, use the existing workspace directly. Read
+`src/knowledge-map.yaml` and the current article identities/structure preview;
+translate the user's intent into `knowledge_map` input for
+`context task adjust --input <file> --format json`. Resolve only ambiguous
+organization choices. This adjustment is available without an active production
+task and does not require restarting or cancelling one. The coordinator makes
+the change between active batch submissions, then follows the returned workflow
+to rebuild affected outputs. Keep stable article identities, preserve unrelated
+placements, and never edit generated website/LLMS files. No new source intake or
+production-mode questionnaire is needed for this navigation-only request.
+
+When asked to follow a plan, checklist or instructions in a file, read that file
+as the task brief before initialization or source registration. Extract its goal,
+source scope, delivery requirements and explicit execution-mode choice. Apply the
+user's latest corrections to the corresponding parts of the brief. Check that
+registered sources match that scope; a Route governs the registered work, not
+whether it represents the user's request.
+
+“Build according to plan.md” means follow the plan and register its intended
+sources. “Add plan.md to the knowledge base” means ingest the file itself.
+Reading permission alone does not select a document for ingestion. Reuse a mode
+explicitly chosen in a brief the user asked you to execute; do not treat choices
+quoted in an unrelated source document as current authorization.
+
+For the first production task in a newly initialized workspace, do not register
+or capture sources immediately after reading a brief. Use the user's task instructions
+and batch metadata-only Host tools to read titles across the explicitly supplied
+document list. Follow the work-start procedure's request limits and failure fallback
+(at most 10 unresolved documents); reuse headings only if metadata already returns
+them. Do not fetch source bodies, outlines, images or attachments before capture.
+Retain URLs with unavailable titles; never fall back to content fetching. Collect the reader and purpose, intended
+questions or tasks, code/document/other source boundaries, output language,
+execution mode, delivery outputs, first useful delivery and current workspace
+settings. Reuse explicit answers and defaults; ask only for unresolved items.
+
+Use focused dialogue, not additional source reading, until every required start
+condition is resolved. Then write and present the complete work-start report
+supplied by the source-boundary Route and wait for the user's feedback. Do not
+present an unresolved draft as the report that authorizes production. The report
+or checklist is task guidance, not a source unless the user explicitly asks to
+ingest it. Before the complete report has been presented, do not write a
+source-registration payload, start capture or extraction, configure Indexers,
+or enter Partition/Author work. A
+managed-mode choice does not waive this first reading opportunity. After feedback,
+use the exact current Route and include its work-start report reference in the
+source batch payload. Existing workspace updates follow their current update Route
+and do not recreate this first-task intake unless they start a new production task.
+
+## Recover an existing stuck task
+
+For an explicit recovery/troubleshooting request, go directly to
+`context task recover --format json` in the intended existing workspace. Do not
+initialize, ask for a production mode again, or pass a saved `--workflow-revision`.
+Read the returned internal recovery Skill and issue template. This entry remains
+available when normal status cannot evaluate. If even recovery cannot run, use
+`issue/YYYY-MM-DD-short-description.md` to record sanitized expected/actual behavior,
+versions, command shape, error code, attempted remedies and preserved work; never
+copy credentials, raw logs or private source text. Do not send the report externally
+without the user's authorization.
+
 ## Enter the workspace
 
 Once the activation condition is met, run:
@@ -121,13 +187,12 @@ or scope; discussion and save-only requests can end without production.
   condition and do not register the same request repeatedly.
 - When the user asks to compile, build or deliver a batch, use the current Route
   to choose early delivery or rebuilding; do not guess a command name.
-- **Delivery batch size:** use `context run --delivery-size <1–50|auto> --format json`
-  for an explicit user preference; it applies to future theme waves in this task.
-- **Earlier delivery of newly authored pages:** use the Author Route's
-  `delivery.request.command` (`context run --deliver --format json`). Finish any
-  running command first. Complete the current Author batch, then follow the
-  returned composition, Review and build steps. This does not approve content
-  or merely rebuild old approved pages; all Author tasks need not finish first.
+- **Earlier delivery of completed articles:** when explicitly requested, finish
+  any running command, then use `context run --deliver --format json` and follow
+  its Review, close and build routes. This pauses further writing without
+  approving content. Successful delivery resumes remaining tasks; an explicit
+  `context run --resume-writing --format json` cancels the pause without losing
+  drafts or approvals. Batch grouping belongs to the current Agent plan.
 - **An independent new task while work remains:** explain saved results,
   unfinished scope and concrete rollback losses. Reuse or obtain the user's
   choice to finish the current task or roll back an explicit scope. Do not
@@ -167,7 +232,14 @@ authority; do not reconstruct commands from earlier steps.
 the complete returned file and any required direct files it names. If a resource
 has a `command`, execute it and read its output; materializing is not reading.
 Current Indexer Partition, Author, Composer and structure-review files need no
-read receipt: use their immediate completion command after reading. For other
+read receipt: use their immediate completion command after reading.
+For Indexer files that need no read receipt, reuse a fully read resource in this
+conversation only when its source/Provider identity and content digest are unchanged
+and its contents remain available. A new revision alone does not require rereading
+those files. Always read the new Route and task-specific changes; after context loss
+or truncated output, read the missing content. Never invent a receipt or mark an
+unread file as read.
+For other
 resources, follow the returned receipt instructions, keep receipts in this
 conversation, and use the latest `next_action.command` carrying that context.
 When only direct files remain, `resources.after_read.command` acknowledges them
@@ -255,11 +327,11 @@ must not resolve or install the Provider again.
 
 ## Progress reporting format
 
-Every user-facing progress update, in conversation or in a report, must use
-these two bold lines in this order, with the actual values inside the brackets:
+For production progress updates, use two bold lines in this order. Describe
+the actual stage when counters are unavailable; include counts only when supplied:
 
-**[总体进度：已交付 33/125 页]**
-**[当前分片：已规划 3/8 项]**
+**[总体进展：已交付 33/125 页]**
+**[当前进展：已规划 3/8 项]**
 
 Use CLI `progress.scopes` (or `indexerProgress.scopes` in status) as the
 single source for progress in conversation and reports. It separates:
@@ -281,9 +353,10 @@ number of currently prepared tasks. Revisions can overlap delivered pages;
 do not add wave tasks to delivered pages to invent a page total.
 
 Use two bold progress lines. The first combines `overall` and a clearly labelled
-`wave` supplement; the second uses `slice`. For example, with matching CLI values:
-**[总体进度：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
-**[当前分片：补充内容检查 0/8 项]**
+`wave` supplement; the second describes the current action, using `slice` counts
+when available. Internal wave/slice names need not appear in user-facing text. For example, with matching CLI values:
+**[总体进展：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
+**[当前进展：补充内容检查 0/8 项]**
 
 A completion receipt's `submitted_slice` describes the slice just submitted;
 `progress.scopes.slice` can already describe the next Route. Use the former when
@@ -291,8 +364,12 @@ reporting submission success and the latter when announcing the next slice.
 Never combine their numerators and denominators. A null slice means no active
 Agent task slice, not that the workflow is complete. During Review/build, state
 the returned Route action briefly rather than inventing a slice ratio.
-If progress is unavailable after task cleanup, say the counters are unavailable;
-do not turn the last wave into the overall scope or report delivery as zero.
+Before counters exist or after task cleanup, describe the known stage and current
+action instead of repeatedly saying counters are unavailable. For example:
+**[总体进展：正在准备知识工作区]**
+**[当前进展：已读取启动清单，正在整理仓库与文档范围]**
+During review or packaging, name that action rather than a nonexistent slice.
+Do not turn the last wave into the overall scope or report delivery as zero.
 Continue authorized work after an update; only the agreed delivery stop or an
 actual unresolved blocker permits stopping. This format governs progress, not
 answers, review findings or necessary questions.

package/plugins/cursor/skills/context-indexer-create/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: context-indexer-create
-description: Use when the user explicitly asks to create a new Context Indexer Provider Skill for code, documents, notes or session summaries. Do not activate for indexing existing sources, ordinary coding, knowledge queries or selecting an installed Provider.
+description: Use when the user explicitly asks to create a new Context Indexer Skill for code, documents, notes or session summaries. Do not activate for indexing existing sources, ordinary coding, knowledge queries or selecting an installed skill.
 user-invocable: false
 metadata:
   context-role: "authoring-assistant"
@@ -9,72 +9,33 @@ metadata:
 
 # Create a Context Indexer
 
-Create a reusable Provider in the user's chosen directory. This is a Skill-writing
-assistant, not a Provider or a production Route. Use the conversation language.
-An explicit request to make a new Indexer is sufficient; the user need not name
-this Skill. Do not initialize a knowledge workspace to write a Provider.
-
-## Establish the intended result
-
-Reuse the stated source type, readers, tasks and desired output. Ask only about
-missing choices that affect interpretation or ownership: should the new Provider
-replace an existing primary, or contribute to another Provider's pages? Notes
-may become FAQs, decisions or corrections; session summaries may or may not link
-to code changes. Do not force a taxonomy, a commit association, or one page per
-source. Distinguish a reusable Provider from a workspace-only wording/template
-change; explain the smaller option without refusing a requested new Provider.
-
-## Read the matching contracts and examples
-
-Read [the authoring guide](references/guides/indexer-skill-creation.md), then the
-relevant sections of [the Provider protocol](references/reference/indexer-provider-protocol.md).
-Use the SDK version compatible with the intended CLI, rather than recalling
-schema fields from another release. These references are copied from the SDK
-at plugin build time; the installed schema remains the executable authority.
-
-- Code: [Code authoring](references/guides/code-indexer-skill-authoring.md).
-- Documents: [Markdown authoring](references/guides/markdown-indexer-skill-authoring.md).
-- Notes: [Note sources](references/guides/note.md).
-- Sessions: [Session sources](references/guides/sessions.md).
-- Composition and selection: [Provider customization](references/guides/indexer-provider-and-customization.md).
-
-Inspect the matching existing Provider's actual SKILL.md, context-indexer.yaml,
-selected instruction references and one relevant template. Use a Host-visible
-Skill path or the installed CLI catalog's guidance paths; do not crawl host
-caches or require this repository's developer paths. If examples or the SDK are
-unavailable, explain which validation remains unavailable. Do not invent a
-successful validation or silently install dependencies.
-
-## Write a complete, bounded Provider
-
-Deliver SKILL.md, context-indexer.yaml, the declared instructions and useful
-page templates. Add anonymous fixtures and validation instructions. Add programs
-only for an actual unsupported extraction need; ordinary source interpretation
-and writing belong to the Agent. Derive manifest capabilities and resources
-from what the new bundle actually implements, not everything in the example.
-
-Use one context.indexer.provider/v1 manifest for all four source families.
-Note and Sessions currently use the markdown domain with their own target kinds
-and profiles; do not invent new protocol domains. A resource must be declared
-so the lifecycle can send it to the Agent: an unreferenced reference file is
-not enough. Preserve stable source/subject identity, evidence bindings and
-revision boundaries; keep nonessential metadata out of knowledge frontmatter.
-
-The new Provider does not own source authorization, scheduling, approval,
-close/build or publication. Return the current operation's declared results.
-Do not turn suggestions in notes or sessions into established implementation
-facts, and do not manufacture raw transcripts from summaries.
-
-## Validate and hand off
-
-Follow the guide's manifest, resource, template and fixture checks in an isolated
-test directory. Test the intended reader output, insufficient material, revision
-of an existing page, and composition when advertised. Cover only the source
-families claimed by this Provider. Report static validation separately from an
-actual lifecycle run; a valid YAML file alone is not a working Provider.
-
-Summarize the created files, supported inputs, ownership/composition, tests and
-remaining limitations. Explain the user's chosen installation channel and host
-Skill switch. Installation/enabling does not select a Provider for a workspace.
-Only hand off to the existing Context production Skill when the user asks to
-use it there; that Skill follows a fresh Route for Provider selection.
+Create a reusable skill in the user's chosen directory. This assistant writes
+skills; it does not initialize a knowledge workspace or start production.
+Use the conversation language and ask only for missing source, reader or
+capability choices that materially affect the requested result.
+
+Read [the authoring guide](references/guides/indexer-skill-creation.md).
+When a relevant example is available, inspect its actual host-visible SKILL.md
+and only the references needed for this source family. Do not crawl caches,
+load every installed skill or require an exact Provider version.
+
+Every Indexer starts with a useful skeleton: source structure, recognizable
+features, names, counts when actually established, and entry locations.
+Planning may use direct Agent investigation or a bounded helper appropriate
+to the technology. Detailed parsing and behavior analysis are separate,
+optional writing-time work. One module may use several skills.
+
+Deliver SKILL.md and only useful references, templates or scripts. Do not
+generate a Provider registration manifest, primary/extension binding, version
+or hash verification flow, per-symbol fact ledger or persistent producer log.
+The current Context stage supplies purpose, scope, scheduling and submission
+schemas; the new skill contributes investigation and writing guidance.
+
+Validate the skill's references and any scripts, then exercise realistic
+anonymous material for its claimed capability. Distinguish static validation
+from model output review and a real production run. Do not silently install
+dependencies or claim tests that could not run.
+
+Report created files, supported inputs, bounded helper behavior and remaining
+limitations. Installation makes a skill available, not selected. Start actual
+Context production only when requested, through its existing entry and route.

package/plugins/cursor/skills/context-indexer-create/references/guides/indexer-skill-creation.md

@@ -1,99 +1,109 @@
 # Creating a reusable Indexer Skill
 
-A Provider is a portable Skill bundle. Workspace-local customization changes a
-selected Provider for one workspace; it is not the packaging format for a new
-Provider. Start from the source interpretation and reader task, then choose
-primary replacement or an advertised extension.
-
-## Package and protocol
-
-A typical instruction-only bundle contains:
-
-```text
-context-example-indexer/
-  SKILL.md
-  context-indexer.yaml
-  references/indexer.md
-  references/writing.md
-  templates/reader-guide.md
-```
-
-The name is illustrative. Use a discoverable context-…-indexer… name and an
-explicit Provider identity/version. SKILL.md describes when the lifecycle may
-select it; context-indexer.yaml declares context.indexer.provider/v1, domains,
-activation, profiles, operations and resources. Instructions and templates must
-be declared for the profiles using them. Do not copy unused profiles, composers
-or resource paths. Do not add a provider manifest to the creation assistant itself.
-
-Start from the [minimal manifest](indexer-manifest-example.md), which gives the
-field tree in three groups: required, required once a capability is declared, and
-optional. Read the [protocol](../reference/indexer-provider-protocol.md) for the
-subsystem rules behind those fields — selection validation, partition authority,
-overlays, controlled invocation — and the [selection
-guide](indexer-provider-and-customization.md) for composition.
-The four built-in examples are context-code-indexer, context-markdown-indexer,
-context-note-indexer and context-sessions-indexer. The latter two are independent
-source interpreters using markdown-domain contracts. Use their source-specific
-references instead of making a Markdown Provider accept everything.
-
-## Find a real example
-
-If Context CLI is available, inspect `context indexer catalog --format json`.
-Use the selected entry's guidance.skill_path and guidance.manifest_path to locate
-its bundle; read only that example and its declared resources. Alternatively use
-an exact Host-exposed installed Skill. Do not guess cache paths. This read-only
-catalog use is for Provider development, not a new production discovery gate.
-
-Choose one profile and follow its manifest references through instructions and
-template to its declared results. A code example demonstrates parser facts and
-public APIs; a document example demonstrates evidence-based consolidation;
-a note example demonstrates excerpts versus summaries; a sessions example
-separates decisions, rejected proposals and optional change associations.
-Adapt behavior, not only names. The example's breadth is not a minimum feature
-requirement for a specialized Provider.
-
-## Validate against the installed SDK
-
-Use the matching SDK's public exports. For community installations the package
-is @c4a/context; for an internal distribution use its supplied SDK coordinates.
-With the SDK available, this Node ESM check validates the manifest and declared resource paths:
-
-```js
-import { loadIndexerProviderManifest } from '@c4a/context';
-const manifest = await loadIndexerProviderManifest(process.argv[2]);
-console.log(manifest.id, manifest.version);
-```
-
-The argument is the Skill bundle directory. This check does not establish that
-all resources are usable or that the Provider can produce useful pages. Check
-all declared resource paths stay within the bundle and exist; validate templates
-with the SDK template loader and their declared profile contracts. Consult the
-installed exported signatures before writing the runner: do not invent a CLI
-validate command or fabricate a production Route to run a development check.
-
-Template protocol is context.indexer.template/v1. Semantic prose and deterministic
-Facts have separate variables; registered renderers own program blocks. A
-Provider cannot invent a renderer or an arbitrary document kind. Use supported
-profile/artifact contracts or the existing declared overlay mechanism.
-
-Use anonymous fixtures that demonstrate the advertised source interpretation:
-one useful result, material that cannot support a claim, and an existing-page
-update. Test primary/extension ownership only if that composition is advertised.
-Test the complete selected bundle in a disposable workspace through the normal
-lifecycle when the necessary CLI and materials are available. Preserve the
-user's live workspace. Record exact commands and failures; clearly distinguish
-schema/resource checks from semantic review and lifecycle verification.
-
-## Distribution and use
-
-Keep references and templates inside the bundle, with portable relative paths.
-The complete runtime file ledger determines integrity; do not hand-write a hash
-or copy another bundle's integrity. Use the target distribution's existing
-packaging/resolution tools. Development fixtures need not be shipped as runtime
-resources. Installation may use any supported organizational channel.
-
-A business Provider may be enabled through the host and selected instead of the
-default. Prefixes aid discovery; the manifest and verified resources determine
-compatibility. Select through the current Context Provider-selection Route when
-the user requests actual use. No new CLI install registry or creation-specific
-production state is needed.
+An Indexer is source-specific investigation and writing guidance. It helps the
+Agent understand authorized material and produce useful articles; it does not
+own workflow routing, source authorization, review or permanent article identity.
+Several skills may contribute to one module or article.
+
+## Minimal package
+
+Start with SKILL.md. Add references for substantial source-specific guidance,
+templates when they help readers, and scripts only when a concrete repeated
+operation needs deterministic assistance. A simple note interpreter needs no
+script, manifest, profile registry or template catalog.
+
+Use a discoverable name and a precise description. State when the skill helps,
+which sources it understands, and real limits. Refer to bundled resources by
+portable relative paths. Use an existing host-visible Indexer as a behavioral
+example, not as a collection of fields to copy.
+
+Do not generate context-indexer.yaml, an exact-version selection ritual,
+integrity receipts, primary/extension ownership, article producer records or
+a per-member disposition protocol. A release may have ordinary package
+metadata; that is not a requirement for the Agent to verify before working.
+
+## Investigation produces a skeleton
+
+Explain the recognizable source signals and how to examine them cheaply.
+For code, identify useful feature families from declarations or registrations,
+with names and locations. A dependency or filename is a hint, not proof of
+runtime behavior. For documents, use titles, opening excerpts and heading
+hierarchy, with optional full reading to settle grouping. For saved notes and
+sessions, directly interpret the provided record rather than scanning history.
+
+A technology-specific helper, if needed, must have an explicit input boundary,
+bounded time/output and a useful stopping behavior. Return names, counts and
+entry locations, not source bodies or a full symbol/relationship graph during
+planning. Distinguish checked counts from totals and identify unfinished scope.
+Do not fabricate feature counts from file counts or silently treat timeouts as
+empty results. Store large results in temporary files rather than long stdout.
+
+Document any prerequisites and error recovery. Do not install dependencies,
+parse the whole repository or read unrelated modules by default. A helper that
+needs expensive semantic analysis belongs to selected writing tasks, not the
+initial investigation path. Direct Agent investigation is a valid default
+when a helper adds no useful capability.
+
+## Guide topics without owning the plan
+
+Describe which reader questions visible signals can suggest, and what further
+evidence the writer needs. A route family, component or storage boundary may
+justify a recurring outline, but not an automatic fixed number of pages.
+A component manual may require individual analysis during writing.
+
+Use existing article titles, descriptions and references as navigation, then
+read relevant bodies or sources when necessary. Code can establish structure;
+documents may supply better business topics. Multiple authorized sources may
+form an article. Avoid duplicating a page merely because another skill or
+source family supplied its material.
+
+The current stage provides available-skill declarations and temporary planned
+usage. The Agent selects useful skills and article batches. Keep uncertain
+investigation and real evidence gaps visible. Required scope cannot be dropped
+to reduce processing cost, and long-term exclusions require the applicable
+user decision.
+
+## Writing and file handoff
+
+Explain source authority, meaningful reader output, real references and
+revision behavior. Keep examples, assumptions and confirmed facts distinct.
+A session summary is not a transcript; a change URL is not proof of deployment;
+a declaration or test double is not independently verified runtime behavior.
+
+Consume the current task directory, not a copied schema from a past release.
+New articles use the supplied Markdown/reference contract; revisions can use
+the task's base article and fragment edits. Write drafts and manifests to the
+designated Agent temporary directory. The coordinator submits a finished
+subset through the current CLI action and follows its receipt or recovery.
+
+Do not write formal knowledge or mutate sources directly. Do not add a
+parallel Author/Composer result envelope, semantic graph, field-by-field fact
+ledger or skill identity to formal content. Source permissions, input
+baselines, real citations and safe writes remain CLI responsibilities.
+
+## Validate the claimed capability
+
+Check skill frontmatter and every referenced local resource. Run new scripts
+against small anonymous fixtures, including an empty input, a bounded partial
+scan and any failure/recovery behavior they claim. Confirm the helper does not
+escape its selected scope or emit secret/source-body dumps.
+
+Exercise useful output, insufficient evidence and a revision of an existing
+article. For source families advertised by the skill, include representative
+differences: an unadopted proposal, a document requiring optional deeper reading,
+or two technologies in one module. Do not claim support for families not tested.
+
+A static resource check does not prove semantic quality, and a reviewed example
+does not prove the CLI submission works. If an actual Context run is available
+and requested, validate through the existing workflow in an isolated workspace,
+including report confirmation and file submission. Report unavailable checks
+honestly; do not fabricate a route or silently install tools to make it pass.
+
+## Distribution
+
+Keep the package portable and use the user's chosen installation channel.
+The host lists available skills; planning records only useful temporary usage.
+Formal articles, sources and necessary long-term scope decisions survive a
+new machine. Unfinished drafts, candidates, skill choices and execution receipts
+remain temporary; a new user can start a fresh production run without restoring
+the former skill bundle or process.