rollback-prod
Roll back the most recent production release across configured deploy targets after an explicit typed confirmation. Use only when the user directly invokes /rollback-prod during incident response or release recovery.
- License 许可
- MIT
- 最近更新
- 2026-10-26
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- rollback-prod
- description
- Roll back the most recent production release across configured deploy targets after an explicit typed confirmation. Use only when the user directly invokes /rollback-prod during incident response or release recovery.
- argument-hint
- [--dry-run]
- user-invocable
- true
- disable-model-invocation
- true
02 资源文件 3
- 参考文档references/aws-amplify.md518 B
- 参考文档references/fly.md1.1 KB
- 参考文档references/vercel.md755 B
03 SKILL.md 正文
Rollback Prod
Roll back production deploy targets to their previous releases using each provider's native rollback primitive.
Workflow
-
Resolve the shared deploy helper:
if [ -f "$HOME/.claude/skills/deploy-status/scripts/deploy-ops.mjs" ]; then DEPLOY_OPS="$HOME/.claude/skills/deploy-status/scripts/deploy-ops.mjs" elif [ -f "skills/deploy-status/scripts/deploy-ops.mjs" ]; then DEPLOY_OPS="skills/deploy-status/scripts/deploy-ops.mjs" else echo "rollback-prod helper not found; re-run dotbabel bootstrap or dotbabel init" >&2 exit 2 fi -
Run the rollback planner/executor from the consuming project root:
node "$DEPLOY_OPS" rollback $ARGUMENTS -
Preserve the helper's exit code:
0- rollback ran and post-rollback status is in sync1- confirmation declined or post-rollback deploy status reports drift2- discovery, auth, release lookup, or rollback execution failed
Confirmation Contract
The helper always prints the rollback plan first. Unless --dry-run is present,
it must require the operator to type exactly:
ROLLBACK PROD
No --yes, environment variable, autonomous mode, or model routing decision may
bypass this confirmation. Provider CLIs may receive their own non-interactive
flags only after this confirmation succeeds.
Target Ordering
The helper uses the same target discovery as /deploy-status. If
.claude/deploy-targets.json contains rollback_order, targets matching each
entry are serialized in that order and targets in the same group run in
parallel. Example:
{
"rollback_order": ["fly", "vercel"]
}
This rolls backend targets back before frontend targets.
Provider References
Load only the provider notes that match discovered targets:
| Provider | Reference |
|---|---|
| Vercel | references/vercel.md |
| Fly.io | references/fly.md |
| AWS Amplify | references/aws-amplify.md |
Rules
- Never run rollback actions without typed confirmation.
- If any target cannot produce both current and previous releases, run no
rollback actions and exit
2. - If one target fails during rollback, report the partial state clearly and do not auto-revert targets that already succeeded.
- After attempted rollback actions, run deploy status automatically and print the new state.
04 同仓库更多 Skills
yolo
Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.
veracity-audit
Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace <label> (single source end-to-end). Invoke when: "audit pipeline", "veracity check", "scoring math correct?", "check gates", "trace source", "verify quality gates", "formula correct?".
validate-spec
Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs/audits/. Use whenever the user asks to "validate a spec", "audit a spec", "check if spec is implemented", "verify the spec is done", "is this spec really done", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.
terragrunt-specialist
Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: "Terragrunt audit", "run-all review", "dependency block", "DRY pattern review", "env hierarchy audit", "mock_outputs", "terragrunt hooks".
terraform-specialist
Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".
spec
Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on "let's spec this out", "create a spec", "design doc", "write a technical plan", "plan the architecture". Works for greenfield and brownfield projects. Outputs to docs/specs/.