@cleocode/skills 2026.10.3 → 2026.10.5-rc.ci.672

package/package.json

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

package/skills/ct-cleo/SKILL.md

@@ -2,14 +2,14 @@
 name: ct-cleo
 description: CLEO task management protocol - session, task, and workflow guidance. Use when managing tasks, sessions, or multi-agent workflows with the CLEO CLI protocol.
 metadata:
-  version: 2.24.4
+  version: 2.24.7
   tier: core
   install: harness
   covers:
     - packages/cleo/src/cli/commands/session.ts
     - packages/cleo/src/cli/commands/focus.ts
     - packages/cleo/src/cli/commands/sticky.ts
-  lastReviewed: 2026-10-01
+  lastReviewed: 2026-10-04
   stability: stable
 ---
 
@@ -464,4 +464,4 @@ BRAIN ID going forward.
 
 ## Evidence must prove task criteria
 
-Merged PRs and passing CI are provenance. Implementation requires changed artifacts related to the task; testing and review require their own actual results (`ci:<pr>` once the PR merged and the project sets `evidence.ciSatisfies`; else `tool:test-affected` when `testing.affectedCommand` is configured, otherwise a targeted `test-run:<json>` or `tool:test`; plan with `cleo done <id> --plan`, never run the suite by hand and again via `tool:test`). For tasks with canonical criteria, append explicit links such as `satisfies:T1234#AC1` to each relevant gate's evidence. Fetch the PR merge commit so artifact hashes can be inspected. A changed criterion invalidates its recorded proof. Completing a child preserves an open parent whose own criteria remain unproven; child waivers never transfer to parent criteria.
+Merged PRs and passing CI are provenance. Implementation requires changed artifacts related to the task; testing and review require their own actual results (`ci:<pr>` once the PR merged and the project sets `evidence.ciSatisfies`; else `tool:test-affected` when `testing.affectedCommand` is configured, otherwise a targeted `test-run:<json>` or `tool:test`; plan with `cleo done <id> --plan`, never run the suite by hand and again via `tool:test`). Run tests, typechecks and builds one at a time through `cleo run --wait --class <test|build|full-build> -- <cmd>` (exit 75: not admitted yet, wait and retry); never wrap `cleo run` or `cleo verify` in another queue or wrapper, and never raise heap or worker counts (`NODE_OPTIONS`, `--maxWorkers`). For tasks with canonical criteria, append explicit links such as `satisfies:T1234#AC1` to each relevant gate's evidence. Fetch the PR merge commit so artifact hashes can be inspected. A changed criterion invalidates its recorded proof. Completing a child preserves an open parent whose own criteria remain unproven; child waivers never transfer to parent criteria.

package/skills/ct-codebase-mapper/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ct-codebase-mapper
-version: 2.1.0
+version: 2.1.2
 description: Orient in an unfamiliar or large codebase with CLEO's code-intelligence graph (cleo nexus) and project map (cleo map). Use before planning or editing unfamiliar code, for brownfield onboarding, to find what a change would break, or to map a project's structure, communities and execution flows. Triggers on "map the codebase", "understand this project", "what calls X", "what would break", "brownfield analysis", "project structure".
 protocol: null
 dependencies: []
@@ -17,13 +17,13 @@ triggers:
   - project structure
   - blast radius
 metadata:
-  version: 2.1.0
+  version: 2.1.2
   tier: on-demand
   install: harness
   covers:
     - packages/cleo/src/cli/commands/nexus.ts
     - packages/cleo/src/cli/commands/map.ts
-  lastReviewed: 2026-09-29
+  lastReviewed: 2026-10-04
   stability: stable
 ---
 
@@ -50,6 +50,12 @@ Queries auto-refresh up to 25 stale files; beyond that they warn
 rebuilds). An empty or stale index gives confident-looking but incomplete
 answers — say which you relied on.
 
+Project-scoped queries use the declared portable project id. `--project-id`
+may name that id or a recorded, unambiguous legacy alias; an alias warns
+`W_NEXUS_LEGACY_PROJECT_ID`. A foreign or colliding id is refused: run the
+query from the intended checkout. Moving a checkout retains its id and graph;
+never derive a replacement id from the new path or re-analyze solely for a move.
+
 ## 2. Survey the project
 
 ```bash

package/skills/ct-dev-workflow/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ct-dev-workflow
 description: Development workflow orchestration for task-driven development with atomic commits, conventional commit messages, and systematic release processes. Enforces task traceability, branch discipline, smart test scope selection, and GitHub Actions integration. Use when committing code, creating releases, managing branches, or following contribution protocols. Triggers on commit operations, release preparation, or workflow compliance needs.
-version: 3.1.5
+version: 3.1.7
 protocol: contribution
 dependencies: []
 sharedResources:
@@ -14,12 +14,12 @@ compatibility:
   - gemini-cli
 license: MIT
 metadata:
-  version: 3.1.5
+  version: 3.1.7
   tier: core
   install: harness
   covers:
     - .github/workflows/release-prepare.yml
-  lastReviewed: 2026-09-30
+  lastReviewed: 2026-10-04
   stability: stable
 ---
 
@@ -282,12 +282,17 @@ git push origin HEAD
 
 **Release preflight (`release-prepare.yml`).** `cleo release open <version>`
 checks main's HEAD SHA and dispatches with `skip-tests=true` when the `ci.yml`
-push run for that SHA is green AND ran every Linux `Unit Tests` shard green (a
-docs-only push that skipped the tests does not count), and
-`skip-macos-tests=true` when the nightly macOS jobs for that SHA are green; the
-SHA travels as `verified-sha`, and the workflow ignores the skips if it checks
-out another commit or `verified-sha` is empty. Otherwise the 4
-Linux and 4 macOS test shards run. The decision is in the run summary.
+push run for that SHA, or for an ancestor reached only through release-plan
+commits (the plan file, changesets, CHANGELOG; T13140), is green AND ran every
+Linux `Unit Tests` shard green (a docs-only push that skipped the tests does
+not count). It sets `skip-macos-tests=true` when the newest completed nightly
+or `macos-main.yml` (main-push, never cancelled mid-run, pending pushes coalesce;
+T13143, T13187) run with macOS jobs for
+one of those commits is green. The SHA travels as `verified-sha`, and the
+workflow ignores the skips if it checks out another commit or `verified-sha` is
+empty. Otherwise the 8 Linux and 8 macOS test shards run, and the reason names
+the newest main commit that has a green macOS run. The decision is in the run
+summary.
 
 **Bump-PR merge.** Its `pull_request` runs stay `action_required` (no GitHub
 App), so the orchestrator admin-merges once the dispatched `CI` run on the PR

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.17.4
+version: 3.17.5
 protocol: null
 dependencies:
   - ct-spec-writer
@@ -16,13 +16,13 @@ compatibility:
   - gemini-cli
 license: MIT
 metadata:
-  version: 3.17.4
+  version: 3.17.5
   tier: core
   install: harness
   covers:
     - packages/cleo/src/cli/commands/docs.ts
     - packages/contracts/src/docs-taxonomy.ts
-  lastReviewed: 2026-09-30
+  lastReviewed: 2026-10-04
   stability: stable
 ---
 

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.0.8
+  version: 4.0.10
   tier: core
   install: harness
   covers:
     - packages/cleo/src/cli/commands/orchestrate.ts
     - packages/core/src/orchestration/spawn-prompt.ts
-  lastReviewed: 2026-10-01
+  lastReviewed: 2026-10-04
   stability: stable
 ---
 
@@ -356,6 +356,14 @@ needs no local run at all (`ci:<pr>`). When `testing.affectedCommand` is
 configured, a full `tool:test` is only for changes to root config, which
 affected planning refuses; without it, `tool:test` is the normal run.
 
+Every spawn prompt carries one governed path for heavy work (T13134), and the
+orchestrator follows it too: tests, typechecks and builds run one at a time
+through `cleo run --wait --class <test|build|full-build> -- <cmd>` (exit 75:
+not admitted yet, wait and retry). Never wrap `cleo run` or `cleo verify` in
+another queue or wrapper, never put one inside them (the lock systems
+deadlock), and never raise heap or worker counts (`NODE_OPTIONS`,
+`--maxWorkers`).
+
 Emergency: set `CLEO_OWNER_OVERRIDE=1` and `CLEO_OWNER_OVERRIDE_REASON="<reason>"`
 before the verify call — audited to `.cleo/audit/force-bypass.jsonl`.
 

package/skills/ct-release-orchestrator/SKILL.md

@@ -7,7 +7,7 @@ adrRefs:
   - ADR-063
   - ADR-065
 metadata:
-  version: 3.0.2
+  version: 3.2.0
   tier: on-demand
   install: harness
   covers:
@@ -15,7 +15,7 @@ metadata:
     - packages/core/src/validation/protocols/protocols-markdown/release.md
     - packages/cleo/src/cli/commands/release.ts
   loomStage: release
-  lastReviewed: 2026-09-28
+  lastReviewed: 2026-10-04
   stability: stable
 ---
 
@@ -34,10 +34,11 @@ Owns the canonical 4-verb release pipeline established by SPEC-T9345 and finalis
 | Step | Verb / Workflow | Owns transition | Notes |
 |-----:|------------------|------------------|-------|
 | 1 | `cleo release plan <ver> --epic <id>` | _(none)_ → `planned` | Builds the Release Plan envelope; auto-writes `CHANGELOG.md` (T10105 closes the silent-skip gap) |
-| 2 | `cleo release open <ver>` | `planned` → `pr-opened` | Dispatches `release-prepare.yml`; the workflow cuts the branch + opens the PR |
+| 2 | `cleo release open <ver>` | `planned` → `pr-opened` | Dispatches `release-prepare.yml` with the plan's sha256 once the plan is verified on the default branch, plus the verified preflight skips; the workflow cuts the branch + opens the PR |
 | 3 | _(GHA)_ `release-prepare.yml` → PR merge | `pr-opened` → `pr-merged` | Owned by CI; verify via `cleo release pr-status <ver>` |
 | 4 | `git tag -a v<ver> -m "Release v<ver>" && git push origin v<ver>` | `pr-merged` → `tag-pushed` | Explicit tag after the release PR merges — `auto-tag-on-release-merge.yml` is retired (T10434, ADR-087); the tag push triggers `release.yml` |
 | 5 | `cleo release reconcile <ver>` | `tag-pushed` → `published` | Backfills 11 provenance tables; idempotent |
+| 6 | _(GHA)_ `release.yml` Publish: release candidate gate | `<ver>-rc.ci.<n>` on `canary` → `<ver>` on `latest` | Automatic, OIDC only, no token (T13181). The candidate must install from npm and pass the sandbox soak (`scripts/release-canary-soak.mjs`) before the release publishes to `latest`; a failed gate leaves users on the previous release, and a re-run of the failed job continues. No dist-tag is ever moved by hand: a bad release is fixed forward with the next patch. Runbook: `docs/release/merge-queue-runbook.md`, "Release candidate gate" |
 
 Optional validators (read-only / dry-run):
 
@@ -67,8 +68,11 @@ Use the explicit verbs. **Do not** invoke `cleo release ship` — it was deleted
 # 1. Plan — build the canonical Release Plan envelope.
 cleo release plan v2026.6.0 --epic T10099
 
-# 2. Open — dispatch release-prepare workflow.
-cleo release open v2026.6.0
+# 2. Open — dispatch release-prepare workflow. When the plan reached main
+#    through a release-plan PR (branch protection), open it with
+#    --no-commit-plan: the plan on main is verified (read from there if this
+#    checkout lacks it) and dispatched by its sha256 (T13050).
+cleo release open v2026.6.0 --no-commit-plan
 
 # 3. (Optional) Poll PR + CI status while the workflow runs.
 cleo release pr-status v2026.6.0
@@ -108,7 +112,7 @@ Exit codes (canonical):
 | Pattern | Problem | Solution |
 |---------|---------|----------|
 | Running `cleo release ship` | The verb was deleted in T10103 — the command will exit with `Unknown command`. | Use `cleo release plan` + `cleo release open`. | <!-- cleo-cmd: negative-example: release ship -->
-| Manually invoking `gh workflow run release-prepare.yml` | Bypasses the plan envelope; `releases.status` stays at `planned`. | Always go through `cleo release open <ver>` — it tracks state in the `releases` table. |
+| Manually invoking `gh workflow run release-prepare.yml` | Bypasses the plan envelope; `releases.status` stays at `planned`; a hand dispatch also drops the verified `skip-tests` / `verified-sha` inputs, so the whole Linux and macOS suites run again (v2026.10.3 lost ~45 min). | Always go through `cleo release open <ver>` (`--no-commit-plan` after a plan PR) — it tracks state in the `releases` table and forwards the preflight skips. |
 | Tagging before the release PR merges, or `git push --tags` | Tags an unmerged commit, or pushes every local tag. | Tag the merged release commit and push that one tag: `git push origin v<ver>`. |
 | Hand-editing `CHANGELOG.md` for the new version | Drift between the changeset directory and the changelog. | `cleo release plan` always auto-writes the section (T10105). Use `cleo changeset add` to author entries. |
 | Pasting one verb into another's workflow file | Multi-step orchestration belongs in `ship-e2e-smoke`. | Use `cleo release ship-e2e-smoke … --execute` for end-to-end validation. |
@@ -125,6 +129,7 @@ Exit codes (canonical):
 6. Provenance reconcile is invoked by `release-publish.yml`, not manually (unless backfilling).
 7. Per-task evidence gates use `cleo verify --gate --evidence` per ADR-051 — not the deleted batch verb.
 8. Use `cleo release ship-e2e-smoke` to validate the full pipeline before a real ship.
+9. A stable release reaches `latest` only through release.yml's release candidate gate (T13181). If the gate fails, the release is not shipped to users: re-run the failed Publish job or fix forward; never move `latest` by hand (there is no npm token).
 
 ## CI Job Inventory
 

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.7.7
+version: 2.7.8
 protocol: implementation
 adrRefs:
   - ADR-070
@@ -17,7 +17,7 @@ compatibility:
   - gemini-cli
 license: MIT
 metadata:
-  version: 2.7.7
+  version: 2.7.8
   tier: core
   install: harness
   covers:
@@ -28,7 +28,7 @@ metadata:
     - packages/core/src/validation/protocols/cant/implementation.cant
     - packages/core/src/validation/protocols/protocols-markdown/implementation.md
   loomStage: implementation
-  lastReviewed: 2026-10-01
+  lastReviewed: 2026-10-03
   stability: stable
 ---
 

package/skills/ct-task-executor/references/evidence-and-gates.md

@@ -107,6 +107,29 @@ pnpm vitest run path/to/changed.test.ts --reporter=json --outputFile=/tmp/vitest
 cleo verify T### --gate testsPassed --evidence "test-run:/tmp/vitest-out.json"
 ```
 
+The report must carry one of these counter sets (gh#1804, T13136). The first
+set whose total is a number is read:
+
+| Runner | Total | Passed | Failed | Skipped / todo |
+|---|---|---|---|---|
+| vitest `--reporter=json`, jest `--json` | `numTotalTests` | `numPassedTests` | `numFailedTests` | `numPendingTests`, `numTodoTests` |
+| a runner's summary output (bun test, tsx --test) | `total` | `passed` | `failed` | `skipped`, `todo` |
+| node --test summary | `tests` | `pass` | `fail`, `cancelled` | `skipped`, `todo` |
+
+For example, `{"total":43,"passed":42,"failed":0,"skipped":1}`. Every count
+must be a non-negative integer, and passed + failed + skipped/todo must equal
+the total. A failure under any key (`numFailedTests`, `failed`, `fail`,
+`cancelled`, `failures`, `errors`) refuses, whichever set supplied the total.
+`exit` / `exitCode` must be a number, and a non-zero one is refused, as is a
+report with no passed test. A report without a counter set, or with counts that
+are not integers or do not add up, is refused with `E_EVIDENCE_INVALID`, and
+the message names the keys or the arithmetic. A `test-run:` atom proves only
+what its file says, so never write one by hand: `tool:test` and `ci:<pr>` are
+what prove the run. Only a vitest/jest report lists the test files
+it ran (`testResults`). In a workspace, a targeted report must cover every
+affected package that has tests, so a summary report with no file list is
+refused there: record `tool:test-affected` or `tool:test` instead.
+
 ### `decision:<decision-id>`
 
 A BRAIN decision ID (e.g., `D-arch-001`) or an `AGT-*` provenance ID.

package/skills/manifest.json

@@ -226,7 +226,7 @@
     },
     {
       "name": "ct-cleo",
-      "version": "2.24.4",
+      "version": "2.24.7",
       "description": "CLEO task management protocol - session, task, and workflow guidance. Use when managing tasks, sessions, or multi-agent workflows with the CLEO CLI protocol.",
       "path": "skills/ct-cleo",
       "tier": 0,
@@ -302,7 +302,7 @@
     },
     {
       "name": "ct-codebase-mapper",
-      "version": "2.1.0",
+      "version": "2.1.2",
       "description": "Orient in an unfamiliar or large codebase with CLEO's code-intelligence graph (cleo nexus) and project map (cleo map). Use before planning or editing unfamiliar code, for brownfield onboarding, to find what a change would break, or to map a project's structure, communities and execution flows. Triggers on \"map the codebase\", \"understand this project\", \"what calls X\", \"what would break\", \"brownfield analysis\", \"project structure\".",
       "path": "skills/ct-codebase-mapper",
       "tier": 1,
@@ -566,7 +566,7 @@
     },
     {
       "name": "ct-dev-workflow",
-      "version": "3.1.5",
+      "version": "3.1.7",
       "description": "Development workflow orchestration for task-driven development with atomic commits, conventional commit messages, and systematic release processes. Enforces task traceability, branch discipline, smart test scope selection, and GitHub Actions integration. Use when committing code, creating releases, managing branches, or following contribution protocols. Triggers on commit operations, release preparation, or workflow compliance needs.",
       "path": "skills/ct-dev-workflow",
       "tier": 0,
@@ -642,7 +642,7 @@
     },
     {
       "name": "ct-documentor",
-      "version": "3.17.4",
+      "version": "3.17.5",
       "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,
@@ -983,7 +983,7 @@
     },
     {
       "name": "ct-orchestrator",
-      "version": "4.0.8",
+      "version": "4.0.10",
       "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,
@@ -1150,7 +1150,7 @@
     },
     {
       "name": "ct-release-orchestrator",
-      "version": "3.0.2",
+      "version": "3.2.0",
       "description": "Orchestrates the canonical 4-verb release pipeline introduced by SPEC-T9345: cleo release plan, then cleo release open, then PR + GHA tag workflow, then cleo release reconcile. The deprecated cleo release ship monolith was deleted in T10103 — do not invoke it. Use ship-e2e-smoke to validate the full pipeline end-to-end (dry-run by default). The full verb-to-state map is in docs/release/verb-matrix.md. Use when shipping a new version, validating the release pipeline end-to-end, or promoting a completed epic to released status.",
       "path": "skills/ct-release-orchestrator",
       "tier": 1,
@@ -1472,7 +1472,7 @@
     },
     {
       "name": "ct-task-executor",
-      "version": "2.7.7",
+      "version": "2.7.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,