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.
1---2name: red-button3description: Use when an action could cause material, hard-to-reverse harm to production, data, security, finances, users, or external systems.4---56# Red Button78Some changes deserve a slower agent. Apply a focused gate only where consequence requires it.910## Classify the operation11121. Name the exact action, target environment, affected users or assets, and externally visible effect.132. 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.143. Keep reversible local edits, read-only inspection, isolated test work, and draft pull requests ordinary unless they themselves create consequential side effects.154. 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.165. For an ordinary operation, proceed with the normal workflow. Do not load a reference or manufacture a risk review.176. For a high-risk operation, name the risk category and load only the matching reference.1819## Load the focused reference2021| Risk category | Reference |22| --- | --- |23| Production schema or data migration; deletion or bulk repair | [data-operations.md](references/data-operations.md) |24| Force push, rebase of published work, or history rewrite | [repository-history.md](references/repository-history.md) |25| Authentication, authorization, IAM, secrets, or credentials | [identity-and-secrets.md](references/identity-and-secrets.md) |26| Charges, refunds, subscriptions, invoices, pricing, or payment flows | [billing-and-payments.md](references/billing-and-payments.md) |27| Infrastructure, networking, capacity, or production configuration | [infrastructure.md](references/infrastructure.md) |28| Public API contracts, events, schemas, or compatibility | [public-apis.md](references/public-apis.md) |29| Email, notification, campaign, or other bulk outreach | [mass-communication.md](references/mass-communication.md) |30| Production model, prompt, retrieval, guardrail, or tool-policy deployment | [model-and-prompt-deployments.md](references/model-and-prompt-deployments.md) |31| Other consequential operation with no matching category | Apply the core gate below; do not load an unrelated reference |3233Load 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.3435## Apply the gate3637Analysis, 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:38391. Resolve the target, blast radius, reversibility, monitoring, and authority with concrete evidence. Satisfy any loaded reference's additional preconditions and keep unknowns explicit.402. Prefer the smallest reversible action, staged rollout, and bounded exposure that can achieve the goal.413. Define observable success, stop conditions, and a recovery owner before creating side effects.424. 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.4344For 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.4546During 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.4748After 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.
Lum1104