一键导入
deployment-safety
Production deployment rules, rollback-first recovery, dependency batching, CI cost awareness, and framework upgrade verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Production deployment rules, rollback-first recovery, dependency batching, CI cost awareness, and framework upgrade verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Push accountability, CI monitoring after push, background agent CI verification, verification command sequencing.
Always use when user asks to create, generate, draw, or design a diagram, flowchart, architecture diagram, ER diagram, sequence diagram, class diagram, network diagram, mockup, wireframe, or UI sketch, or mentions draw.io, drawio, drawoi, .drawio files, or diagram export to PNG/SVG/PDF.
Known agent error patterns -- debugging reference for tool failures, git errors, CI issues, and common mistakes. Consult when encountering unexpected behavior, tool errors, or CI failures.
Git recipes, worktree management, push sequences, branch verification, and conflict resolution patterns.
gh CLI patterns, JSON field discovery, PR check interpretation, label management, merge settings verification.
macOS-specific patterns: launchd agent configuration, brew vs pip, zsh regex quirks, file descriptor limits.
| name | Deployment Safety |
| description | Production deployment rules, rollback-first recovery, dependency batching, CI cost awareness, and framework upgrade verification. |
Wrong -- merge Dependabot PR thinking it's cleanup:
gh pr merge 42 --merge # Dependabot targets main = production deploy
Right -- move the update onto the non-production integration path, close the PR, and release normally:
# develop/main topology:
git checkout develop && git cherry-pick <commit>
gh pr close 42 # release via develop -> main
# main-only topology:
git checkout -b chore/dependency-updates main
git cherry-pick <commit>
gh pr close 42 # validate on branch/PR before merging back to main
Wrong -- merge N PRs one-by-one (O(n^2) rebase cascade):
gh pr merge 1 && gh pr merge 2 && gh pr merge 3
# 7 PRs x 9 workflows = ~189 wasted CI runs
Right -- batch into a single branch:
# develop/main topology:
git checkout -b chore/dependency-updates develop
# main-only topology:
git checkout -b chore/dependency-updates main
# Apply all updates, run CI once, merge one PR
Wrong -- push partial work to see if CI passes:
git push # 9 workflows triggered, guess and check
Right -- test locally, push once:
pnpm run typecheck 2>&1; pnpm run lint 2>&1; pnpm run test 2>&1
git push # confident it works
Wrong -- merge after CI passes (CI != production):
gh pr merge 99 --squash # CI green, serverless runtime crashes
Right -- verify on preview deployment first:
# Push to non-main branch -> preview URL
# Verify: site loads, API routes respond, health checks pass
# Only then merge to main
Wrong -- deploy fixes to prod while investigating:
vercel deploy --prod # fails, deploy again, fails again
Right -- roll back first, investigate second:
vercel rollback # Step 1: restore service immediately
# Step 2: investigate on non-production (logs, preview URL)
# Step 3: fix on the integration path, verify on preview,
# then merge to the production branch
Before any CI run, deployment, or API call:
1. Is this needed? (Can I achieve this locally?)
2. Is this justified? (Does this advance the task?)
3. Is this verifiable? (Will I know if it succeeded?)
If any answer is "no" -- do not proceed.