@cleocode/skills 2026.10.21 → 2026.10.22

package/skills/manifest.json

@@ -226,7 +226,7 @@
     },
     {
       "name": "ct-cleo",
-      "version": "2.24.16",
+      "version": "2.24.21",
       "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,
@@ -238,7 +238,7 @@
       "dependencies": [],
       "references": [
         "skills/ct-cleo/references/session-protocol.md",
-        "skills/ct-cleo/references/loom-lifecycle.md",
+        "skills/ct-cleo/references/planning-loop.md",
         "skills/ct-cleo/references/anti-patterns.md"
       ],
       "protocol": null,
@@ -302,7 +302,7 @@
     },
     {
       "name": "ct-codebase-mapper",
-      "version": "2.2.1",
+      "version": "2.3.5",
       "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.25",
+      "version": "3.1.31",
       "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.25.4",
+      "version": "3.26.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,
@@ -965,8 +965,8 @@
     },
     {
       "name": "ct-lead",
-      "version": "1.0.8",
-      "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.",
+      "version": "1.1.3",
+      "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, read worker completion messages on AgentMBX 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.",
       "path": "skills/ct-lead",
       "tier": 0,
       "deliveryTier": "core",
@@ -983,7 +983,7 @@
     },
     {
       "name": "ct-lean",
-      "version": "1.4.0",
+      "version": "1.6.0",
       "description": "Lean change discipline for CLEO work: the smallest change that fully solves the task, and a reply a busy owner understands in one read. Use on every coding task (writing, fixing, refactoring, reviewing, choosing dependencies) and when the owner asks for the simplest solution, YAGNI, or complains about over-engineering or bloat; also for a lean code review (\"review this\", \"review my PR\") or a whole-repo audit (\"audit the repo\", \"what can I delete\"). Never trades away evidence gates, package boundaries, validation, data safety or anything the task asked for.",
       "path": "skills/ct-lean",
       "tier": 0,
@@ -1001,7 +1001,7 @@
     },
     {
       "name": "ct-orchestrator",
-      "version": "4.0.15",
+      "version": "4.1.2",
       "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,
@@ -1013,7 +1013,6 @@
       "dependencies": [],
       "references": [
         "skills/ct-orchestrator/references/autonomous-operation.md",
-        "skills/ct-orchestrator/references/lifecycle-gates.md",
         "skills/ct-orchestrator/references/orchestrator-compliance.md",
         "skills/ct-orchestrator/references/orchestrator-handoffs.md",
         "skills/ct-orchestrator/references/orchestrator-patterns.md",
@@ -1490,7 +1489,7 @@
     },
     {
       "name": "ct-task-executor",
-      "version": "2.8.5",
+      "version": "2.8.6",
       "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,

package/skills/ct-cleo/references/loom-lifecycle.md

@@ -1,136 +0,0 @@
-# LOOM Lifecycle (Detailed)
-
-**LOOM** (Logical Order of Operations Methodology) is the systematic framework for how CLEO processes project threads through the RCASD-IVTR+C pipeline. This document details the lifecycle stages and gate enforcement.
-
-See `docs/concepts/CLEO-VISION.md` for the complete LOOM framework, neural hierarchy model, and brain metaphor mapping.
-
-## Pipeline Stages
-
-```
-LOOM (RCASD-IVTR+C) PIPELINE:
-
-RCASD (Planning Phase):
-  Research -> Consensus -> Architecture Decision -> Specification -> Decomposition
-                                                              |
-                                                              v
-IVTR (Execution Phase):
-  Implementation -> Validation -> Testing -> Release
-
-+C (Cross-Cutting):
-  Contribution (applies across all stages)
-```
-
-Each stage has a **lifecycle gate**. Entering a later stage requires prior stages to be `completed` or `skipped`. Gate enforcement mode is configured in `.cleo/config.json` (`strict` | `advisory` | `off`).
-
-## Conditional Protocols (9 Types)
-
-| Protocol | Keywords | Use Case |
-|----------|----------|----------|
-| Research | research, investigate, explore | Information gathering |
-| Consensus | vote, validate, decide | Multi-agent decisions |
-| Specification | spec, rfc, design | Document creation |
-| Decomposition | epic, plan, decompose | Task breakdown |
-| Implementation | implement, build, create | Code execution |
-| Contribution | PR, merge, shared | Work attribution |
-| Release | release, version, publish | Version management |
-| Artifact Publish | publish, artifact, package | Artifact distribution |
-| Provenance | provenance, attestation, SLSA | Supply chain integrity |
-
-## Lifecycle Gate Enforcement
-
-CLEO enforces LOOM (RCASD-IVTR+C) lifecycle progression through automatic gate checks at spawn time.
-
-```
-research --+---> consensus --+---> architecture_decision --+---> specification --+---> decomposition
-           |                 |                              |                    |
-           | GATE            | GATE                         | GATE               | GATE
-           |                 |                              |                    |
-           +-----------------+------------------------------+--------------------+---> implementation --+---> release
-                                                                                                         |
-                                                                                                    validation/testing
-```
-
-| Enforcement Mode | On Gate Failure | Default |
-|------------------|-----------------|---------|
-| `strict` | Blocks spawn with exit 75 | yes |
-| `advisory` | Warns but proceeds | |
-| `off` | Skips all checks | |
-
-### Emergency Bypass
-
-```bash
-cleo config set lifecycleEnforcement.mode off
-# ... emergency work ...
-cleo config set lifecycleEnforcement.mode strict
-```
-
-## Architecture Overview
-
-CLEO implements a **2-tier universal subagent architecture**:
-
-```
-Tier 0: ORCHESTRATOR (ct-orchestrator)
-    |
-    +-- Coordinates complex workflows
-    +-- Spawns subagents via Task tool
-    +-- Pre-resolves ALL tokens before spawn
-    +-- Reads only manifest summaries (not full content)
-    |
-    v
-Tier 1: CLEO-SUBAGENT (universal executor)
-    |
-    +-- Receives fully-resolved prompts
-    +-- Loads skill via protocol injection
-    +-- Executes delegated work
-    +-- Outputs: file + manifest entry + summary
-```
-
-**Core Principle**: One universal subagent type (`cleo-subagent`) with context-specific protocols -- NOT skill-specific agents.
-
-## Protocol Stack
-
-Every spawn combines two layers:
-
-```
-+------------------------------------------+
-| CONDITIONAL PROTOCOL (task-specific)     |
-| - research.md, implementation.md, etc.   |
-+------------------------------------------+
-| BASE PROTOCOL (always loaded)            |
-| - Lifecycle, output format, constraints  |
-+------------------------------------------+
-```
-
-## Subagent (cleo-subagent)
-
-### Constraints (BASE)
-
-| ID | Rule | Enforcement |
-|----|------|-------------|
-| BASE-001 | MUST append ONE entry via `cleo manifest append --entry '<json>'` (writes to pipeline_manifest table per ADR-027/T1093) | Required |
-| BASE-002 | MUST NOT return content in response | Required |
-| BASE-003 | MUST complete task via `cleo complete` | Required |
-| BASE-004 | MUST write output file before manifest | Required |
-| BASE-005 | MUST start a task before beginning work | Required |
-| BASE-006 | MUST NOT fabricate information | Required |
-| BASE-007 | SHOULD link research to task | Recommended |
-
-### Subagent Lifecycle
-
-```
-SPAWN -> INJECT -> EXECUTE -> OUTPUT -> RETURN
-```
-
-1. **SPAWN**: Orchestrator invokes Task tool
-2. **INJECT**: Subagent receives base protocol + conditional protocol
-3. **EXECUTE**: Follow skill-specific instructions
-4. **OUTPUT**: Write file + append manifest entry
-5. **RETURN**: Completion signal only (no content)
-
-### Return Messages
-
-| Status | Message |
-|--------|---------|
-| Complete | `[Type] complete. Manifest appended to pipeline_manifest.` |
-| Partial | `[Type] partial. Manifest appended to pipeline_manifest.` |
-| Blocked | `[Type] blocked. Manifest appended to pipeline_manifest.` |

package/skills/ct-orchestrator/references/lifecycle-gates.md

@@ -1,98 +0,0 @@
-# Lifecycle Gate Enforcement
-
-> Referenced from: @skills/ct-orchestrator/SKILL.md
-> Load when: Need details on RCASD-IVTR+C gate checks, enforcement modes, handling gate failures, or emergency bypass
-
-## Overview
-
-Before spawning ANY implementation task, the system automatically checks RCASD-IVTR+C prerequisites. This ensures the Research → Consensus → Specification → Decomposition pipeline is followed.
-
-## Decision Tree
-
-```
-Before spawn:
-│
-├─ Is task under an epic (has parentId)?
-│   ├─ NO → Skip gate check, proceed
-│   └─ YES → Continue to gate check
-│
-├─ What is enforcement mode?
-│   ├─ off → Skip gate check, proceed
-│   ├─ advisory → Check gates, warn on failure, proceed
-│   └─ strict (default) → Check gates, BLOCK on failure
-│
-├─ Map protocol to RCASD-IVTR+C stage:
-│   ├─ research → research stage
-│   ├─ consensus → consensus stage
-│   ├─ specification → specification stage
-│   ├─ decomposition → decomposition stage
-│   ├─ implementation/contribution → implementation stage
-│   └─ release → release stage
-│
-├─ Check prerequisites for target stage:
-│   ├─ All prior stages completed/skipped → GATE PASSES → Proceed with spawn
-│   └─ Missing prerequisite stages → GATE FAILS
-│
-└─ On GATE FAILURE (strict mode):
-    ├─ Exit code: 75 (EXIT_LIFECYCLE_GATE_FAILED)
-    ├─ Error includes: missing stages, fix commands
-    └─ Action: Complete prerequisite stages first
-```
-
-## Enforcement Modes
-
-| Mode | Behavior | When to Use |
-|------|----------|-------------|
-| **strict** (default) | Blocks spawn if prerequisites missing | Production, regulated work |
-| **advisory** | Warns but allows spawn | Rapid prototyping, debugging |
-| **off** | Disables all gate checks | Legacy compatibility, emergencies |
-
-## Setting Enforcement Mode
-
-```bash
-# Check current mode
-jq '.lifecycleEnforcement.mode' .cleo/config.json
-
-# Set to advisory (temporary)
-jq '.lifecycleEnforcement.mode = "advisory"' .cleo/config.json > tmp && mv tmp .cleo/config.json
-
-# Set back to strict
-jq '.lifecycleEnforcement.mode = "strict"' .cleo/config.json > tmp && mv tmp .cleo/config.json
-```
-
-## Handling Gate Failures
-
-When a gate fails in strict mode:
-
-1. **Check what's missing**: Error JSON shows `missingPrerequisites`
-2. **Complete prerequisites**: Spawn subagents for missing stages
-3. **Record completion**: System auto-records via manifest entries
-4. **Retry spawn**: Original task should now pass gate
-
-**Example failure response:**
-```json
-{
-  "error": {
-    "code": "E_LIFECYCLE_GATE_FAILED",
-    "message": "SPAWN BLOCKED: Lifecycle prerequisites not met for implementation stage",
-    "context": {
-      "targetStage": "implementation",
-      "missingPrerequisites": "research consensus"
-    }
-  }
-}
-```
-
-## Emergency Bypass
-
-**Only for emergencies** — set mode to advisory or off:
-
-```bash
-# Temporary bypass for single session
-export LIFECYCLE_ENFORCEMENT_MODE=off
-
-# Or update config
-jq '.lifecycleEnforcement.mode = "off"' .cleo/config.json > tmp && mv tmp .cleo/config.json
-```
-
-**Remember to restore strict mode after emergency.**