Red Button

Red Button

Some changes deserve a slower agent. Apply a focused gate only where consequence requires it.

Classify the operation

1. Name the exact action, target environment, affected users or assets, and externally visible effect.
2. Classify the operation as ordinary or high-risk. Mark it high-risk if failure could 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.
3. Treat uncertainty about the target, blast radius, rollback, or authority as risk to resolve before execution.
4. For an ordinary operation, proceed with the normal workflow. Do not load a reference or manufacture a risk review.
5. For a high-risk operation, name the risk category and load only its reference. Load multiple references only when the operation genuinely crosses categories.

Load the focused reference

| Risk category | Reference | | --- | --- | | Production schema or data migration; deletion or bulk repair | [data-operations.md](references/data-operations.md) | | Force push, rebase of published work, or history rewrite | [repository-history.md](references/repository-history.md) | | Authentication, authorization, IAM, secrets, or credentials | [identity-and-secrets.md](references/identity-and-secrets.md) | | Charges, refunds, subscriptions, invoices, pricing, or payment flows | [billing-and-payments.md](references/billing-and-payments.md) | | Infrastructure, networking, capacity, or production configuration | [infrastructure.md](references/infrastructure.md) | | Public API contracts, events, schemas, or compatibility | [public-apis.md](references/public-apis.md) | | Email, notification, campaign, or other bulk outreach | [mass-communication.md](references/mass-communication.md) | | Production model, prompt, retrieval, guardrail, or tool-policy deployment | [model-and-prompt-deployments.md](references/model-and-prompt-deployments.md) |

Apply the gate

Before acting:

1. Satisfy the loaded reference's preconditions with concrete evidence. Keep unknowns explicit.
2. Separate analysis, rehearsal, and approval from the consequential execution step.
3. Prefer the smallest reversible action, staged rollout, and bounded exposure that can achieve the goal.
4. Define observable success, stop conditions, and a recovery owner before creating side effects.
5. Request approval at the boundary named by the reference unless the user has already authorized that exact action, target, and scope. Never treat technical access as authorization.

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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Lum1104
• Source: Lum1104/red-button
• License: MIT

Install and usage instructions live in the source repository linked above.