@cleocode/skills 2026.10.25 → 2026.10.26

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cleocode/skills",
-  "version": "2026.10.25",
+  "version": "2026.10.26",
   "description": "CLEO skill definitions - bundled with CLEO monorepo",
   "main": "index.js",
   "types": "index.d.ts",

package/skills/ct-documentor/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ct-documentor
 description: Documentation coordinator with CLEO style guide compliance. Routes every canonical-doc write (spec, adr, research, handoff, note, llm-readme) through the docs SSoT via `cleo docs add` / `cleo docs publish` / `cleo docs fetch` — never raw filesystem writes. Carries the CLEO writing and review guides as references and coordinates ct-spec-writer and ct-adr-recorder. Use when creating or updating documentation files, consolidating scattered documentation, or validating documentation against style standards. Triggers on documentation tasks, doc update requests, or style guide compliance checks.
-version: 3.26.0
+version: 3.27.0
 protocol: null
 dependencies:
   - ct-spec-writer
@@ -16,13 +16,13 @@ compatibility:
   - gemini-cli
 license: MIT
 metadata:
-  version: 3.26.0
+  version: 3.27.0
   tier: core
   install: harness
   covers:
     - packages/cleo/src/cli/commands/docs.ts
     - packages/contracts/src/docs-taxonomy.ts
-  lastReviewed: 2026-10-23
+  lastReviewed: 2026-10-27
   stability: stable
 ---
 
@@ -702,6 +702,11 @@ cleo docs publish --for T1234 --to docs/feature-x.md
 Atomic tmp-then-rename. The published file ships in the next commit; the
 SSoT blob remains canonical and continues to track future versions.
 
+`--to` must resolve under the project root (a relative path resolves there)
+or inside a registered canonical task worktree; anything else is refused with
+`E_VALIDATION_ERROR` and nothing is created. `--dry-run` runs the same checks
+and writes nothing, so a dry run that passes means the real run will.
+
 ### Fetch the doc back by slug
 
 ```bash

package/skills/ct-orchestrator/SKILL.md

@@ -2,13 +2,13 @@
 name: ct-orchestrator
 description: "Pipeline-aware orchestration skill for managing complex workflows through subagent delegation. Use when the user asks to \"orchestrate\", \"orchestrator mode\", \"run as orchestrator\", \"delegate to subagents\", \"coordinate agents\", \"spawn subagents\", \"multi-agent workflow\", \"context-protected workflow\", \"agent farm\", \"HITL orchestration\", \"pipeline management\", or needs to manage complex workflows by delegating work to subagents while protecting the main context window. Enforces ORC-001 through ORC-009 constraints. Provider-neutral — works with any AI agent runtime."
 metadata:
-  version: 4.1.4
+  version: 4.1.6
   tier: core
   install: harness
   covers:
     - packages/cleo/src/cli/commands/orchestrate.ts
     - packages/core/src/orchestration/spawn-prompt.ts
-  lastReviewed: 2026-10-25
+  lastReviewed: 2026-10-27
   stability: stable
 ---
 
@@ -159,7 +159,7 @@ then `full`. At `off` the block is omitted, so set the level before spawning, no
 
 The spawn provisions the worker's worktree, and its `pnpm install` is admitted through the heavy queue or deferred to the worker; the envelope's `install.status` says which. `cleo orchestrate spawn T1586 --no-install` provisions without installing, and the envelope names the command the worker runs instead (T13524).
 
-To start a worker from its dependencies' work, `cleo orchestrate spawn T1586 --base task/T1585` creates the task branch from that ref (branch, tag or sha) instead of HEAD; everything else (lock, session, guards) matches a normal spawn. The ref is resolved to a commit first and must exist (`E_WORKTREE_BASE_INVALID`), the primary checkout never moves, and the sha is recorded as `baseSha` in `.cleo/audit/worktree-lifecycle.jsonl`. An existing worktree or branch for the task with another base is refused with `E_WORKTREE_BASE_MISMATCH` and left untouched (T14027).
+To start a worker from its dependencies' work, `cleo orchestrate spawn T1586 --base task/T1585` creates the task branch from that ref (branch, tag or sha) instead of HEAD; everything else (lock, session, guards) matches a normal spawn. The ref is resolved to a commit first and must exist (`E_WORKTREE_BASE_INVALID`), the primary checkout never moves, and the sha is recorded as `baseSha` in `.cleo/audit/worktree-lifecycle.jsonl`. An existing worktree or branch for the task with another base is refused with `E_WORKTREE_BASE_MISMATCH` and left untouched (T14027). `cleo orchestrate spawn-execute T1586 --base task/T1585` takes the same flag; a provisioning failure under `--base` refuses the spawn instead of running the agent in the project root (T14046). `--include-deps` (T14045) starts the branch from a `--no-ff` merge of each dependency's `task/<id>` branch onto the base (HEAD, or `--base`), built in a temporary worktree under the canonical worktree root: the primary checkout never moves, a dependency with no branch (`E_INCLUDE_DEPS_MISSING`) or one that does not merge cleanly (`E_INCLUDE_DEPS_DIVERGED`) refuses the spawn, and the base and dependency shas are recorded in `.cleo/audit/worktree-integration.jsonl`.
 
 ### Step 2: Execute (Provider-Specific)
 
@@ -389,7 +389,9 @@ branch only when CLEO provisioned its worktree and the main checkout is on that
 branch with no uncommitted tracked changes; otherwise it skips or refuses, never
 switches the checkout and never pushes. Check `integration` in
 `cleo done <taskId> --plan` first; pass `--no-integrate` (or set
-`CLEO_NO_AUTO_WORKTREE_COMPLETE=1`) when the branch lands through a PR.
+`CLEO_NO_AUTO_WORKTREE_COMPLETE=1`) when the branch lands through a PR. The
+same variable stops `spawn-execute`'s post-spawn auto-complete, which writes a
+`complete-skip` row with `reason: 'env-override'` instead (T14057).
 
 Never re-run a worker's full suite to "double-check": a worker's
 `tool:test-affected` or `tool:test` result for the same tree and the

package/skills/ct-task-executor/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ct-task-executor
 description: General implementation task execution for completing assigned CLEO tasks by following instructions and producing concrete deliverables. Handles coding, configuration, documentation work with quality verification against acceptance criteria and progress reporting. Use when executing implementation tasks, completing assigned work, or producing task deliverables. Triggers on implementation tasks, general execution needs, or task completion work.
-version: 2.8.7
+version: 2.8.8
 protocol: implementation
 adrRefs:
   - ADR-070
@@ -17,7 +17,7 @@ compatibility:
   - gemini-cli
 license: MIT
 metadata:
-  version: 2.8.7
+  version: 2.8.8
   tier: core
   install: harness
   covers:
@@ -29,7 +29,7 @@ metadata:
     - packages/core/src/validation/protocols/cant/implementation.cant
     - packages/core/src/validation/protocols/protocols-markdown/implementation.md
   loomStage: implementation
-  lastReviewed: 2026-10-25
+  lastReviewed: 2026-10-26
   stability: stable
 ---
 
@@ -220,7 +220,7 @@ Record it with `cleo docs add {{TASK_ID}} --content - --type note --slug {{TOPIC
 
 ## Acceptance Criteria Verification
 
-Record each criterion's changed artifacts and actual verification results. A merged PR with green CI provides provenance; it cannot automatically satisfy implementation, testing and review. Use `pr:<number>;files:<changed-path>` for implementation (`pr:<component>@<integration>` when your PR merged into an integration branch) and actual result atoms for test/review gates, with explicit `satisfies:T1234#AC1` links for canonical criteria. The PR must relate to the task; documentation-only changes cannot prove a code fix. Research and documentation tasks may use appropriately scoped documentary evidence: they owe `verification.requiredGatesByKind` (default: the required gates without `testsPassed`/`qaPassed`), but once their work touches any non-document path they owe the full code gates, whatever their kind or labels. Fetch the merge commit before claiming its artifact bytes were inspected. Criterion edits require fresh evidence. A completed child does not establish that its parent's independent criteria were met. `cleo verify <id> --all` sets every required gate at once and still requires `--evidence`; bare `--all` is rejected with `E_EVIDENCE_MISSING`. A failing `tool:<name>` reason names the resolved command and its source, so check that command before retrying. To adopt a native typecheck or lint run for `qaPassed` without re-running it, record one `qa-run:<receipt.json>` per check (`cleo verify --help` lists the receipt shape).
+Record each criterion's changed artifacts and actual verification results. A merged PR with green CI provides provenance; it cannot automatically satisfy implementation, testing and review. Use `pr:<number>;files:<changed-path>` for implementation (`pr:<component>@<integration>` when your PR merged into an integration branch) and actual result atoms for test/review gates, with explicit `satisfies:T1234#AC1` links for canonical criteria. The PR must relate to the task; documentation-only changes cannot prove a code fix. Research and documentation tasks may use appropriately scoped documentary evidence: they owe `verification.requiredGatesByKind` (default: the required gates without `testsPassed`/`qaPassed`), but once their work touches any non-document path they owe the full code gates, whatever their kind or labels. Fetch the merge commit before claiming its artifact bytes were inspected. Criterion edits require fresh evidence. A completed child does not establish that its parent's independent criteria were met. `cleo verify <id> --all` sets every required gate at once and still requires `--evidence`; bare `--all` is rejected with `E_EVIDENCE_MISSING`. A failing `tool:<name>` reason names the resolved command and its source, so check that command before retrying. To adopt a native typecheck or lint run for `qaPassed` without re-running it, record one `qa-run:<receipt.json>` per check (`cleo verify --help` lists the receipt shape). A change with unit and e2e tests can record both runs in one write, `test-run:<vitest.json>;test-run:<playwright.json>` (Playwright `--reporter=json`): their passing test files cover the change together.
 
 
 | Criterion | Status | Notes |

package/skills/manifest.json

@@ -642,7 +642,7 @@
     },
     {
       "name": "ct-documentor",
-      "version": "3.26.0",
+      "version": "3.27.0",
       "description": "Documentation coordinator with CLEO style guide compliance. Routes every canonical-doc write (spec, adr, research, handoff, note, llm-readme) through the docs SSoT via `cleo docs add` / `cleo docs publish` / `cleo docs fetch` — never raw filesystem writes. Carries the CLEO writing and review guides as references and coordinates ct-spec-writer and ct-adr-recorder. Use when creating or updating documentation files, consolidating scattered documentation, or validating documentation against style standards. Triggers on documentation tasks, doc update requests, or style guide compliance checks.",
       "path": "skills/ct-documentor",
       "tier": 0,
@@ -1001,7 +1001,7 @@
     },
     {
       "name": "ct-orchestrator",
-      "version": "4.1.4",
+      "version": "4.1.6",
       "description": "Pipeline-aware orchestration skill for managing complex workflows through subagent delegation. Use when the user asks to \\\"orchestrate\\\", \\\"orchestrator mode\\\", \\\"run as orchestrator\\\", \\\"delegate to subagents\\\", \\\"coordinate agents\\\", \\\"spawn subagents\\\", \\\"multi-agent workflow\\\", \\\"context-protected workflow\\\", \\\"agent farm\\\", \\\"HITL orchestration\\\", \\\"pipeline management\\\", or needs to manage complex workflows by delegating work to subagents while protecting the main context window. Enforces ORC-001 through ORC-009 constraints. Provider-neutral — works with any AI agent runtime.",
       "path": "skills/ct-orchestrator",
       "tier": 0,
@@ -1489,7 +1489,7 @@
     },
     {
       "name": "ct-task-executor",
-      "version": "2.8.7",
+      "version": "2.8.8",
       "description": "General implementation task execution for completing assigned CLEO tasks by following instructions and producing concrete deliverables. Handles coding, configuration, documentation work with quality verification against acceptance criteria and progress reporting. Use when executing implementation tasks, completing assigned work, or producing task deliverables. Triggers on implementation tasks, general execution needs, or task completion work.",
       "path": "skills/ct-task-executor",
       "tier": 0,