| name | red-button |
| description | Use when an action could cause material, hard-to-reverse harm to production, data, security, finances, users, or external systems. |
Red Button
Some changes deserve a slower agent. Apply a focused gate only where consequence requires it.
Classify the operation
- Name the exact action, target environment, affected users or assets, and externally visible effect.
- Classify the operation as
ordinary or high-risk. Mark it high-risk when a credible failure could materially destroy or expose important state, cross a security or authorization boundary, move money, contact many people, break external consumers, disrupt production, or resist timely recovery.
- Keep reversible local edits, read-only inspection, isolated test work, and draft pull requests ordinary unless they themselves create consequential side effects.
- When risk is uncertain, use read-only checks to resolve the target, blast radius, rollback, and authority. Uncertainty alone does not make ordinary work high-risk.
- For an ordinary operation, proceed with the normal workflow. Do not load a reference or manufacture a risk review.
- For a high-risk operation, name the risk category and load only the matching reference.
Load the focused reference
| Risk category | Reference |
|---|
| Production schema or data migration; deletion or bulk repair | data-operations.md |
| Force push, rebase of published work, or history rewrite | repository-history.md |
| Authentication, authorization, IAM, secrets, or credentials | identity-and-secrets.md |
| Charges, refunds, subscriptions, invoices, pricing, or payment flows | billing-and-payments.md |
| Infrastructure, networking, capacity, or production configuration | infrastructure.md |
| Public API contracts, events, schemas, or compatibility | public-apis.md |
| Email, notification, campaign, or other bulk outreach | mass-communication.md |
| Production model, prompt, retrieval, guardrail, or tool-policy deployment | model-and-prompt-deployments.md |
| Other consequential operation with no matching category | Apply the core gate below; do not load an unrelated reference |
Load multiple references only when risks truly cross categories: public API plus identity for an auth-scope change, billing plus data for a ledger migration, or model deployment plus identity for a privileged tool.
Apply the gate
Analysis, coding, local tests, plans, and isolated rehearsal may proceed without execution approval when they create no consequential side effect. Before crossing the real side-effect boundary:
- Resolve the target, blast radius, reversibility, monitoring, and authority with concrete evidence. Satisfy any loaded reference's additional preconditions and keep unknowns explicit.
- Prefer the smallest reversible action, staged rollout, and bounded exposure that can achieve the goal.
- Define observable success, stop conditions, and a recovery owner before creating side effects.
- Obtain authorization for the exact action, target, and scope from the responsible owner, plus any approval named by a loaded reference. Existing user authorization counts only where that user has the relevant authority. Never infer authority from technical access.
For a declared incident, use the established incident-command approval path and record the decision. Urgency does not remove scope bounds, stop conditions, or post-change verification.
During execution, verify the resolved target again, preserve the safety bounds, observe the chosen signals, and stop when a stop condition fires. Do not improvise past a failed guardrail.
After execution, verify the real effect and recovery posture. Report what changed, the scope reached, the evidence observed, any remaining risk, and whether rollback remains available.
