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

package/plugins/VERSION

@@ -1 +1 @@
-0.7.9
+0.7.10-alpha.1

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "c4a",
   "description": "Start or continue a project-local knowledge workspace through one graph-routed entry.",
-  "version": "0.7.9",
+  "version": "0.7.10-alpha.1",
   "author": {
     "name": "c4a"
   },

package/plugins/claude/commands/context.md

@@ -192,13 +192,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

package/plugins/claude/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/claude/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.

package/plugins/codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "c4a",
-  "version": "0.7.9",
+  "version": "0.7.10-alpha.1",
   "description": "Start or continue a project-local knowledge workspace through one graph-routed entry.",
   "author": { "name": "c4a" },
   "homepage": "https://github.com/context4ai/c4a",
@@ -10,7 +10,7 @@
   "skills": "./skills/",
   "interface": {
     "displayName": "C4A Context",
-    "shortDescription": "Initialize and advance a local, source-linked project knowledge workspace.\nv0.7.9",
+    "shortDescription": "Initialize and advance a local, source-linked project knowledge workspace.\nv0.7.10-alpha.1",
     "longDescription": "Create a Context workspace and use agent-guided next steps to register sources, run extraction, review candidates, build package outputs, and verify health without silently mutating source repositories.",
     "developerName": "c4a",
     "category": "Productivity",

package/plugins/codex/skills/context/SKILL.md

@@ -190,13 +190,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

package/plugins/codex/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.