菜单
Use when planning a high-risk production change — classifies the change, assesses risk, runs pre-flight checks, builds an execution plan with rollback triggers, and verifies after completion.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when building any UI, HTML component, slide, document, or design asset that will represent SBP visually — applies the Schuberg Philis visual brand identity (colors, typography, logo, stylization, grids, photography, iconography) to ensure brand-consistent output without manual reminders.
Use when conducting a security review, reducing dependency surface, or when dependencies may pose supply-chain, bloat, or maintainability risks.
Use when deploying to production — verifies rollback readiness, monitoring, and change communication against mission-critical criteria and produces a go/no-go decision.
Use when a production incident has occurred — structured blameless post-incident analysis that reconstructs timeline, assesses impact, finds root causes, and produces concrete action items.
Use when verifying monitoring, alerting, and logging coverage — checks the four pillars (metrics, logs, traces, alerts), produces a coverage matrix with gaps, severity ratings, and recommended actions, and applies the 3 AM test to every component.
Use when existing code needs to change shape before a feature, or when code drift is making further work expensive — improves structure and readability without changing observable behavior.
| name | sbp-safe-change |
| description | Use when planning a high-risk production change — classifies the change, assesses risk, runs pre-flight checks, builds an execution plan with rollback triggers, and verifies after completion. |
| metadata | {"domain":"platform","lifecycle":"run"} |
This is a structured walkthrough for production changes that carry real risk. If you are nervous about a change, that instinct is correct — channel it into preparation, not avoidance.
The goal: turn anxiety into a checklist, execute methodically, and know exactly when to stop and roll back.
Name what you are doing. Different change types carry different risks.
State clearly: what is changing, why, and what the expected outcome is. If you cannot state the expected outcome in one sentence, the change is not well enough understood to proceed.
Answer each question honestly. The point is not to prove the change is safe — it is to understand exactly how it could go wrong.
Blast radius:
Reversibility:
Data loss potential:
Timing risk:
Assign an overall risk level:
Complete every item before executing the change. Skip nothing.
If any item cannot be completed, stop and assess whether the change should proceed. Document why you are proceeding without it.
Write the exact steps you will follow. This is not a summary — it is the script you execute.
For each step:
Example:
Step 1: Apply database migration
Action: kubectl exec -it deploy/app -- python manage.py migrate --database=primary
Expected: "Applying 0042_add_index... OK" with exit code 0
Verify: SELECT count(*) FROM pg_indexes WHERE indexname = 'idx_orders_customer_id'; — should return 1
Abort if: migration fails, takes longer than 5 minutes, or lock wait timeout appears in logs
Leave time between steps. Rushing through a plan defeats the purpose of having one.
Define the specific signals that mean "stop and roll back" before you start. Deciding this under pressure leads to bad decisions.
Write these triggers down and share them with whoever is watching with you. During the change, you are executing — your partner is watching for triggers.
After the change is complete and you believe it succeeded:
When verification is complete, communicate the outcome:
Feeling nervous about a production change is a feature, not a bug. It means you understand the stakes. This walkthrough exists to channel that awareness into methodical execution.
The engineer who follows a checklist is not being slow — they are being professional. The fastest incident response is the one that never happens.