Loops · dev-team

`release`

Take merged code to live users through a planned, reversible rollout — plan the phases and the rollback, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call.

Use it when: Use when the user has merged a change and asks how to roll it out, whether they are ready to launch, or for a go/no-go decision.
Comes with: The dev-team pack
Where you decide: Ready (G3): a review panel decides
Go (G3.1): you decide
Size: 4 stages · 2 gates · up to 3 revision rounds

npx skilldrop-cli install --loop release

Installs the loop as an invokable skill, plus every skill its stages run.

Other ways to install

Every loop in its pack, with their skills:

npx skilldrop-cli install --loop --pack dev-team

The loop alone, without its stage skills (each stage falls back to an inline version):

npx skilldrop-cli install --loop release --no-skills

In Claude Code, the dev-team plugin includes it:

/plugin install dev-team@skilldrop

The loop

%%{init: {'theme':'base','themeVariables':{'fontFamily':'Segoe UI, Helvetica, Arial','fontSize':'15px','lineColor':'#9AA5B1'},'flowchart':{'curve':'basis','rankSpacing':70,'nodeSpacing':50,'padding':16}}}%%
flowchart LR
    classDef gen    fill:#E8F0FE,stroke:#4C7DF0,stroke-width:1.5px,color:#1A3A8F;
    classDef review fill:#FDEAEA,stroke:#E05B5B,stroke-width:1.5px,color:#8A1F1F;
    classDef gate   fill:#FBE3A2,stroke:#D9971E,stroke-width:2px,color:#6B4500,font-weight:bold;
    classDef ship   fill:#E6F7EC,stroke:#34A853,stroke-width:2px,color:#0F6B33,font-weight:bold;

    plan["plan<br/><small>migration-plan·rollout-plan</small>"]:::gen
    ready["ready<br/><small>launch-readiness</small>"]:::review
    announce["announce<br/><small>release-notes</small>"]:::gen
    go["go<br/><small>council-review</small>"]:::gate
    G3{"G3 · review"}:::gate
    G3_1{"G3.1 · human"}:::gate
    DONE(["complete"]):::ship

    plan --> ready
    ready --> G3
    G3 == "PROCEED" ==> announce
    announce --> go
    go --> G3_1
    G3_1 == "PROCEED" ==> DONE

    G3 -- "REVISE (max 3)" --> plan
    G3_1 -- "REVISE (max 3)" --> plan

Stages

#	Stage	What it does	Skills	Gate
1	plan generate	Decide the rollout phases, the rollback for each, and the one point of no return, before anything reaches users.	`migration-plan`, `rollout-plan`	—
2	ready verify	Judge on evidence whether the change can go live: rollback, detection, response, measured targets, data, comms, exposure.	`launch-readiness`	G3 — a review panel decides PROCEED · PROCEED WITH CONDITIONS · REVISE · BLOCKED
3	announce generate	Write what users and the team are told. Only after readiness, so nobody announces a launch that then fails the check.	`release-notes`	—
4	go gate	A human decides whether it should ship now. Readiness says it can; this decides timing, freeze windows, and who is on call.	`council-review`	G3.1 — you decide PROCEED · PROCEED WITH CONDITIONS · REVISE · RECONSIDER · BLOCKED

This loop covers the step between build, which ends when a human merges, and operate, which assumes the service is already live. A merge can be undone with a revert. A launch that has touched users or data often cannot be undone, so this loop gets its own gates instead of being folded into either neighbour.

How to run this loop

Plan the rollout and the way back. A change to data, a schema or a platform → migration-plan: the phases, a tested rollback for each, and at most one named point of no return. A code change released behind a flag or a canary → rollout-plan: the exposure steps, the metric and threshold that decide each one, how long each must run to detect a regression, and what turning the flag off doesn't undo. A change that does both gets both. The plan can be short, but it has to exist.
Judge readiness at G3. launch-readiness lists the change's own failure modes, then checks rollback, detection, response, measured targets, data and privacy, comms and exposure, each with evidence. REVISE returns to plan, and the report names which gap to close and which skill closes it. A missing rollback is BLOCKED on its own.
Announce only once it is ready. release-notes drafts the notes for each audience you name from the git range, with nothing the log doesn't say. Writing them before G3 risks announcing a launch that then does not happen.
A human decides at G3.1. The release owner decides whether to ship now, given timing, freeze windows and on-call coverage. When that decision is contested, use council-review. RECONSIDER means it is ready but this is the wrong time, and the work waits instead of going back to plan.

After PROCEED, the change is live and the work moves to operate. Gaps that G3 sent to observability-plan or runbook-generator are the first things operate picks up.

Verdicts

Defined in contracts/terminals.json. G3 emits PROCEED, PROCEED WITH CONDITIONS, REVISE or BLOCKED. G3.1 adds RECONSIDER. PROCEED WITH CONDITIONS at G3 is allowed only when the open rows are comms or exposure. A detection or response gap is always REVISE.

Non-interactive runs

Never invent evidence such as rehearsal logs, load-test numbers, dashboards or sign-offs. When the change being released cannot be identified, emit BLOCKED: need <the PR, tag, or feature name>. G3.1 is a human gate. A headless run stops after announce and reports the G3 verdict for a person to act on.

When a stage's skill is not installed

Name the missing skill and skilldrop as its source, do the minimal inline version of that stage, and record the stage as degraded. For ready, the minimal version is the seven checks written as a list, each marked met, not met or n/a with a reason. Skipping it is never the minimal version.

Run log (opt-in)

Only when the environment variable SKILLDROP_LOOP_LOG is set to a file path: after each gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is sent anywhere. When the variable isn't set, or you can't read it, skip this section.

printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"release","stage":"ready","gate":"G3","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"

Fields: ts (UTC), loop, stage, gate (null for a stage without one), verdict (the gate's exact word), and round (1 for the first attempt, counting returns under the cap). skilldrop loop-stats summarises the file: which gates pass first time, which loop back, and which end in BLOCKED.

Quality bar

Rollback exists before readiness is judged. A plan with no way back is the one thing that cannot be fixed after launch.
Readiness rests on evidence. Every check links to something; "we're good" is not met.
Can and should are separate gates. G3 says whether it can ship; G3.1 says whether it should ship now.
Detection gaps leave this loop as hand-offs. operate picks them up first, rather than discovering them during the first incident.

Anti-patterns to avoid

❌ Jumping from merge to "instrument a running service". That skips this loop entirely, which is the gap it exists to close.
❌ Announcing before G3. Customers hear about a launch that is then pulled.
❌ Treating flag-off as a rollback without a data story. If dual-write or a backfill has run, turning the flag off does not undo the data.
❌ Letting G3.1 overrule a G3 BLOCKED. A human can delay a ready launch; they cannot make an unready one ready by deciding to go.

Source

LOOP.md · loop.json on GitHub · Why loops