red-button

Your agents treat every change like a green light.
This skill adds a red button for risky ones.

Install · Before / After · How it works · Risk references · Read the skill

---

Renaming a local variable and changing a production database should not get the same workflow.

red-button detects high-risk operations and loads only the safeguards that fit. Ordinary reversible work stays ordinary; consequential changes get checks for blast radius, recovery, rollout, monitoring, and approval.

Install

Install with the Skills CLI:

npx skills add Lum1104/red-button

Install globally for all projects:

npx skills add Lum1104/red-button -g

Then invoke it explicitly where your agent supports skill syntax:

$red-button Plan a zero-downtime migration for the production users table.

Or ask in plain language:

Use red-button to review this production Terraform apply before any changes are made.

Before / after

Suppose the task is: “Make users.email non-null in production and deploy it.”

Without red-button

Added ALTER TABLE users ALTER COLUMN email SET NOT NULL. Migration tests pass. Ready to deploy.

The code may be correct, but important questions remain unanswered: Which database? How many nulls exist? Will the statement lock the table? Can the running application tolerate both shapes? What stops the rollout? Who approved the destructive contract step?

With red-button

Classification: high-risk production data operation.

Unresolved before execution: exact database and region, null-row count, lock behavior, application compatibility, recovery source, stop thresholds, and approval for the contract step.

Safer sequence: deploy tolerant readers first; add or validate constraints without a long blocking operation where the database supports it; backfill in bounded, resumable batches; observe locks, lag, latency, and errors; switch writers; verify invariants; request separate approval before removing compatibility or enforcing the final contraction.

The skill changes the workflow from “the migration file looks right” to “the real operation has a bounded, observable plan.” It still cannot guarantee that the migration is safe.

Important

Installing or invoking red-button does not authorize an operation and does not make a dangerous operation safe. It helps surface evidence, limits, stop conditions, recovery options, and approval boundaries. The responsible owner still decides whether execution is permitted.

How it works

red-button first asks whether the task is an ordinary reversible edit or an operation with material consequences.

Task
 ├─ Ordinary, reversible, local
 │    └─ Continue with the normal development workflow
 │
 └─ Destructive, hard to reverse, security-sensitive,
      financial, broad, or externally consequential
           ↓
      Resolve the exact action, target, scope, and effect
           ↓
      Load a matching risk reference when one fits
           ↓
      Check preconditions → rehearse → bound rollout
           ↓
      Define monitoring, stop conditions, and recovery
           ↓
      Obtain approval for the exact consequential boundary
           ↓
      Execute only within those bounds; verify the real effect

Uncertainty about the target, blast radius, recovery path, or authority is something to resolve before execution—not a reason to improvise. A task that spans two categories may load two references; an unmatched consequential operation uses the core gate without loading an unrelated guide; an ordinary edit loads none.

Focused risk references

The main skill stays short. It dynamically loads only the reference relevant to the operation.

Category	Loaded for	Focus
Production data operations	Schema migrations, backfills, deletion, bulk repair	Manifests, invariants, bounded batches, restore paths
Published repository history	Force pushes, shared-branch rebases, history rewrites	Backup refs, leases, collaborator recovery
Identity and secrets	Auth, permissions, IAM, credentials, secret rotation	Deny/allow tests, versioned rotation, emergency access
Billing and payments	Charges, refunds, pricing, invoices, subscriptions	Idempotency, reconciliation, financial exposure
Production infrastructure	Networking, capacity, state, production configuration	Effective plans, failure domains, canaries, SLO signals
Public API compatibility	Endpoints, events, schemas, SDKs, contract changes	Consumer impact, additive evolution, deprecation windows
Mass communication	Email, notifications, campaigns, bulk outreach	Frozen audiences, deduplication, volume ceilings
Model and prompt deployments	Models, prompts, retrieval, guardrails, tool policies	Versioned bundles, evals, shadowing, traffic rollback

Each reference is deliberately narrow: preconditions, rehearsal and staging, monitoring and stop conditions, recovery, and the approval boundary for that category.

Approval and reversibility limits

• Technical access is not authorization. Approval must cover the exact action, target, scope, environment, and consequential boundary.
• Some effects are not retractable: delivered messages, exposed credentials, consumed API responses, and settled financial events may require compensation or incident handling rather than rollback.
• A backup is not proof of recoverability. Restoration time, retained data, compatibility, and the recovery procedure must fit the actual operation.
• If the necessary authority or recovery evidence is missing, red-button should stop at analysis or rehearsal and report what remains unresolved.

The skill cannot supply organizational approval, verify facts it cannot observe, create a rollback where none exists, or replace the accountable production, security, data, financial, or product owner.

What is in this repository

Path	Purpose
SKILL.md	Core classification and execution gate loaded by the agent
references/	Eight category-specific guides loaded only when relevant
LICENSE	MIT license

There is no runtime service, framework, or automation layer. red-button is a focused set of instructions and references; your agent uses its existing tools and remains subject to their permissions and your approvals.

Related skills

• no-vibes — separate verified outcomes from inferred completion.
• bet-on-it — record predictions before meaningful experiments or changes.
• archaeologist — inspect repository history when the past changes the decision.
• prove-me-wrong — try to falsify the current explanation or fix.

License

MIT