Skip to content
Back to skills

red-button

ASecurity

Use when an action could cause material, hard-to-reverse harm to production, data, security, finances, users, or external systems.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 6, 2026
ai-agentsgoapisecurity

Works with

  • api

Security analysis

A100/100

Pro scans all 9 files and shows the line behind each finding

Scanned September 6, 2026

npx -y skills add Lum1104/red-button --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of red-button?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for red-button
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/lum1104-red-button/badge)](https://www.skillsdirectory.com/skills/lum1104-red-button)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

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 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.
3. Keep reversible local edits, read-only inspection, isolated test work, and draft pull requests ordinary unless they themselves create consequential side effects.
4. 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.
5. For an ordinary operation, proceed with the normal workflow. Do not load a reference or manufacture a risk review.
6. 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](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) |
| 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:

1. Resolve the target, blast radius, reversibility, monitoring, and authority with concrete evidence. Satisfy any loaded reference's additional preconditions and keep unknowns explicit.
2. Prefer the smallest reversible action, staged rollout, and bounded exposure that can achieve the goal.
3. Define observable success, stop conditions, and a recovery owner before creating side effects.
4. 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.

Files in this skill

  • SKILL.md4 KB
  • references/billing-and-payments.md3 KB
  • references/data-operations.md3.3 KB
  • references/identity-and-secrets.md2.9 KB
  • references/infrastructure.md2.6 KB
  • references/mass-communication.md2.5 KB
  • references/model-and-prompt-deployments.md2.7 KB
  • references/public-apis.md2.2 KB
  • references/repository-history.md2.2 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.