@cleocode/skills 2026.9.20 → 2026.9.22

package/skills/ct-ivt-looper/SKILL.md

@@ -2,10 +2,19 @@
 name: ct-ivt-looper
 description: "Runs a project-agnostic autonomous Implement-then-Validate-then-Test compliance loop on any git worktree. Detects the project's test framework (vitest, jest, mocha, pytest, unittest, go-test, cargo-test, rspec, phpunit, bats, or other) and iterates until the implementation satisfies its specification, recording convergence metrics to the manifest. Use when given an implementation task that must ship verified: the IVT loop is the autonomous compliance layer enforced before any release or PR. Triggers on phrases like 'implement and verify', 'run the IVT loop', 'ship this task', 'complete implementation with tests', 'verify against spec', or any implementation task with acceptance criteria. Works in any git worktree regardless of language or framework, never hardcoded to one project's tooling."
 protocol: testing
-loomStage: testing
 adrRefs:
   - ADR-051
   - ADR-061
+metadata:
+  version: 1.0.2
+  tier: on-demand
+  install: harness
+  covers:
+    - packages/core/src/validation/protocols/cant/testing.cant
+    - packages/core/src/validation/protocols/protocols-markdown/testing.md
+  loomStage: testing
+  lastReviewed: 2026-09-28
+  stability: stable
 ---
 
 # IVT Looper
@@ -147,24 +156,22 @@ Record the loop outcome through `cleo check protocol`:
 
 ```bash
 # Success case: loop converged on iteration 3.
-cleo check protocol \
-  --protocolType testing \
+cleo check protocol testing \
   --framework vitest \
-  --testsRun 142 \
-  --testsPassed 142 \
-  --testsFailed 0 \
-  --ivtLoopConverged true \
-  --ivtLoopIterations 3
+  --tests-run 142 \
+  --tests-passed 142 \
+  --tests-failed 0 \
+  --ivt-loop-converged true \
+  --ivt-loop-iterations 3
 
 # Failure case: loop exhausted iterations, HITL escalation.
-cleo check protocol \
-  --protocolType testing \
+cleo check protocol testing \
   --framework pytest \
-  --testsRun 87 \
-  --testsPassed 84 \
-  --testsFailed 3 \
-  --ivtLoopConverged false \
-  --ivtLoopIterations 5
+  --tests-run 87 \
+  --tests-passed 84 \
+  --tests-failed 3 \
+  --ivt-loop-converged false \
+  --ivt-loop-iterations 5
 ```
 
 Exit code 0 = loop converged and protocol is valid. Exit code 65 = `HANDOFF_REQUIRED` (non-convergence).
@@ -172,11 +179,10 @@ Exit code 0 = loop converged and protocol is valid. Exit code 65 = `HANDOFF_REQU
 This skill MUST also chain a validation check against the spec before its own testing check:
 
 ```bash
-cleo check protocol \
-  --protocolType validation \
-  --specMatchConfirmed true \
-  --testSuitePassed true \
-  --protocolComplianceChecked true
+cleo check protocol validation \
+  --spec-match-confirmed true \
+  --test-suite-passed true \
+  --protocol-compliance-checked true
 ```
 
 ## Anti-Patterns
@@ -201,7 +207,7 @@ cleo check protocol \
 5. Never run on `main`, `master`, or `trunk` — stop and request a feature branch.
 6. Record `framework`, `testsRun`, `testsPassed`, `testsFailed`, `ivtLoopConverged`, `ivtLoopIterations` in the manifest.
 7. On non-convergence, exit 65 and leave the worktree untouched.
-8. Validate every run via `cleo check protocol --protocolType testing`.
+8. Validate every run via `cleo check protocol testing`.
 
 ## See also / References
 

package/skills/ct-lead/SKILL.md

@@ -1,6 +1,15 @@
 ---
 name: ct-lead
-description: "Phase Lead orchestration playbook for spawning and supervising a parallel worker swarm in one wave. Use when spawned by ct-orchestrator with role=orchestrator to fan out N leaf workers via delegate_task, drain the epic-<TID>.wave-<n> conduit topic plus pipeline_manifest, await rollupWaveStatus convergence, and return ONE rolled-up contract string to the parent Orchestrator. Triggers: 'phase lead', 'wave lead', 'supervise wave', 'fan out workers', 'aggregate worker results', 'rollup wave', any task with role=orchestrator that is itself a child of another orchestrator. Implements ADR-070 hierarchical orchestration."
+description: "Phase Lead orchestration playbook for spawning and supervising a parallel worker swarm in one wave. Use when spawned by ct-orchestrator with role=orchestrator to fan out N leaf workers via delegate_task, drain the epic-{TID}.wave-{n} conduit topic plus pipeline_manifest, await rollupWaveStatus convergence, and return ONE rolled-up contract string to the parent Orchestrator. Triggers: 'phase lead', 'wave lead', 'supervise wave', 'fan out workers', 'aggregate worker results', 'rollup wave', any task with role=orchestrator that is itself a child of another orchestrator. Implements ADR-070 hierarchical orchestration."
+metadata:
+  version: 1.0.5
+  tier: core
+  install: harness
+  covers:
+    - packages/core/src/orchestration/lead-rollup.ts
+    - packages/core/src/orchestration/waves.ts
+  lastReviewed: 2026-09-28
+  stability: stable
 ---
 
 # Phase Lead Protocol (ct-lead)
@@ -28,7 +37,7 @@ exactly ONE aggregated summary.
 |----|------|-------------------|
 | LEAD-005 | Subscribe BEFORE spawn | Subscribe to `epic-<TID>.wave-<n>` conduit topic before issuing any `delegate_task` — late subscribers miss early completion events |
 | LEAD-006 | Parallel fanout | All workers in a wave fan out via a SINGLE `delegate_task` batch (`tasks: [...]`) — never sequential per-worker calls |
-| LEAD-007 | Bounded by `delegation.max_concurrent_children` | Wave width MUST NOT exceed the configured cap (default 10); split into multiple waves if larger |
+| LEAD-007 | Bounded by `maxConcurrent` (default 10) | Wave width MUST NOT exceed it; split into multiple waves if larger. No config key or runtime check enforces this yet (`delegation.max_concurrent_children` is not read by CLEO) — the Lead enforces it |
 | LEAD-008 | Convergence over polling | Wait on conduit signals + `rollupWaveStatus`; do not poll task status in a busy loop |
 | LEAD-009 | Roll up via `rollupWaveStatus` | Always call `rollupWaveStatus(epicId, waveId)` before returning — never hand-aggregate manifest rows |
 | LEAD-010 | One summary upstream | Return ONE contract string to parent Orchestrator; detail lives in pipeline_manifest under your wave's roll-up entry |
@@ -44,7 +53,7 @@ The parent Orchestrator spawns you with a resolved prompt containing:
 | `waveId` | Wave index within the epic (e.g., `wave-2`) |
 | `workerTasks[]` | Pre-resolved leaf task IDs in this wave (deps already satisfied) |
 | `conduitTopic` | `epic-<epicId>.wave-<waveId>` — your subscription topic |
-| `maxConcurrent` | Effective `delegation.max_concurrent_children` |
+| `maxConcurrent` | Wave width cap passed by the parent (default 10) |
 | `subagentTimeoutSeconds` | Default 600 — wall-clock budget per worker |
 
 ## Workflow
@@ -53,10 +62,11 @@ The parent Orchestrator spawns you with a resolved prompt containing:
 
 ```bash
 # Subscribe FIRST — race-free (LEAD-005)
-cleo conduit subscribe "epic-${EPIC}.wave-${WAVE}" --as-lead
+cleo conduit subscribe --topic "epic-${EPIC}.wave-${WAVE}"
 
-# Verify the wave is well-formed
-cleo orchestrate ready --epic "${EPIC}" --wave "${WAVE}" --json
+# Verify the wave is well-formed: ready tasks and the computed wave plan
+cleo orchestrate ready "${EPIC}"
+cleo orchestrate waves "${EPIC}"
 ```
 
 ### 2. Parallel Fanout (one batch)
@@ -80,16 +90,43 @@ delegate_task({
 ### 3. Convergence (drain conduit + manifest)
 
 ```bash
-# Block on conduit signals — fires on every worker terminal status
-cleo conduit await "epic-${EPIC}.wave-${WAVE}" \
-  --expect "${WORKER_COUNT}" \
-  --timeout 600
+# WAVE = the wave number `cleo orchestrate waves` prints now (1-based);
+# topic and roll-up use the same number.
+
+# Read worker terminal signals on the wave topic. There is no blocking
+# await: poll with --since between checks, bounded by the wave budget.
+cleo conduit listen --topic "epic-${EPIC}.wave-${WAVE}" --since "${SPAWNED_AT}"
 
 # Roll up authoritative status from pipeline_manifest
-cleo lead rollup --epic "${EPIC}" --wave "${WAVE}" --json \
+cleo orchestrate roll-up "${EPIC}" --wave "${WAVE}" --json \
   > /tmp/rollup-${EPIC}-${WAVE}.json
 ```
 
+> **Wave contract (T12682).** One wave number `n` names everything: it is
+> the 1-based number `cleo orchestrate waves <epic>` prints, spawned workers
+> publish on `epic-<epicId>.wave-<n>`, and `cleo orchestrate roll-up <epic>
+> --wave <n>` takes the same `n` (`--wave 0` is refused with
+> `E_CLEO_VALIDATION`, pointing at `cleo orchestrate waves`).
+>
+> **What a wave number guarantees (T12683).** A task's wave is its
+> structural dependency depth: 1 plus the deepest wave among its
+> dependencies, whatever their status and whichever epic holds them.
+>
+> - **Stable** when any task's status changes (done, cancelled, archived)
+>   or a task moves between epics. A finished wave stays in `cleo
+>   orchestrate waves` with status `completed`; `--hide-completed` omits
+>   finished waves without renumbering the rest.
+> - **Not stable** when a dependency edge is added or removed anywhere
+>   upstream, including in another epic: downstream waves shift. If you
+>   subscribed ahead to `epic-<epicId>.wave-<n>`, re-read `cleo orchestrate
+>   waves` after any dependency change.
+> - **Numbers can skip, and an epic's first wave can be above 1** (a task
+>   whose external prerequisite sits at depth 3 is in wave 4). Always take
+>   `n` from `cleo orchestrate waves`; never assume the first wave is 1.
+>
+> `orchestrate ready`, `plan` and `parallel start --wave <n>` never re-run
+> finished tasks.
+
 `rollupWaveStatus` (T9082, `packages/core/src/orchestration/lead-rollup.ts`)
 returns `{ wave, total, complete, partial, blocked, failed, workers: [...] }`.
 
@@ -128,7 +165,7 @@ cleo manifest append \
 - **Sequential fanout**: spawning workers one-by-one defeats parallelism and breaks the wave model — use ONE batch (LEAD-006).
 - **Recursive Leads**: do NOT spawn a Lead from within a Lead — escalate to parent Orchestrator with a `blocked` contract instead (LEAD-003).
 - **Forwarding raw outputs**: never paste worker manifest entries upstream — parent's context budget assumes ONE rollup string per wave (LEAD-004).
-- **Polling**: do not `while true; sleep` on task status — use `cleo conduit await` (LEAD-008).
+- **Polling task status**: do not `while true; sleep` on `cleo show` — read the wave topic with `cleo conduit listen --topic … --since …` and aggregate with `cleo orchestrate roll-up` (LEAD-008).
 - **Unbounded retries**: cap local retry at 1 per worker — repeated failure escalates to parent.
 
 ## Cross-references

package/skills/ct-lead/references/aggregation-protocol.md

@@ -21,12 +21,12 @@ fast-finishing workers and silently loses early `complete` signals.
 
 ```bash
 # CORRECT — subscribe, then spawn
-cleo conduit subscribe "epic-T9080.wave-2" --as-lead
-cleo orchestrate spawn-batch --tasks T9301,T9302,T9303 ...
+cleo conduit subscribe --topic "epic-T9080.wave-2"
+cleo orchestrate fanout T9080 --tasks T9301,T9302,T9303
 
 # WRONG — fanout, then subscribe (race window)
-cleo orchestrate spawn-batch --tasks T9301,T9302,T9303 ...
-cleo conduit subscribe "epic-T9080.wave-2" --as-lead   # may miss T9301 done
+cleo orchestrate fanout T9080 --tasks T9301,T9302,T9303
+cleo conduit subscribe --topic "epic-T9080.wave-2"   # may miss T9301 done
 ```
 
 The conduit retains buffered signals for `conduit.replay_window` (default 30s)
@@ -36,19 +36,44 @@ to defend against tiny races, but relying on the buffer is brittle.
 
 ## 2. Drain loop
 
-The Lead blocks on `cleo conduit await` which yields when the expected number
-of terminal signals arrive OR the wall-clock timeout elapses.
+There is no blocking await. The Lead polls the wave topic with
+`cleo conduit listen --topic <topic> --since <last-seen>` until the expected number of
+terminal signals has arrived OR its wall-clock budget elapses.
 
 ```bash
-cleo conduit await "epic-T9080.wave-2" \
-  --expect 5 \
-  --timeout 600 \
-  --json > /tmp/conduit-drain.json
+cleo conduit listen --topic "epic-T9080.wave-2" --since "${SPAWNED_AT}" \
+  > /tmp/conduit-drain.json
 
-# Then read authoritative state from manifest
-cleo lead rollup --epic T9080 --wave wave-2 --json > /tmp/rollup.json
+# Then read authoritative state from manifest — same wave number as the topic.
+cleo orchestrate roll-up T9080 --wave 2 --json > /tmp/rollup.json
 ```
 
+> **Wave contract (T12682).** One wave number `n` names everything: it is
+> the 1-based number `cleo orchestrate waves <epic>` prints, spawned workers
+> publish on `epic-<epicId>.wave-<n>`, and `cleo orchestrate roll-up <epic>
+> --wave <n>` takes the same `n` (`--wave 0` is refused with
+> `E_CLEO_VALIDATION`, pointing at `cleo orchestrate waves`).
+>
+> **What a wave number guarantees (T12683).** A task's wave is its
+> structural dependency depth: 1 plus the deepest wave among its
+> dependencies, whatever their status and whichever epic holds them.
+>
+> - **Stable** when any task's status changes (done, cancelled, archived)
+>   or a task moves between epics. A finished wave stays in `cleo
+>   orchestrate waves` with status `completed`; `--hide-completed` omits
+>   finished waves without renumbering the rest.
+> - **Not stable** when a dependency edge is added or removed anywhere
+>   upstream, including in another epic: downstream waves shift. If you
+>   subscribed ahead to `epic-<epicId>.wave-<n>`, re-read `cleo orchestrate
+>   waves` after any dependency change.
+> - **Numbers can skip, and an epic's first wave can be above 1** (a task
+>   whose external prerequisite sits at depth 3 is in wave 4). Always take
+>   `n` from `cleo orchestrate waves`; never assume the first wave is 1.
+>
+> `orchestrate ready`, `plan` and `parallel start --wave <n>` never re-run
+> finished tasks.
+
+
 `rollupWaveStatus` returns:
 
 ```json
@@ -94,15 +119,13 @@ Local retry shape:
 RETRIABLE=$(jq -r '.workers[] | select(.status=="failed" and (.reason|test("testsPassed|qaPassed|INFRASTRUCTURE"))) | .taskId' /tmp/rollup.json)
 
 # Re-spawn ONLY those (NEW conduit topic suffix to avoid replay collision)
-cleo orchestrate spawn-batch \
-  --parent "${LEAD_TASK_ID}" --parent-role orchestrator \
-  --topic "epic-T9080.wave-2.retry-1" \
-  --tasks "$(echo $RETRIABLE | tr ' ' ,)" \
-  --child-role leaf --timeout 600
-
-# Re-drain on the retry topic, merge into final rollup
-cleo conduit await "epic-T9080.wave-2.retry-1" --expect $(echo $RETRIABLE | wc -w) --timeout 600
-cleo lead rollup --epic T9080 --wave wave-2 --include-retries --json > /tmp/rollup-final.json
+cleo conduit subscribe --topic "epic-T9080.wave-2.retry-1"
+cleo orchestrate fanout T9080 --tasks "$(echo $RETRIABLE | tr ' ' ,)"
+
+# Re-drain on the retry topic, then roll up again (the manifest holds the
+# latest status of every worker, retries included)
+cleo conduit listen --topic "epic-T9080.wave-2.retry-1" --since "${RETRY_AT}"
+cleo orchestrate roll-up T9080 --wave 2 --json > /tmp/rollup-final.json
 ```
 
 After the single retry pass, whatever `rollup-final.json` shows IS the

package/skills/ct-lead/references/spawn-pattern.md

@@ -1,7 +1,7 @@
 # Spawn Pattern — Worker Fanout Examples
 
 The Phase Lead fans out all workers in a single `delegate_task` batch.
-Width is bounded by `delegation.max_concurrent_children` (default 10).
+Width is bounded by `maxConcurrent` (default 10; a convention the Lead enforces — no runtime check exists).
 Each child carries `role=leaf` and inherits the wave's conduit topic.
 
 All examples assume:
@@ -32,15 +32,14 @@ Typical for narrowly-scoped IVTR waves where deps fan in tightly.
 }
 ```
 
-CLI equivalent (one shell call, NOT a loop):
+CLI equivalent (one shell call, NOT a loop). `fanout` takes the epic and the
+task list only; role, model and timeout come from each task's spawn prompt
+(`cleo orchestrate spawn <taskId>`), and the Lead subscribes to the wave topic
+before it runs:
 
 ```bash
-cleo orchestrate spawn-batch \
-  --parent T9080-lead-w2 --parent-role orchestrator \
-  --topic epic-T9080.wave-2 \
-  --timeout 600 \
-  --tasks T9101,T9102,T9103 \
-  --child-role leaf --model sonnet
+cleo conduit subscribe --topic epic-T9080.wave-2
+cleo orchestrate fanout T9080 --tasks T9101,T9102,T9103
 ```
 
 ---
@@ -69,7 +68,7 @@ cleo orchestrate spawn-batch \
 
 ## Example 3 — 10-worker fanout (max-width wave)
 
-This is the upper bound at default `delegation.max_concurrent_children = 10`.
+This is the upper bound at the default `maxConcurrent = 10`.
 For wider waves, the parent Orchestrator MUST split into multiple Leads.
 
 ```json
@@ -111,10 +110,12 @@ done
 DO NOT exceed `maxConcurrent`:
 
 ```bash
-# WRONG — runtime rejects with E_WAVE_OVERSIZED
-cleo orchestrate spawn-batch --tasks $(seq -s, T9301 T9320)   # 20 > 10
+# WRONG — 20 workers in one wave; split into waves of at most maxConcurrent
+cleo orchestrate fanout T9300 --tasks $(seq -s, T9301 T9320)
 ```
 
+Nothing in the runtime enforces the cap today; the Lead must.
+
 DO NOT spawn workers with `role=orchestrator`:
 
 ```json

package/skills/ct-orchestrator/README.md

@@ -27,8 +27,8 @@ Skill: orchestrator
 
 Install to your project for persistent availability:
 ```bash
-cleo orchestrate skill --install    # Copy to .cleo/skills/
-cleo orchestrate skill --verify     # Verify installation
+cleo skills install ct-orchestrator   # install to your agent directory
+cleo skills info ct-orchestrator      # verify it resolves
 ```
 
 ## Files

package/skills/ct-orchestrator/SKILL.md

@@ -2,8 +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: 2.8.0
-  lastReviewed: 2026-09-19
+  version: 4.0.4
+  tier: core
+  install: harness
+  covers:
+    - packages/cleo/src/cli/commands/orchestrate.ts
+    - packages/core/src/orchestration/spawn-prompt.ts
+  lastReviewed: 2026-09-28
   stability: stable
 ---
 
@@ -92,7 +97,7 @@ Runs **autonomously on every incoming issue**. Decomposes ideas into executable
 | **Specification** | Write formal spec with RFC 2119 language, acceptance criteria | Lead (reasoning) |
 | **Decomposition** | Break into atomic tasks with deps under epic(s) | Lead (reasoning) |
 
-**RCASD output**: Epic(s) with child tasks, spec documents attached, dependency graph defined, acceptance criteria on every task. Architecture decisions stored in BRAIN decision-store via `cleo memory store --type decision`, not in adrs markdown blobs.
+**RCASD output**: Epic(s) with child tasks, spec documents attached, dependency graph defined, acceptance criteria on every task. Architecture decisions stored in BRAIN decision-store via `cleo memory decision-store --decision "..." --rationale "..."`, not in adrs markdown blobs.
 
 ### IVTR Phase (Execution)
 
@@ -135,7 +140,7 @@ Spawning is a **two-step pattern** — CLEO prepares the prompt, then the provid
 
 ```bash
 # Get next dependency-safe task
-cleo orchestrate ready --epic T1575
+cleo orchestrate ready T1575
 
 # Generate fully-resolved spawn prompt
 cleo orchestrate spawn T1586 --json
@@ -176,7 +181,7 @@ After successful verification, subagents MUST return exactly one of:
 cleo session status              # Resume existing?
 cleo dash                        # Project overview
 cleo current                     # Active task?
-cleo orchestrate start --epic T1575  # Full state: session, pipeline, next task
+cleo orchestrate start T1575  # Full state: session, pipeline, next task
 ```
 
 ### 2. RCASD — Plan the Work
@@ -197,11 +202,12 @@ cleo orchestrate start --epic T1575  # Full state: session, pipeline, next task
 ### 3. IVTR — Execute the Work
 
 ```
-1. Identify Wave 0: cleo orchestrate ready --epic T1575
-2. Spawn Workers in parallel for each Wave 0 task
+1. Read the waves: cleo orchestrate waves T1575 (take each wave n from here;
+   numbers can skip and the first need not be 1), then cleo orchestrate ready T1575
+2. Spawn Workers in parallel for each ready task in the first incomplete wave
 3. On completion: read manifest, check acceptance criteria
 4. If criteria NOT met → re-spawn worker with feedback (IVTR loop)
-5. Advance to Wave 1 (tasks whose deps are now done)
+5. Advance to the next wave cleo orchestrate waves lists (its deps are now done)
 6. Repeat until all tasks complete
 7. Final validation with Lead across the full epic
 ```
@@ -229,6 +235,23 @@ On an idle host every ready task is `admitted` and behaviour is unchanged.
 ### 4. Report to Human
 
 After each wave or on request: what completed, blockers needing HITL, next actions.
+Report only when work is done or a decision is needed; no routine status chatter.
+
+## Asking the Owner (HITL ask tool)
+
+Whenever the owner must answer, decide, approve or choose ANYTHING, ask through
+the ask tool (`AskUserQuestion` in Claude Code, or the provider equivalent from
+CAAMP's `PROVIDER_ASK_TOOLS`) with concrete, detailed, selectable options. Never
+ask inside a response, and never bury a question or decision in prose. Each option
+states what happens and its trade-offs, with the recommended option first.
+
+- **Subagent relay.** Subagents never ask the human (most harnesses deny them the
+  ask tool). A subagent that needs a decision returns `blocked` with
+  `{question, options[{label, description}], recommended}` in its manifest entry;
+  you, the orchestrator, put that question to the owner via your ask tool, then
+  re-spawn or continue with the answer.
+- **Fallback.** When your harness has no ask tool, emit one LAFS `hitl.request`
+  envelope `{question, options[{label, description}], recommended}` and stop.
 
 ## Handoff Chain Protocol
 
@@ -262,10 +285,10 @@ When operating without continuous HITL oversight, additional constraints apply:
 
 | Command | Purpose |
 |---------|---------|
-| `cleo orchestrate start --epic T1575` | Full startup: session + pipeline + next task |
-| `cleo orchestrate ready --epic T1575` | Parallel-safe tasks in current wave |
+| `cleo orchestrate start T1575` | Full startup: session + pipeline + next task |
+| `cleo orchestrate ready T1575` | Parallel-safe tasks in current wave |
 | `cleo orchestrate spawn T1586 --json` | Generate resolved spawn prompt |
-| `cleo orchestrate next --epic T1575` | Suggest next task |
+| `cleo orchestrate next T1575` | Suggest next task |
 | `cleo saga rollup <sagaId>` | Cross-Epic status aggregation when orchestrating a multi-Epic Saga (ADR-073) |
 | `cleo saga members <sagaId>` | Member Epics of a Saga (parent_id containment — NOT `task_relations.groups`) |
 | `cleo pipeline stage.status --epic T1575` | Current pipeline stage |

package/skills/ct-orchestrator/references/SUBAGENT-PROTOCOL-BLOCK.md

@@ -8,8 +8,8 @@ Copy and include this block in EVERY subagent prompt spawned via Task tool.
 ## SUBAGENT PROTOCOL (RFC 2119 - MANDATORY)
 
 OUTPUT REQUIREMENTS:
-1. MUST write findings to: {{OUTPUT_DIR}}/YYYY-MM-DD_{topic}.md
-2. MUST append ONE entry via `cleo manifest append <json>` (writes to pipeline_manifest table per ADR-027/T1093)
+1. MUST record findings with `cleo docs add {{TASK_ID}} --content - --type <kind> --slug {{TOPIC_SLUG}}` (never a raw file under `.cleo/agent-outputs/`)
+2. MUST append ONE entry via `cleo manifest append --entry '<json>'` (writes to pipeline_manifest table per ADR-027/T1093)
 3. MUST return ONLY: "Research complete. Manifest appended to pipeline_manifest."
 4. MUST NOT return research content in response.
 
@@ -33,8 +33,8 @@ You are the {ROLE} subagent. Your job is to complete CLEO task {TASK_ID}.
 
 ## SUBAGENT PROTOCOL (RFC 2119 - MANDATORY)
 OUTPUT REQUIREMENTS:
-1. MUST write findings to: {{OUTPUT_DIR}}/YYYY-MM-DD_{topic}.md
-2. MUST append ONE entry via `cleo manifest append <json>` (writes to pipeline_manifest table per ADR-027/T1093)
+1. MUST record findings with `cleo docs add {{TASK_ID}} --content - --type <kind> --slug {{TOPIC_SLUG}}` (never a raw file under `.cleo/agent-outputs/`)
+2. MUST append ONE entry via `cleo manifest append --entry '<json>'` (writes to pipeline_manifest table per ADR-027/T1093)
 3. MUST return ONLY: "Research complete. Manifest appended to pipeline_manifest."
 4. MUST NOT return research content in response.
 

package/skills/ct-orchestrator/references/autonomous-operation.md

@@ -115,19 +115,19 @@ HANDOFF CONTENTS:
 
 ```bash
 # 1. Read last handoff
-cleo research list --type handoff --limit 1
+cleo docs list --type handoff --project
 
 # 2. Verify session exists
-cleo session status <session_id>
+cleo session show <session_id>
 
 # 3. Check for concurrent modifications
-cleo session list --scope epic:<epic_id>
+cleo session list --status active
 
 # 4. Resume if clear
 cleo session resume <session_id>
 
 # 5. Continue from next_tasks
-cleo orchestrate next --epic <epic_id>
+cleo orchestrate next <epic_id>
 ```
 
 ## Exit Codes

package/skills/ct-orchestrator/references/orchestrator-compliance.md

@@ -37,7 +37,7 @@ research_id="${topic_slug}-${date}"  # e.g., "auth-research-2026-01-21"
 # 2. Verify manifest entry exists
 cleo research show "$research_id"
 # OR
-jq -s '.[] | select(.id == "'$research_id'")' "{{MANIFEST_PATH}}"
+cleo manifest show "$research_id"
 
 # 3. Block on missing manifest - DO NOT spawn next agent until confirmed
 if ! cleo research show "$research_id" &>/dev/null; then
@@ -91,7 +91,7 @@ fi
 
 | Violation | Detection | Recovery |
 |-----------|-----------|----------|
-| Missing protocol block | `grep -q "SUBAGENT PROTOCOL"` fails | Re-inject via `cleo research inject` |
+| Missing protocol block | `grep -q "SUBAGENT PROTOCOL"` fails | Regenerate the prompt with `cleo orchestrate spawn <taskId>` (it embeds the protocol) |
 | Invalid return message | Not in allowed format list | Mark as violation, re-spawn |
 | No manifest entry | `cleo research show` returns error | Re-spawn with explicit manifest requirement |
 | No research link | `jq '.task.linkedResearch'` empty | Orchestrator links via `cleo research link` |
@@ -240,7 +240,7 @@ if (( $(echo "$compliance_pass_rate < $COMPLIANCE_THRESHOLD" | bc -l) )); then
     stricter_prompt="$original_prompt
 
 ## COMPLIANCE CHECKLIST (VERIFY BEFORE RETURNING)
-- [ ] Output file exists at {{OUTPUT_DIR}}/{{DATE}}_{{TOPIC_SLUG}}.md
+- [ ] Output recorded with `cleo docs add` (`cleo docs fetch <slug>` returns it)
 - [ ] pipeline_manifest entry appended via `cleo manifest append`
 - [ ] Return message is EXACTLY: 'Research complete. Manifest appended to pipeline_manifest.'
 - [ ] Task linked via: {{TASK_LINK_CMD}} {{TASK_ID}} <research-id>

package/skills/ct-orchestrator/references/orchestrator-patterns.md

@@ -21,14 +21,14 @@ cleo orchestrate spawn T1575  # Auto-detects epic → uses decomposition protoco
 cleo research show <research-id>
 
 # 5. Continue with wave-0 tasks
-cleo orchestrate next --epic T1575
+cleo orchestrate next T1575
 ```
 
 ## Pattern: Resuming Interrupted Work
 
 ```bash
 # 1. Check state on conversation start
-cleo orchestrate start --epic T1575
+cleo orchestrate start T1575
 # Shows: session active, current T1586, next task T1589
 
 # 2. Check for incomplete subagent work
@@ -36,7 +36,7 @@ cleo research pending
 # Shows: needs_followup: ["T1586"]
 
 # 3. Resume focused task or spawn followup
-cleo show T1586 --brief
+cleo show T1586
 cleo orchestrate spawn T1586  # Re-spawn if needed
 ```
 
@@ -52,7 +52,7 @@ cleo add "Add error handling to auth" --parent T1586 --depends T1586
 cleo add "Write auth tests" --parent T1586 --depends T1586
 
 # 3. Spawn for new tasks
-cleo orchestrate next --epic T1575
+cleo orchestrate next T1575
 cleo orchestrate spawn T1590
 ```
 
@@ -64,7 +64,7 @@ cleo orchestrate analyze T1575
 # Shows: Wave 0: T1578, T1580, T1582 (no deps)
 
 # 2. Verify parallel safety
-cleo orchestrate ready --epic T1575
+cleo orchestrate ready T1575
 # Returns: ["T1578", "T1580", "T1582"]
 
 # 3. Spawn multiple subagents (different sessions)
@@ -84,13 +84,13 @@ cleo phase show
 # Returns: "core"
 
 # 2. Get tasks in current phase
-cleo orchestrate ready --epic T1575 --phase core
+cleo orchestrate ready T1575
 
 # 3. Spawn within phase context
 cleo orchestrate spawn T1586
 
 # 4. When phase complete, advance
-cleo phases stats
+cleo phase list
 cleo phase advance  # Move to testing phase
 ```
 
@@ -125,18 +125,19 @@ cleo list --parent T1575 --status pending  # Should be empty
 
 # 2. Run pre-release validation
 ./tests/run-all-tests.sh
-cleo validate
-
-# 3. Create and ship release
-cleo release create v0.85.0 --tasks T001,T002,T003
-cleo release ship v0.85.0 --bump-version --create-tag --push
-
-# Preview without changes:
-cleo release ship v0.85.0 --bump-version --dry-run
+cleo check arch
+
+# 3. Plan and open the release PR (ADR-065; merged through PRs, tagged explicitly)
+cleo release plan v0.85.0 --tasks T001,T002,T003
+cleo release open v0.85.0
+cleo release pr-status v0.85.0
+git tag -a v0.85.0 -m "Release v0.85.0" && git push origin v0.85.0
+cleo release reconcile v0.85.0
 ```
 
-**IMPORTANT**: `dev/release-version.sh` is **DEPRECATED** (since v0.78.0).
-Always use `cleo release create` → `cleo release ship`.
+**IMPORTANT**: `dev/release-version.sh` is **DEPRECATED** (since v0.78.0), and the
+`release create`/`release ship` verbs were removed (T9540, T10103). Always use
+`cleo release plan` → `open` → tag → `reconcile`.
 
 See `src/protocols/release.md` for the full release protocol specification.
 
@@ -158,7 +159,7 @@ cleo orchestrate spawn T105  # implementation protocol
 # contribution protocol auto-triggers for shared resources
 
 # RELEASE (polish phase)
-cleo release create v0.74.0 --tasks T104,T105
-cleo release ship v0.74.0 --bump-version --create-tag --push
+cleo release plan v0.74.0 --tasks T104,T105
+cleo release open v0.74.0
 cleo session end --note "Feature X released v0.74.0"
 ```