Menú
Check the portable stack-control release contract and use the shared release surface instead of host-owned release semantics.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Provision the fleet control plane's accepted bearer token, or serve the plane HTTP endpoint (stackctl plane provision-token | serve) — the fleet control plane a single operator's sidecars uplink to (specs/036-fleet-control-plane). Wraps `stackctl plane`.
Elect and run the per-installation sidecar daemon that uplinks telemetry to the fleet control plane and receives commands over SSE (stackctl sidecar run) — specs/036-fleet-control-plane. Wraps `stackctl sidecar`.
Run a Spec Kit spec by dispatching each task to a fresh, right-sized subagent at the model its declared [tier:] resolves to (model-sized dispatch), with deskwork governance firing automatically afterward (cross-model audit-barrage + finding lift)
Author a NEW Spec Kit spec for a new feature, in-session — drive native /speckit-specify and the downstream authoring chain via the in-session agent, confirming state with stackctl spec-check (spec-authoring only; does not create worktree/docs infra)
Open the designing phase for a roadmap item — an opinionated frontend that drives a swappable design backend (default superpowers:brainstorming) IN-SESSION, sets the design: pointer on entry, re-injects capture-over-YAGNI, routes the handoff to /stack-control:define, and writes the installation-anchored design record the design-to-spec gate checks
Close a shipped roadmap item and everything it contains — the operator-confirmed post-ship terminal move. Shows the full transitive cascade (the item's part-of subtree's recorded closes: ids) as a dry-run, prompts you to confirm (and, when self-hosting, to validate the installed release), then runs `roadmap advance --to closed` which closes the deduped backlog ids and advances the item to the terminal `closed` phase. Never closes automatically.
| name | release |
| description | Check the portable stack-control release contract and use the shared release surface instead of host-owned release semantics. |
Use the stack-control release surface as the portable contract for deskwork releases. The workflow remains one monorepo release with one version line; host surfaces are adapters, not separate release streams.
Before doing ANY of this skill's work, consult the compass for the roadmap item being released, declaring this skill as the intent:
stackctl workflow compass <item> --intent release
A non-zero exit is a hard refusal: print the compass's reason and STOP — perform none of this skill's work. release maps to the back-half shipped target, so an item that has not reached governing returns ahead (naming the skipped step) — you cannot release un-governed work. Proceed only on exit 0. Per .claude/rules/enforcement-lives-in-skills.md the gate lives in this skill body + the stackctl workflow compass verb, never a git hook.
Start with the shared-core check:
stackctl release-check
The portable helper subcommands also live behind stackctl now:
stackctl release-helper check-preconditions
stackctl release-helper validate-version <version> <last-tag>
stackctl release-helper assert-not-published <version>
stackctl release-helper assert-published <version>
stackctl release-helper atomic-push <tag> <branch>
This is the authoritative preflight for portability:
The historical operator procedure still lives in
/.claude/skills/release/, but its helper
implementation is now a compatibility wrapper over the stack-control-owned
release helper module. Treat the Claude-owned path as a host adapter, not the
portable source of truth.
Claude Code and Codex may present release steps differently, but they must both consume the same shared release contract and must not invent host-only version lines or publish flows.