gilde

← All craftbooks

Deploy Checklist

Ship and releaseevalv1.0.0released 2026-06-05workflow: build-loop

Author and then actually execute a pre-deploy verification checklist for shipping a release to production — the concrete gates that must be green before the deploy button is pressed: tests passing, build clean, migrations reviewed, config/secrets present, feature flags set, rollback path confirmed, and observability/alerts ready. A planner scopes the checklist tailored to this service and risk level, a developer runs each item and records real evidence (command output, links, screenshots) for pass or fail, and a reviewer signs off go/no-go. Use this before a production deploy, a release cut-over, or any 'are we ready to ship?' gate where skipping a step causes outages.

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Scope the checklistplannerentry

    define the go/no-go gates for THIS service and release

    Show working prompt
    1. Identify what is being deployed (service, version, target environment) and its blast radius / risk level. 2. Build the checklist of pre-deploy gates tailored to this service — at minimum: CI green (tests + lint + build), schema/data migrations reviewed and reversible, required config and secrets present in the target env, feature flags in their intended state, dependencies/external services healthy, a confirmed rollback path, and observability (dashboards, alerts, on-call) ready. 3. Drop any gate that genuinely does not apply and note why; add service-specific gates (cache warmups, queue drains, third-party rate limits) that do. 4. For each gate, write the EXACT verification step (the command to run, the URL to check, the artifact to inspect) and the explicit pass condition. 5. Good looks like: an ordered, unambiguous checklist where any engineer could execute each item and objectively decide pass/fail, and where each item has a defined pass condition. Write this as an acceptance-criteria checklist (each gate IS a criterion) plus the deploy context to the notes file via write_task_note AND to notes/scope.md.
  2. Verify each gatedeveloper

    execute every checklist item and record real evidence

    Show working prompt
    1. Open notes/scope.md and work through every gate IN ORDER, actually running the verification step (run the command, hit the endpoint, inspect the artifact) — do not assume, do not skip. 2. For each gate record: the step taken, the real evidence (command output, status, link), and a PASS or FAIL with the pass condition met or not. 3. If a gate FAILS, mark it FAIL with the specific reason — do not silently soften it; a failed gate is a no-go signal. 4. Render the result as a markdown checklist where every item is checked [x] only when its evidence genuinely supports PASS. 5. Conclude with an overall GO (all gates PASS) or NO-GO (any gate FAIL) recommendation and the single biggest risk. 6. Good looks like: a completed checklist where every gate from scope.md has attached evidence and an honest verdict, with a clear top-line go/no-go. Write the executed checklist to deploy-checklist.md.
  3. Sign off go/no-goreviewer

    audit the evidence and confirm the go/no-go decision

    Show working prompt
    1. Open deploy-checklist.md and audit each gate's EVIDENCE, not just its checkbox — a checked box with weak or missing evidence is a FAIL. 2. Confirm every gate from notes/scope.md is present and that no gate was dropped without a recorded reason. 3. Re-derive the overall verdict: if any gate is FAIL, the deploy is NO-GO regardless of the recorded recommendation. 4. Note any gate whose evidence is ambiguous and must be re-verified. 5. Write a PASS/FAIL per gate and a final, defensible GO or NO-GO with the deciding factors. 6. Any insufficient evidence routes back to the verify phase to re-run that gate. Write your sign-off to notes/report.md.
  4. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    Open deploy-checklist.md and verify it against the gates locked in notes/scope.md, PASS/FAIL each gate. Confirm: (a) every gate from scope.md appears with a recorded verification step; (b) each gate has REAL evidence (command output, link, or artifact), not just a checked box; (c) no gate was dropped without a stated reason; (d) the pass condition for each gate is genuinely met where marked PASS; (e) the document ends with a clear GO/NO-GO that is consistent with the gates (any FAIL ⇒ NO-GO). Any gate lacking evidence or wrongly marked routes back to the verify phase to re-run it.

Then route — this is the whole point of the loop:

- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "verify" })` to loop back. The builder fixes exactly those gaps.

Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.
  5. Finishdeveloper

    All acceptance criteria met. Stamp a short summary and report DONE.

    Show working prompt
    Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license