@cleocode/skills 2026.4.5 → 2026.4.7

package/skills/ct-release-orchestrator/references/composition.md

@@ -0,0 +1,138 @@
+# Release Protocol Composition
+
+The release parent protocol composes with two sub-protocols: `artifact-publish` and `provenance`. This file explains the composition contract, the exit-code flow, and the rollback semantics when a sub-protocol fails mid-pipeline.
+
+## Exit Code Flow
+
+The composed pipeline has a single downstream exit-code convention: the parent bubbles whatever the sub-protocol returned, so the orchestrator can distinguish which layer failed.
+
+```
+release → artifact-publish → provenance
+   54           86                90-94
+   55           87
+   56           88
+               (89)
+```
+
+| Code | Source | Meaning |
+|------|--------|---------|
+| 54 | release | `E_VALIDATION_FAILED` — parent-level gate failed (tests, schema, version) |
+| 55 | release | `E_VERSION_BUMP_FAILED` — bump script failed |
+| 56 | release | `E_TAG_CREATION_FAILED` — git tag/commit failed |
+| 65 | any | `HANDOFF_REQUIRED` — yielding control to next layer (not a failure) |
+| 85 | artifact-publish | `E_ARTIFACT_TYPE_UNKNOWN` — handler missing |
+| 86 | artifact-publish | `E_ARTIFACT_VALIDATION_FAILED` — pre-build validation |
+| 87 | artifact-publish | `E_ARTIFACT_BUILD_FAILED` — build command failed |
+| 88 | artifact-publish | `E_ARTIFACT_PUBLISH_FAILED` — publish failed (rollback attempted) |
+| 89 | artifact-publish | `E_ARTIFACT_ROLLBACK_FAILED` — rollback failed, dirty state |
+| 90 | provenance | `E_PROVENANCE_CONFIG_INVALID` |
+| 91 | provenance | `E_SIGNING_KEY_MISSING` |
+| 92 | provenance | `E_SIGNATURE_INVALID` |
+| 93 | provenance | `E_DIGEST_MISMATCH` |
+| 94 | provenance | `E_ATTESTATION_INVALID` |
+
+The parent MUST NOT remap sub-protocol exit codes. A caller reading `cleo release ship` output needs to know exactly which step failed.
+
+## Rollback Semantics
+
+### Single-artifact publish
+
+On a single-artifact release that fails at publish, the parent has a clean answer: the artifact was never on the registry, so there's nothing to roll back. The parent reports exit 88 and stops. The git tag may or may not have been created; the parent MUST NOT delete it. Tag deletion is a manual operation.
+
+### Multi-artifact publish
+
+On a multi-artifact release (e.g., npm + docker + tarball), the parent relies on the artifact-publish sub-protocol's per-registry rollback semantics. The sub-protocol keeps an `published_artifacts[]` list as it goes. On a failure at artifact[i], it attempts to roll back `artifacts[0..i-1]` using per-registry methods:
+
+| Registry | Rollback |
+|----------|----------|
+| npm | `npm unpublish <pkg>@<version>` (within 72 hours only) |
+| docker | registry API delete |
+| cargo | `cargo yank` (soft, not a real unpublish) |
+| github-release | `gh release delete` |
+| generic-tarball | delete uploaded file (depends on target) |
+
+If rollback succeeds across every already-published artifact, the pipeline exits 88 (clean failure). If any rollback fails, it exits 89 (dirty failure) and a human MUST intervene.
+
+### Git tag and commit
+
+The parent creates the release commit and tag **before** handing off to artifact-publish. This is deliberate: the commit carries the final state that the artifacts represent, and the tag is needed by CI jobs that watch for `v*.*.*` pushes. If artifact-publish fails, the tag remains; a re-run points at the same commit.
+
+The parent MUST NOT auto-delete the tag on failure. If a human operator wants to retract the release, they use `git tag -d` and `git push --delete` manually after inspecting the dirty state.
+
+## Handoff Data
+
+Each handoff passes a minimal set of data to the next layer:
+
+### Release → artifact-publish
+
+```json
+{
+  "version": "v2026.4.5",
+  "taskId": "T4900",
+  "epicId": "T260",
+  "commitSha": "3a2f1e9c...",
+  "tagName": "v2026.4.5",
+  "changelogPath": "CHANGELOG.md",
+  "artifactsConfig": [ /* release.artifacts[] from config.json */ ]
+}
+```
+
+### artifact-publish → provenance
+
+```json
+{
+  "version": "v2026.4.5",
+  "commitSha": "3a2f1e9c...",
+  "builtArtifacts": [
+    { "type": "npm-package", "path": "dist/cleo-2026.4.5.tgz", "sha256": "<hex>" },
+    { "type": "docker-image", "digest": "sha256:<hex>" }
+  ]
+}
+```
+
+### provenance → artifact-publish (return)
+
+```json
+{
+  "attestationPath": ".cleo/attestations/v2026.4.5.intoto.jsonl",
+  "signed": true,
+  "slsaLevel": "SLSA_BUILD_LEVEL_3",
+  "transparencyLog": {
+    "index": "123456789",
+    "url": "https://rekor.sigstore.dev"
+  }
+}
+```
+
+### artifact-publish → release (return)
+
+```json
+{
+  "published": [
+    { "type": "npm-package", "registry": "npmjs.org", "publishedAt": "2026-04-06T19:50:00Z" },
+    { "type": "docker-image", "registry": "ghcr.io", "publishedAt": "2026-04-06T19:51:12Z" }
+  ],
+  "attestationPath": ".cleo/attestations/v2026.4.5.intoto.jsonl"
+}
+```
+
+## CI Handoff
+
+In CI, the composition collapses: `.github/workflows/release.yml` runs all three sub-protocols in a single job sequence. The parent skill's job is to:
+
+1. Assemble the handoff data structures above from the task + config.
+2. Invoke the artifact-publish sub-protocol (or, in CI, let the workflow do it).
+3. Record the returned provenance chain in `.cleo/releases.json` via `record_release()`.
+4. Complete the task.
+
+When CI is driving the workflow, the skill's role is record-keeping, not execution. The skill MUST NOT double-publish.
+
+## Source-Only Releases
+
+A source-only release (`release.artifacts == []`) skips both sub-protocols entirely. The pipeline ends after step 4 (git commit + tag). The parent still writes the manifest entry and sets `agent_type: "documentation"`; it just records a shorter chain.
+
+Source-only releases are common for:
+
+- Documentation-only releases
+- Spec or protocol updates
+- Code changes that don't produce a publishable artifact (e.g., internal refactors before the next package bump)

package/skills/ct-release-orchestrator/references/release-types.md

@@ -0,0 +1,130 @@
+# Release Type Checklists
+
+The release parent protocol handles several release types. Each type has a distinct checklist. Pick the checklist that matches the release config before running ship.
+
+## Source-Only Release
+
+No package is produced. Used for docs, spec updates, and internal code changes that precede a later packaged release.
+
+### Checklist
+
+- [ ] Version is a valid semver.
+- [ ] Changelog has entries for every task in the release.
+- [ ] `release.artifacts` is `[]` or all entries are `enabled: false`.
+- [ ] Tests pass (opt-in via `--run-tests` for major/minor).
+- [ ] Tag created and pushed.
+- [ ] Manifest entry recorded with `agent_type: "documentation"`.
+
+### Commands
+
+```bash
+cleo release ship v2026.4.5 --bump-version --create-tag --push --no-artifacts
+cleo check protocol --protocolType release --version v2026.4.5 --hasChangelog true
+```
+
+## npm-Package Release
+
+Publishes one or more npm packages from the monorepo. Uses `npm publish --provenance` for SLSA L3 keyless attestation via the repository's OIDC trust.
+
+### Checklist
+
+- [ ] `package.json#version` matches the release version in every publishable workspace.
+- [ ] `release.artifacts[]` has an `npm-package` entry with `options.access: "public"` (for scoped public packages) or `options.access: "restricted"`.
+- [ ] `options.provenance: true` is set on the npm-package entry.
+- [ ] Trusted publishing is configured in npm registry settings.
+- [ ] The CI workflow `.github/workflows/release.yml` will run the publish step with OIDC identity.
+- [ ] Post-publish: the attestation reference is recorded in `.cleo/releases.json` via `record_release()`.
+
+### Commands
+
+```bash
+cleo release ship v2026.4.5 --bump-version --create-tag --push
+# CI handles the publish + attestation; the skill records the result.
+cleo check protocol --protocolType release --version v2026.4.5 --hasChangelog true
+cleo check protocol --protocolType artifact-publish --artifactType npm-package --buildPassed true
+cleo check protocol --protocolType provenance --hasAttestation true --hasSbom true
+```
+
+## docker-image Release
+
+Builds and pushes a container image to GHCR or another OCI registry, signs with cosign keyless, and generates a CycloneDX SBOM.
+
+### Checklist
+
+- [ ] `Dockerfile` at the image root is clean and reproducible.
+- [ ] `release.artifacts[]` has a `docker-image` entry with the target registry.
+- [ ] `release.security.provenance.framework: "slsa"` and `level: "SLSA_BUILD_LEVEL_3"`.
+- [ ] Cosign keyless signing is wired through the CI OIDC identity.
+- [ ] SBOM generator (syft or equivalent) is available in the CI image.
+- [ ] Post-publish: the image digest, signature, and SBOM reference are recorded.
+
+### Commands
+
+```bash
+cleo release ship v2026.4.5 --bump-version --create-tag --push
+# CI runs: docker build → cosign sign → cosign attest → syft sbom → push
+cleo check protocol --protocolType artifact-publish --artifactType docker-image --buildPassed true
+cleo check protocol --protocolType provenance --hasAttestation true --hasSbom true
+```
+
+## cargo-crate Release
+
+Publishes one or more crates from the Rust workspace to crates.io.
+
+### Checklist
+
+- [ ] `Cargo.toml#version` matches the release version for every publishable crate.
+- [ ] `cargo publish --dry-run` succeeds locally and in CI.
+- [ ] Inter-crate version bumps are consistent across the workspace.
+- [ ] `CARGO_REGISTRY_TOKEN` is available in CI (not in config.json).
+- [ ] Dependent crates publish after their dependencies (dependency order matters).
+
+### Commands
+
+```bash
+cleo release ship v2026.4.5 --bump-version --create-tag --push
+# CI runs: cargo test → cargo publish --dry-run → cargo publish
+cleo check protocol --protocolType artifact-publish --artifactType cargo-crate --buildPassed true
+```
+
+## github-tarball Release
+
+Creates a source tarball and attaches it to a GitHub Release. Optional cosign signing.
+
+### Checklist
+
+- [ ] Tarball exclude list is correct (no `.git/`, no secrets, no generated files).
+- [ ] Checksum file (`checksums.txt`) is generated alongside the tarball.
+- [ ] GitHub Release body includes the changelog section and the checksums.
+- [ ] If signing is enabled, cosign keyless produces a `.sig` file alongside the tarball.
+
+### Commands
+
+```bash
+cleo release ship v2026.4.5 --bump-version --create-tag --push
+# gh release create runs in CI with the tarball attached
+cleo check protocol --protocolType artifact-publish --artifactType github-release --buildPassed true
+```
+
+## Multi-Artifact Release
+
+A release with more than one artifact type — typical for a major version that ships npm + docker + GitHub Release together.
+
+### Checklist
+
+- [ ] Every artifact's checklist above is completed.
+- [ ] Artifacts are declared in a stable order in `release.artifacts[]` — the sub-protocol publishes sequentially in config order.
+- [ ] Rollback semantics per artifact are understood (see references/composition.md).
+- [ ] The provenance chain references every artifact digest in the same attestation.
+
+### Commands
+
+```bash
+cleo release ship v2026.4.5 --bump-version --create-tag --push
+# CI orchestrates all publishes; skill records the unified chain
+cleo check protocol --protocolType release --version v2026.4.5 --hasChangelog true
+```
+
+## Which Checklist Wins?
+
+If `release.artifacts[]` contains one entry, pick the checklist for that entry type. If it contains multiple entries, use the Multi-Artifact checklist and run each single-artifact checklist for the sub-types. If it is empty, use the Source-Only checklist.

package/skills/ct-skill-creator/manifest-entry.json

@@ -2,7 +2,7 @@
   "name": "ct-skill-creator",
   "version": "1.0.0",
   "description": "Guide for creating effective CLEO skills with the full v2 standard.",
-  "path": "packages/ct-skills/skills/ct-skill-creator",
+  "path": "packages/skills/skills/ct-skill-creator",
   "status": "active",
   "tier": 3,
   "core": false,

package/skills/ct-skill-creator/references/provider-deployment.md

@@ -1,13 +1,13 @@
 # Provider Deployment
 
-This reference covers multi-provider skill deployment: where each provider reads skills from, how symlinks enable a single source of truth, and how to add new skills to the CLEO ct-skills package.
+This reference covers multi-provider skill deployment: where each provider reads skills from, how symlinks enable a single source of truth, and how to add new skills to the @cleocode/skills package.
 
 ## Architecture
 
 Skills follow a single-source-of-truth model:
 
 ```
-packages/ct-skills/skills/         <-- canonical location
+packages/skills/skills/         <-- canonical location
   ct-cleo/SKILL.md
   ct-orchestrator/SKILL.md
   ct-skill-creator/SKILL.md
@@ -57,7 +57,7 @@ CLEO-aware providers read both SKILL.md and manifest.json. The manifest provides
 
 ### CLEO Package Skills
 
-Skills in `packages/ct-skills/skills/` are managed by CLEO infrastructure. They are deployed via the CLEO skill system and do not need manual symlink setup. The manifest.json, dispatch-config.json, and provider-skills-map.json coordinate deployment automatically.
+Skills in `packages/skills/skills/` are managed by CLEO infrastructure. They are deployed via the CLEO skill system and do not need manual symlink setup. The manifest.json, dispatch-config.json, and provider-skills-map.json coordinate deployment automatically.
 
 ### User Global Skills
 
@@ -110,13 +110,13 @@ cp -r my-skill/ .cursor/skills/my-skill/
 
 Project skills are committed to the repository and shared with all contributors.
 
-## Adding a New Skill to CLEO ct-skills
+## Adding a New Skill to @cleocode/skills
 
-To add a new skill to the CLEO package (`packages/ct-skills/`):
+To add a new skill to the CLEO package (`packages/skills/`):
 
 1. **Create the skill directory**:
    ```bash
-   mkdir -p packages/ct-skills/skills/my-new-skill
+   mkdir -p packages/skills/skills/my-new-skill
    ```
 
 2. **Write SKILL.md with standard fields only**:
@@ -132,7 +132,7 @@ To add a new skill to the CLEO package (`packages/ct-skills/`):
    ```
    Include only v2 standard fields. No `version`, `tier`, `category`, or other CLEO-only fields.
 
-3. **Add entry to manifest.json** (`packages/ct-skills/skills/manifest.json`):
+3. **Add entry to manifest.json** (`packages/skills/skills/manifest.json`):
    ```json
    {
      "name": "my-new-skill",
@@ -164,12 +164,12 @@ To add a new skill to the CLEO package (`packages/ct-skills/`):
    }
    ```
 
-4. **Add entry to dispatch-config.json** (`packages/ct-skills/dispatch-config.json`):
+4. **Add entry to dispatch-config.json** (`packages/skills/dispatch-config.json`):
    Add the skill to relevant `by_task_type`, `by_keyword`, and/or `by_protocol` mappings if it should participate in dispatch routing.
 
 5. **Update totalSkills** in manifest.json `_meta.totalSkills` to reflect the new count.
 
 6. **Validate**: Run the skill validator to confirm the new skill passes all checks:
    ```bash
-   python3 packages/ct-skills/skills/ct-skill-creator/scripts/quick_validate.py packages/ct-skills/skills/my-new-skill
+   python3 packages/skills/skills/ct-skill-creator/scripts/quick_validate.py packages/skills/skills/my-new-skill
    ```

package/skills/ct-skill-validator/evals/evals.json

@@ -15,7 +15,7 @@
     },
     {
       "id": 2,
-      "prompt": "Check if this skill folder is v2 compliant: packages/ct-skills/skills/ct-orchestrator",
+      "prompt": "Check if this skill folder is v2 compliant: packages/skills/skills/ct-orchestrator",
       "expected_output": "Validation results for ct-orchestrator with tier breakdown, and an HTML report",
       "expectations": [
         "Claude validates ct-orchestrator not some other skill",

package/skills/ct-skill-validator/manifest-entry.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "CLEO-only metadata -- add to packages/ct-skills/skills/manifest.json",
+  "_comment": "CLEO-only metadata -- add to packages/skills/skills/manifest.json",
   "name": "ct-skill-validator",
   "version": "1.0.0",
   "tier": 2,

package/skills/manifest.json

@@ -1,11 +1,11 @@
 {
   "$schema": "https://cleo-dev.com/schemas/v1/skills-manifest.schema.json",
   "_meta": {
-    "schemaVersion": "2.3.0",
-    "lastUpdated": "2026-03-02",
-    "totalSkills": 15,
-    "generatedFrom": "manual restructure — provider-neutral skills consolidation",
-    "architectureNote": "Universal Subagent Architecture: All spawns use provider-neutral delegation with skill/protocol injection."
+    "schemaVersion": "2.4.0",
+    "lastUpdated": "2026-04-07",
+    "totalSkills": 21,
+    "generatedFrom": "T260 — lifecycle pipeline rework: dedicated skills for ADR, IVT loop, consensus, release, artifact-publish, provenance",
+    "architectureNote": "Universal Subagent Architecture: All spawns use provider-neutral delegation with skill/protocol injection. Pipeline stages and cross-cutting protocols each have a dedicated skill — no overloading."
   },
   "dispatch_matrix": {
     "_comment": "Maps task types/keywords to skill NAMES. Provider adapter decides HOW to execute.",
@@ -13,35 +13,45 @@
       "research": "ct-research-agent",
       "planning": "ct-epic-architect",
       "implementation": "ct-task-executor",
-      "testing": "ct-dev-workflow",
+      "testing": "ct-ivt-looper",
       "documentation": "ct-documentor",
       "specification": "ct-spec-writer",
       "validation": "ct-validator",
-      "release": "ct-dev-workflow",
-      "consensus": "ct-validator",
-      "contribution": "ct-contribution"
+      "release": "ct-release-orchestrator",
+      "consensus": "ct-consensus-voter",
+      "contribution": "ct-contribution",
+      "architecture-decision": "ct-adr-recorder",
+      "artifact-publish": "ct-artifact-publisher",
+      "provenance": "ct-provenance-keeper"
     },
     "by_keyword": {
       "research|investigate|explore|discover": "ct-research-agent",
       "epic|plan|decompose|architect": "ct-epic-architect",
       "implement|build|execute|create": "ct-task-executor",
-      "test|coverage|integration|vitest": "ct-dev-workflow",
+      "ivt|test|coverage|integration|verify against spec": "ct-ivt-looper",
       "doc|document|readme|guide": "ct-documentor",
       "spec|rfc|protocol|contract": "ct-spec-writer",
-      "validate|verify|audit|compliance|consensus|vote": "ct-validator",
-      "release|version|publish|deploy|ship|changelog": "ct-dev-workflow"
+      "validate|verify|audit|compliance": "ct-validator",
+      "consensus|vote|verdict|resolve the debate": "ct-consensus-voter",
+      "adr|architecture decision|formalize|lock in the choice": "ct-adr-recorder",
+      "release|version|ship|changelog|cut release": "ct-release-orchestrator",
+      "artifact|publish|registry|npm publish|docker push": "ct-artifact-publisher",
+      "provenance|attestation|sbom|sigstore|slsa": "ct-provenance-keeper"
     },
     "by_protocol": {
       "research": "ct-research-agent",
-      "consensus": "ct-validator",
+      "consensus": "ct-consensus-voter",
+      "architecture-decision": "ct-adr-recorder",
       "specification": "ct-spec-writer",
       "decomposition": "ct-epic-architect",
       "implementation": "ct-task-executor",
       "contribution": "ct-contribution",
-      "release": "ct-dev-workflow",
-      "agent-protocol": "ct-orchestrator",
       "validation": "ct-validator",
-      "testing": "ct-dev-workflow"
+      "testing": "ct-ivt-looper",
+      "release": "ct-release-orchestrator",
+      "artifact-publish": "ct-artifact-publisher",
+      "provenance": "ct-provenance-keeper",
+      "agent-protocol": "ct-orchestrator"
     }
   },
   "skills": [
@@ -464,6 +474,232 @@
         "requires_session": false,
         "requires_epic": false
       }
+    },
+    {
+      "name": "ct-adr-recorder",
+      "version": "1.0.0",
+      "description": "Records Architecture Decision Records from accepted consensus verdicts. Drafts the document in the proposed-then-accepted HITL lifecycle, links to the originating consensus manifest, persists to the canonical SQLite decisions table, and triggers downstream invalidation when an accepted ADR is later superseded.",
+      "path": "skills/ct-adr-recorder",
+      "tags": ["adr", "architecture-decision", "hitl", "decision-record"],
+      "status": "active",
+      "tier": 2,
+      "token_budget": 8000,
+      "protocol": "architecture-decision",
+      "references": [
+        "skills/ct-adr-recorder/references/cascade.md",
+        "skills/ct-adr-recorder/references/examples.md"
+      ],
+      "capabilities": {
+        "inputs": ["consensus-manifest-id", "task-id", "decision-context"],
+        "outputs": ["adr-markdown", "decisions-table-row", "manifest-entry"],
+        "dependencies": [],
+        "dispatch_triggers": [
+          "write ADR",
+          "record architecture decision",
+          "formalize this decision",
+          "create ADR",
+          "lock in the choice"
+        ],
+        "compatible_subagent_types": ["general-purpose"],
+        "chains_to": ["ct-consensus-voter", "ct-spec-writer"],
+        "dispatch_keywords": {
+          "primary": ["adr", "decision", "architecture", "formalize"],
+          "secondary": ["proposed", "accepted", "superseded", "hitl"]
+        }
+      },
+      "constraints": {
+        "max_context_tokens": 60000,
+        "requires_session": false,
+        "requires_epic": false
+      }
+    },
+    {
+      "name": "ct-ivt-looper",
+      "version": "1.0.0",
+      "description": "Runs a project-agnostic autonomous Implement→Validate→Test compliance loop on any git worktree. Detects the project's test framework and iterates until the implementation satisfies its specification. Works in any git worktree regardless of language or framework — the autonomous compliance layer enforced before any release or PR.",
+      "path": "skills/ct-ivt-looper",
+      "tags": ["testing", "ivt-loop", "autonomous", "framework-agnostic", "compliance"],
+      "status": "active",
+      "tier": 2,
+      "token_budget": 10000,
+      "protocol": "testing",
+      "references": [
+        "skills/ct-ivt-looper/references/escalation.md",
+        "skills/ct-ivt-looper/references/frameworks.md",
+        "skills/ct-ivt-looper/references/loop-anatomy.md"
+      ],
+      "capabilities": {
+        "inputs": ["task-id", "spec-reference", "worktree-path"],
+        "outputs": ["manifest-entry", "ivt-convergence-report"],
+        "dependencies": [],
+        "dispatch_triggers": [
+          "run the IVT loop",
+          "implement and verify",
+          "ship this task",
+          "verify against spec",
+          "complete implementation with tests"
+        ],
+        "compatible_subagent_types": ["general-purpose"],
+        "chains_to": ["ct-validator", "ct-release-orchestrator"],
+        "dispatch_keywords": {
+          "primary": ["ivt", "implement", "validate", "test"],
+          "secondary": ["converge", "framework", "spec", "iterate"]
+        }
+      },
+      "constraints": {
+        "max_context_tokens": 80000,
+        "requires_session": false,
+        "requires_epic": false
+      }
+    },
+    {
+      "name": "ct-consensus-voter",
+      "version": "1.0.0",
+      "description": "Runs structured multi-agent voting for decision tasks with confidence scores, conflict detection, and HITL escalation when the threshold is not met. Produces a voting matrix JSON, enforces the 0.5 threshold, and flags ties within 0.1 confidence as contested for human tiebreak. Split from the overloaded ct-validator skill.",
+      "path": "skills/ct-consensus-voter",
+      "tags": ["consensus", "voting", "decision", "multi-agent", "hitl"],
+      "status": "active",
+      "tier": 2,
+      "token_budget": 6000,
+      "protocol": "consensus",
+      "references": ["skills/ct-consensus-voter/references/matrix-examples.md"],
+      "capabilities": {
+        "inputs": ["task-id", "question", "candidate-options"],
+        "outputs": ["voting-matrix", "manifest-entry"],
+        "dependencies": [],
+        "dispatch_triggers": [
+          "reach consensus",
+          "vote on options",
+          "resolve the debate",
+          "pick the best approach",
+          "run consensus"
+        ],
+        "compatible_subagent_types": ["general-purpose"],
+        "chains_to": ["ct-adr-recorder", "ct-research-agent"],
+        "dispatch_keywords": {
+          "primary": ["consensus", "vote", "decide", "verdict"],
+          "secondary": ["confidence", "rationale", "evidence", "contested"]
+        }
+      },
+      "constraints": {
+        "max_context_tokens": 60000,
+        "requires_session": false,
+        "requires_epic": false
+      }
+    },
+    {
+      "name": "ct-release-orchestrator",
+      "version": "1.0.0",
+      "description": "Orchestrates the full release pipeline: version bump → changelog → commit → tag, then conditionally forks to artifact-publish and provenance based on release config. Parent protocol that composes ct-artifact-publisher and ct-provenance-keeper as sub-protocols. Source-only releases skip both sub-protocols entirely.",
+      "path": "skills/ct-release-orchestrator",
+      "tags": ["release", "orchestration", "composition", "ship", "version"],
+      "status": "active",
+      "tier": 2,
+      "token_budget": 8000,
+      "protocol": "release",
+      "references": [
+        "skills/ct-release-orchestrator/references/composition.md",
+        "skills/ct-release-orchestrator/references/release-types.md"
+      ],
+      "capabilities": {
+        "inputs": ["version", "epic-id", "release-config"],
+        "outputs": ["release-commit", "git-tag", "changelog-entry", "manifest-entry"],
+        "dependencies": [],
+        "dispatch_triggers": [
+          "ship release",
+          "cut release",
+          "publish version",
+          "cleo release ship",
+          "promote epic to released"
+        ],
+        "compatible_subagent_types": ["general-purpose"],
+        "chains_to": ["ct-artifact-publisher", "ct-provenance-keeper"],
+        "dispatch_keywords": {
+          "primary": ["release", "ship", "version", "tag"],
+          "secondary": ["changelog", "semver", "bump", "publish"]
+        }
+      },
+      "constraints": {
+        "max_context_tokens": 60000,
+        "requires_session": false,
+        "requires_epic": true
+      }
+    },
+    {
+      "name": "ct-artifact-publisher",
+      "version": "1.0.0",
+      "description": "Builds and publishes artifacts to registries (npm, PyPI, cargo, docker, GitHub releases, generic tarballs) following the validate → dry-run → build → publish → record-provenance pipeline. Invoked by ct-release-orchestrator as a sub-skill when a release has artifact config. Never stores credentials in output or manifest.",
+      "path": "skills/ct-artifact-publisher",
+      "tags": ["artifact", "publish", "registry", "release", "distribution"],
+      "status": "active",
+      "tier": 2,
+      "token_budget": 8000,
+      "protocol": "artifact-publish",
+      "references": [
+        "skills/ct-artifact-publisher/references/artifact-types.md",
+        "skills/ct-artifact-publisher/references/handler-interface.md"
+      ],
+      "capabilities": {
+        "inputs": ["release-config", "version", "commit-sha"],
+        "outputs": ["built-artifacts", "checksums", "publish-results", "manifest-entry"],
+        "dependencies": [],
+        "dispatch_triggers": [
+          "publish artifacts",
+          "build and publish",
+          "run artifact publish",
+          "ship packages",
+          "push to registry"
+        ],
+        "compatible_subagent_types": ["general-purpose"],
+        "chains_to": ["ct-provenance-keeper"],
+        "dispatch_keywords": {
+          "primary": ["artifact", "publish", "registry", "package"],
+          "secondary": ["npm", "docker", "cargo", "tarball"]
+        }
+      },
+      "constraints": {
+        "max_context_tokens": 60000,
+        "requires_session": false,
+        "requires_epic": false
+      }
+    },
+    {
+      "name": "ct-provenance-keeper",
+      "version": "1.0.0",
+      "description": "Generates in-toto v1 attestations, SLSA-level provenance records, SBOMs (CycloneDX or SPDX), and sigstore/cosign signatures for published artifacts. Invoked by ct-artifact-publisher as a delegation for signing and attestation. Records the full commit→build→artifact→attestation→registry chain in .cleo/releases.json.",
+      "path": "skills/ct-provenance-keeper",
+      "tags": ["provenance", "slsa", "attestation", "sbom", "sigstore", "supply-chain"],
+      "status": "active",
+      "tier": 2,
+      "token_budget": 6000,
+      "protocol": "provenance",
+      "references": [
+        "skills/ct-provenance-keeper/references/signing.md",
+        "skills/ct-provenance-keeper/references/slsa.md"
+      ],
+      "capabilities": {
+        "inputs": ["built-artifacts", "commit-sha", "builder-identity"],
+        "outputs": ["in-toto-attestation", "sbom", "signature", "releases-json-entry"],
+        "dependencies": [],
+        "dispatch_triggers": [
+          "generate provenance",
+          "sign artifacts",
+          "create attestation",
+          "record supply chain",
+          "run slsa attestation"
+        ],
+        "compatible_subagent_types": ["general-purpose"],
+        "chains_to": [],
+        "dispatch_keywords": {
+          "primary": ["provenance", "attestation", "sbom", "slsa"],
+          "secondary": ["sigstore", "cosign", "in-toto", "sign"]
+        }
+      },
+      "constraints": {
+        "max_context_tokens": 60000,
+        "requires_session": false,
+        "requires_epic": false
+      }
     }
   ]
 }