Pre-deployment verification checklist. Generates customized checklists based on tech-stack with rollback triggers. Auto-invoked by /draft:upload.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Pre-deployment verification checklist. Generates customized checklists based on tech-stack with rollback triggers. Auto-invoked by /draft:upload.
Deploy Checklist
You are generating a pre-deployment verification checklist customized to this project's technology stack.
MANDATORY GRAPH LOOKUP (read before Phase 1)
When draft/graph/schema.yaml exists, this skill must follow the graph-first lookup contract in core/shared/graph-query.md §Mandatory Lookup Contract. Use the graph to validate module boundaries before the deploy:
For each file in the deploy diff, run scripts/tools/graph-impact.sh --repo . --file <path> to enumerate the modules affected — flag any module not declared in hld.md §Detailed Design as a deployment-scope miss.
Run scripts/tools/cycle-detect.sh --repo . (and read draft/graph/architecture.json for the module overview) to ensure no fresh cycles were introduced after HLD sign-off.
Load draft/graph/hotspots.jsonl — any hotspot in the diff escalates the Resiliency row of Phase 0.
Filesystem grep is reserved for source-text scans (migration file names, flag-key strings). Module/impact discovery goes through the graph.
Deploying on Friday without explicit team approval
Pushing to production without monitoring in place
Ignoring failed checklist items marked as critical
Every deployment needs a rollback plan. No exceptions.
Pre-Check
0. Capture Git Context
Before starting, capture the current git state:
git branch --show-current # Current branch name
git rev-parse --short HEAD # Current commit hash
Store this for the checklist header. The checklist is scoped to this specific branch/commit.
1. Verify Draft Context
ls draft/ 2>/dev/null
If draft/ doesn't exist, this skill can still run standalone — generate a generic checklist.
2. Load Draft Context (if available)
Read and follow the base procedure in core/shared/draft-context-loading.md.
3. Run validator gate chain (WS-9)
Canonical chain documented in
core/shared/verification-gates.md.
A single non-zero exit aborts the checklist and the output groups defects
by validator.
After the chain runs, write the result into metadata.json:pre_deploy_status
(passing / failing / bypassed). The downstream checklist sections must
not be considered "ready to deploy" if pre_deploy_status != passing.
Step 1: Parse Arguments
Check for arguments:
/draft:deploy-checklist — Interactive: detect active track or ask for service name
/draft:deploy-checklist <service> — Generate checklist for named service
/draft:deploy-checklist track <id> — Generate from track's change scope
If a track is active: read draft/tracks/<id>/spec.md and plan.md for change scope.
Read draft/.ai-context.md — Service topology, dependencies
If track-scoped: Read draft/tracks/<id>/hld.md and lld.md if present — these are the source of truth for HLD §Checklist (Performance, Scale, Security, Resiliency, Multi-tenancy, Upgrade, Cost, Flags), §Deployment, §Observability, and LLD §Alerting Thresholds. The deploy checklist validates they are populated.
Step 3: Generate Checklist
Generate a four-phase checklist customized to the project's tech stack. Adapt items based on what the project actually uses — omit irrelevant items (e.g., skip database items if there is no database) and add project-specific items discovered in context.
Phase 0: HLD/LLD Gate (track-scoped only, when hld.md exists)
** blocker:** the HLD's §Checklist sections were the design-time commitment. If they are still empty at deploy time, the design was never validated against operational reality. This phase enforces that.
For criticality ∈ {high, mission-critical} (read from hld.md frontmatter classification.criticality), every row below MUST be checked before Phase 1 begins. For standard criticality, missing rows produce warnings but do not block. For low, this phase is informational.
HLD §Performance populated — QPS and p95 latency stated
HLD §Scale populated — horizontal scaling story documented; bottlenecks named
HLD §Observability populated — key metrics named with thresholds
HLD §Approvals table signed by Technical Leads and Architecture Review Board (and Cloud Operations if SaaS, QA if on-prem) — Date column populated
LLD §Alerting Thresholds table populated (when lld.md exists) — every metric has Threshold, Severity, Action
If any blocker row is empty for high/mission-critical: STOP. Do not generate Phases 1–3, do not run Step 5 (Save Output), and do not create the deploy-checklist.md file. Tell the developer: "HLD/LLD §[section] is empty for a [criticality] track. Fill it in hld.md / lld.md before deploy. Run /draft:decompose to refresh structural sections; author-driven sections must be filled manually."
If a partial file is needed for tracking, write it with status: BLOCKED in the frontmatter and _latest symlinks must NOT be updated — /draft:upload Step 2.5 detects status: BLOCKED and refuses to treat the file as a passing checklist.
Phase 1: Pre-Deploy
Tests: All tests passing in CI
Review: Code reviewed and approved
Migrations: Database migrations tested on staging (if applicable)
Mandatory Self-Check (before saving the checklist)
Before saving the checklist file, internally verify and report:
Graph files queried — JSONL files loaded plus any live graph query-tool invocations (impact, cycles, modules).
Layer 1 files deliberately skipped — list any context sections skipped.
Filesystem grep fallback justification — for every grep/find run, name the concept it searched for.
If draft/graph/schema.yaml does not exist, set Graph files queried: NONE and use justification graph data unavailable.
Graph Usage Report (append to checklist)
Emit the canonical footer from core/shared/graph-usage-report.md §Canonical footer. The lint hook scripts/tools/check-graph-usage-report.sh validates the section on save.
References:core/agents/ops.md for production-safety mindset
Jira sync: If ticket linked, attach checklist and post comment via core/shared/jira-sync.md
MCP: GitHub MCP for change details, Jira MCP for ticket context
Error Handling
If no tech-stack.md: Generate generic checklist with all items, note: "Customize after running /draft:init"
If no active track: Generate standalone checklist, ask which service/release
If no workflow.md: Use sensible defaults, recommend documenting deployment conventions