Safety guardrails that activate before high-risk operations. Prevents destructive, irreversible, or security-sensitive changes without explicit confirmation. Triggers: destructive operations, production configs, database migrations, security-sensitive files, "be careful", "careful mode".
From superomninpx claudepluginhub wilder1222/superomni --plugin superomniThis skill is limited to using the following tools:
SKILL.md.tmplSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
mkdir -p ~/.omni-skills/sessions
_PROACTIVE=$(~/.claude/skills/superomni/bin/config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
_TEL_START=$(date +%s)
echo "Branch: ---
name: careful
description: |
Safety guardrails that activate before high-risk operations.
Prevents destructive, irreversible, or security-sensitive changes without explicit confirmation.
Triggers: destructive operations, production configs, database migrations, security-sensitive files, "be careful", "careful mode".
allowed-tools: [Bash, Read, Write, Edit, Grep, Glob]
---
{{PREAMBLE}}
# Careful — Safety Guardrails
**Goal:** Prevent costly mistakes by enforcing risk assessment, blast radius calculation, and user confirmation before any high-risk operation.
## Iron Law
**ALWAYS CONFIRM BEFORE DESTRUCTIVE OPERATIONS.**
Never execute a destructive, irreversible, or security-sensitive operation without explicit user approval. "I assumed it was fine" is never an acceptable justification for data loss or a security incident.
## Trigger Conditions
This skill activates automatically when any of the following are detected:
### Destructive Operations
- `rm -rf`, `DROP TABLE`, `DELETE FROM` without `WHERE`
- `git push --force`, `git reset --hard`, branch deletion
- Overwriting files without backup
- Truncating logs or databases
### Production-Touching Changes
- Editing files matching `*prod*`, `*production*`, `*.env.prod*`
- Modifying deployment configs (`Dockerfile`, `docker-compose.yml`, `k8s/*.yaml`)
- Changing CI/CD pipelines (`.github/workflows/*`, `Jenkinsfile`, `.gitlab-ci.yml`)
- Updating infrastructure-as-code (`*.tf`, `*.tfvars`, `cloudformation*`)
### Security-Sensitive Files
- Anything containing secrets, keys, tokens, or credentials
- Auth/authorization logic
- Encryption configuration
- CORS or CSP policies
- `.env` files, certificate files, key stores
### Database Migrations
- Schema changes (`ALTER TABLE`, `ADD COLUMN`, `DROP COLUMN`)
- Data migrations that transform existing records
- Index changes on large tables
- Any migration that cannot be rolled back
## Phase 1: Risk Assessment
When a trigger condition is detected, STOP and assess:
⚠️ HIGH-RISK OPERATION DETECTED ───────────────────────────────── Operation: [what you're about to do] Trigger: [which trigger condition matched] Files: [files that will be affected]
Answer these questions:
1. **What could go wrong?** — list specific failure modes
2. **What is the worst-case outcome?** — data loss? downtime? security breach?
3. **Has this been done before?** — is there precedent in the project?
## Phase 2: Blast Radius Calculation
Determine how much of the system this change affects.
```bash
# For code changes: who depends on this?
grep -rl "$(basename <changed-file> | sed 's/\..*//')" . \
--include="*.js" --include="*.ts" --include="*.py" --include="*.go" \
2>/dev/null | grep -v "node_modules\|.git" | wc -l
# For config changes: what environments are affected?
grep -l "<config-key>" . -r --include="*.env*" --include="*.yaml" --include="*.json" \
2>/dev/null | head -10
# For database changes: how many rows affected?
# (estimate or query with EXPLAIN before executing)
BLAST RADIUS
─────────────────────────────────
Scope: [LOCAL/MODULE/SERVICE/GLOBAL]
Files affected: [N direct, N indirect]
Users affected: [none/some/all]
Environments: [dev/staging/production]
Estimated impact: [LOW/MEDIUM/HIGH/CRITICAL]
─────────────────────────────────
| Level | Meaning | Approval needed |
|---|---|---|
| LOCAL | Only the changed file is affected | Proceed with caution |
| MODULE | Other files in the same module are affected | Review before proceeding |
| SERVICE | Other services or APIs could be affected | User confirmation required |
| GLOBAL | Production, all users, or infrastructure affected | Explicit user approval + rollback plan |
Before proceeding, confirm the operation can be undone.
| Question | Answer |
|---|---|
Can this be reverted with git revert? | [yes/no] |
| Is there a database backup? | [yes/no/N/A] |
| Can the deployment be rolled back? | [yes/no/N/A] |
| Is there a feature flag to disable this? | [yes/no/N/A] |
| What is the recovery time if this goes wrong? | [minutes/hours/days/never] |
REVERSIBILITY
─────────────────────────────────
Reversible: [YES/PARTIAL/NO]
Rollback method: [git revert / backup restore / feature flag / manual]
Recovery time: [estimate]
Data loss risk: [NONE/POSSIBLE/CERTAIN]
─────────────────────────────────
If Reversible = NO and Blast Radius = SERVICE or GLOBAL: → STOP. Do not proceed without explicit user approval AND a mitigation plan.
Present the risk summary and wait for explicit approval.
╔══════════════════════════════════════╗
║ ⚠️ CONFIRMATION REQUIRED ║
╠══════════════════════════════════════╣
║ ║
║ Operation: [description] ║
║ Blast radius: [level] ║
║ Reversible: [yes/partial/no] ║
║ Risk: [LOW/MEDIUM/HIGH/CRIT] ║
║ ║
║ Worst case: [what could happen] ║
║ Mitigation: [how to recover] ║
║ ║
║ Proceed? (yes/no) ║
║ ║
╚══════════════════════════════════════╝
Do not proceed until the user explicitly confirms.
If the user confirms:
If the user declines:
When in doubt, apply these defaults:
| Situation | Safe default |
|---|---|
| Delete file vs. rename/move | Rename to .bak first |
| Force push vs. regular push | Regular push (fail if rejected) |
| Drop column vs. deprecate | Deprecate first, drop later |
| Edit production config | Edit staging first, verify, then production |
| Run migration | Run on dev/staging first, verify, then production |
| Overwrite file | Create backup copy first |
CAREFUL ASSESSMENT
════════════════════════════════════════
Operation: [what was requested]
Trigger: [what activated this skill]
Blast radius: [LOCAL/MODULE/SERVICE/GLOBAL]
Reversibility: [YES/PARTIAL/NO]
Risk level: [LOW/MEDIUM/HIGH/CRITICAL]
User confirmed: [yes/no/not yet]
Outcome: [executed successfully / blocked / alternative proposed]
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
════════════════════════════════════════
{{PREAMBLE}}
Goal: Prevent costly mistakes by enforcing risk assessment, blast radius calculation, and user confirmation before any high-risk operation.
ALWAYS CONFIRM BEFORE DESTRUCTIVE OPERATIONS.
Never execute a destructive, irreversible, or security-sensitive operation without explicit user approval. "I assumed it was fine" is never an acceptable justification for data loss or a security incident.
This skill activates automatically when any of the following are detected:
rm -rf, DROP TABLE, DELETE FROM without WHEREgit push --force, git reset --hard, branch deletion*prod*, *production*, *.env.prod*Dockerfile, docker-compose.yml, k8s/*.yaml).github/workflows/*, Jenkinsfile, .gitlab-ci.yml)*.tf, *.tfvars, cloudformation*).env files, certificate files, key storesALTER TABLE, ADD COLUMN, DROP COLUMN)When a trigger condition is detected, STOP and assess:
⚠️ HIGH-RISK OPERATION DETECTED
─────────────────────────────────
Operation: [what you're about to do]
Trigger: [which trigger condition matched]
Files: [files that will be affected]
Answer these questions:
Determine how much of the system this change affects.
# For code changes: who depends on this?
grep -rl "$(basename <changed-file> | sed 's/\..*//')" . \
--include="*.js" --include="*.ts" --include="*.py" --include="*.go" \
2>/dev/null | grep -v "node_modules\|.git" | wc -l
# For config changes: what environments are affected?
grep -l "<config-key>" . -r --include="*.env*" --include="*.yaml" --include="*.json" \
2>/dev/null | head -10
# For database changes: how many rows affected?
# (estimate or query with EXPLAIN before executing)
BLAST RADIUS
─────────────────────────────────
Scope: [LOCAL/MODULE/SERVICE/GLOBAL]
Files affected: [N direct, N indirect]
Users affected: [none/some/all]
Environments: [dev/staging/production]
Estimated impact: [LOW/MEDIUM/HIGH/CRITICAL]
─────────────────────────────────
| Level | Meaning | Approval needed |
|---|---|---|
| LOCAL | Only the changed file is affected | Proceed with caution |
| MODULE | Other files in the same module are affected | Review before proceeding |
| SERVICE | Other services or APIs could be affected | User confirmation required |
| GLOBAL | Production, all users, or infrastructure affected | Explicit user approval + rollback plan |
Before proceeding, confirm the operation can be undone.
| Question | Answer |
|---|---|
Can this be reverted with git revert? | [yes/no] |
| Is there a database backup? | [yes/no/N/A] |
| Can the deployment be rolled back? | [yes/no/N/A] |
| Is there a feature flag to disable this? | [yes/no/N/A] |
| What is the recovery time if this goes wrong? | [minutes/hours/days/never] |
REVERSIBILITY
─────────────────────────────────
Reversible: [YES/PARTIAL/NO]
Rollback method: [git revert / backup restore / feature flag / manual]
Recovery time: [estimate]
Data loss risk: [NONE/POSSIBLE/CERTAIN]
─────────────────────────────────
If Reversible = NO and Blast Radius = SERVICE or GLOBAL: → STOP. Do not proceed without explicit user approval AND a mitigation plan.
Present the risk summary and wait for explicit approval.
╔══════════════════════════════════════╗
║ ⚠️ CONFIRMATION REQUIRED ║
╠══════════════════════════════════════╣
║ ║
║ Operation: [description] ║
║ Blast radius: [level] ║
║ Reversible: [yes/partial/no] ║
║ Risk: [LOW/MEDIUM/HIGH/CRIT] ║
║ ║
║ Worst case: [what could happen] ║
║ Mitigation: [how to recover] ║
║ ║
║ Proceed? (yes/no) ║
║ ║
╚══════════════════════════════════════╝
Do not proceed until the user explicitly confirms.
If the user confirms:
If the user declines:
When in doubt, apply these defaults:
| Situation | Safe default |
|---|---|
| Delete file vs. rename/move | Rename to .bak first |
| Force push vs. regular push | Regular push (fail if rejected) |
| Drop column vs. deprecate | Deprecate first, drop later |
| Edit production config | Edit staging first, verify, then production |
| Run migration | Run on dev/staging first, verify, then production |
| Overwrite file | Create backup copy first |
CAREFUL ASSESSMENT
════════════════════════════════════════
Operation: [what was requested]
Trigger: [what activated this skill]
Blast radius: [LOCAL/MODULE/SERVICE/GLOBAL]
Reversibility: [YES/PARTIAL/NO]
Risk level: [LOW/MEDIUM/HIGH/CRITICAL]
User confirmed: [yes/no/not yet]
Outcome: [executed successfully / blocked / alternative proposed]
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
════════════════════════════════════════
PROACTIVE"
### PROACTIVE Mode
If `PROACTIVE` is `false`: do NOT proactively suggest skills. Only run skills the
user explicitly invokes. If you would have auto-invoked, say:
*"I think [skill-name] might help here — want me to run it?"* and wait.
### Completion Status Protocol
Report status using one of these at the end of every skill session:
- **DONE** — All steps completed. Evidence provided.
- **DONE_WITH_CONCERNS** — Completed with issues. List each concern explicitly.
- **BLOCKED** — Cannot proceed. State what blocks you and what was tried.
- **NEEDS_CONTEXT** — Missing information. State exactly what you need.
### Auto-Advance Rule
Pipeline stage order: THINK → PLAN → REVIEW → BUILD → VERIFY → SHIP → REFLECT
**THINK is the only human gate.** After the brainstorm skill generates a spec document, STOP and present the spec for user review. Once the user approves, all subsequent stages (PLAN → REVIEW → BUILD → VERIFY → SHIP → REFLECT) auto-advance on DONE without asking the user.
| Status | At THINK stage (after spec generation) | At all other stages |
|--------|----------------------------------------|-------------------|
| **DONE** | STOP — present spec document for user review. Wait for user approval before advancing to PLAN. | Auto-advance — print `[STAGE] DONE → advancing to [NEXT-STAGE]` and immediately invoke next skill |
| **DONE_WITH_CONCERNS** | STOP — present concerns, wait for user decision | STOP — present concerns, wait for user decision |
| **BLOCKED** / **NEEDS_CONTEXT** | STOP — present blocker, wait for user | STOP — present blocker, wait for user |
When auto-advancing:
1. Write the session artifact to `docs/superomni/`
2. Print: `[STAGE] DONE → advancing to [NEXT-STAGE] ([skill-name])`
3. Immediately invoke the next pipeline skill
**Note:** The REVIEW stage (plan-review) runs fully automatically — all decisions (mechanical and taste) are auto-resolved using the 6 Decision Principles. No user input is requested during REVIEW.
### Session Continuity
When the user sends a **follow-up message after a completed session**, before doing anything else:
1. Scan for prior session context:
```bash
ls docs/superomni/specs/spec-*.md docs/superomni/plans/plan-*.md docs/superomni/ .superomni/ 2>/dev/null | head -20
git log --oneline -3 2>/dev/null
To find the latest spec or plan:
_LATEST_SPEC=$(ls docs/superomni/specs/spec-*.md 2>/dev/null | sort | tail -1)
_LATEST_PLAN=$(ls docs/superomni/plans/plan-*.md 2>/dev/null | sort | tail -1)
workflow skill for stage → skill mapping) and announce:
"Continuing in superomni mode — picking up at [stage] using [skill-name]."using-skills/SKILL.md.When asking the user a question, match the confirmation requirement to the complexity of the response:
| Question type | Confirmation rule |
|---|---|
| Single-choice — user picks one option (A/B/C, 1/2/3, Yes/No) | The user's selection IS the confirmation. Do NOT ask "Are you sure?" or require a second submission. |
| Free-text input — user types a value and presses Enter | The submitted text IS the confirmation. No secondary prompt needed. |
| Multi-choice — user selects multiple items from a list | After the user lists their selections, ask once: "Confirm these selections? (Y to proceed)" before acting. |
| Complex / open-ended discussion — back-and-forth clarification | Collect all input, then present a summary and ask: "Ready to proceed with the above? (Y/N)" before acting. |
Rule: never add a redundant confirmation layer on top of a single-choice or text-input answer.
Custom Input Option Rule: Whenever you present a predefined list of choices (A/B/C, numbered options, etc.), always append a final "Other" option that lets the user describe their own idea:
[last letter/number + 1]) Other — describe your own idea: ___________
When the user selects "Other" and provides their custom text, treat that text as the chosen option and proceed exactly as you would for any other selection. If the custom text is ambiguous, ask one clarifying question before proceeding.
Load context progressively — only what is needed for the current phase:
| Phase | Load these | Defer these |
|---|---|---|
| Planning | Latest docs/superomni/specs/spec-*.md, constraints, prior decisions | Full codebase, test files |
| Implementation | Latest docs/superomni/plans/plan-*.md, relevant source files | Unrelated modules, docs |
| Review/Debug | diff, failing test output, minimal repro | Full history, specs |
If context pressure is high: summarize prior phases into 3-5 bullet points, then discard raw content.
All skill artifacts are written to docs/superomni/ (relative to project root).
See the Document Output Convention in CLAUDE.md for the full directory map.
Agent failures are harness signals — not reasons to retry the same approach:
harness-engineering skill to update the harness before retrying.It is always OK to stop and say "this is too hard for me." Escalation is expected, not penalized.
After completing any skill session, run a 3-question self-check before writing the final status:
If any answer is NO, address it before reporting DONE. If it cannot be addressed, report DONE_WITH_CONCERNS and name the gap.
For a full performance evaluation spanning the entire sprint, use the self-improvement skill.
_TEL_END=$(date +%s)
_TEL_DUR=$(( _TEL_END - _TEL_START ))
~/.claude/skills/superomni/bin/analytics-log "SKILL_NAME" "---
name: careful
description: |
Safety guardrails that activate before high-risk operations.
Prevents destructive, irreversible, or security-sensitive changes without explicit confirmation.
Triggers: destructive operations, production configs, database migrations, security-sensitive files, "be careful", "careful mode".
allowed-tools: [Bash, Read, Write, Edit, Grep, Glob]
---
{{PREAMBLE}}
# Careful — Safety Guardrails
**Goal:** Prevent costly mistakes by enforcing risk assessment, blast radius calculation, and user confirmation before any high-risk operation.
## Iron Law
**ALWAYS CONFIRM BEFORE DESTRUCTIVE OPERATIONS.**
Never execute a destructive, irreversible, or security-sensitive operation without explicit user approval. "I assumed it was fine" is never an acceptable justification for data loss or a security incident.
## Trigger Conditions
This skill activates automatically when any of the following are detected:
### Destructive Operations
- `rm -rf`, `DROP TABLE`, `DELETE FROM` without `WHERE`
- `git push --force`, `git reset --hard`, branch deletion
- Overwriting files without backup
- Truncating logs or databases
### Production-Touching Changes
- Editing files matching `*prod*`, `*production*`, `*.env.prod*`
- Modifying deployment configs (`Dockerfile`, `docker-compose.yml`, `k8s/*.yaml`)
- Changing CI/CD pipelines (`.github/workflows/*`, `Jenkinsfile`, `.gitlab-ci.yml`)
- Updating infrastructure-as-code (`*.tf`, `*.tfvars`, `cloudformation*`)
### Security-Sensitive Files
- Anything containing secrets, keys, tokens, or credentials
- Auth/authorization logic
- Encryption configuration
- CORS or CSP policies
- `.env` files, certificate files, key stores
### Database Migrations
- Schema changes (`ALTER TABLE`, `ADD COLUMN`, `DROP COLUMN`)
- Data migrations that transform existing records
- Index changes on large tables
- Any migration that cannot be rolled back
## Phase 1: Risk Assessment
When a trigger condition is detected, STOP and assess:
⚠️ HIGH-RISK OPERATION DETECTED ───────────────────────────────── Operation: [what you're about to do] Trigger: [which trigger condition matched] Files: [files that will be affected]
Answer these questions:
1. **What could go wrong?** — list specific failure modes
2. **What is the worst-case outcome?** — data loss? downtime? security breach?
3. **Has this been done before?** — is there precedent in the project?
## Phase 2: Blast Radius Calculation
Determine how much of the system this change affects.
```bash
# For code changes: who depends on this?
grep -rl "$(basename <changed-file> | sed 's/\..*//')" . \
--include="*.js" --include="*.ts" --include="*.py" --include="*.go" \
2>/dev/null | grep -v "node_modules\|.git" | wc -l
# For config changes: what environments are affected?
grep -l "<config-key>" . -r --include="*.env*" --include="*.yaml" --include="*.json" \
2>/dev/null | head -10
# For database changes: how many rows affected?
# (estimate or query with EXPLAIN before executing)
BLAST RADIUS
─────────────────────────────────
Scope: [LOCAL/MODULE/SERVICE/GLOBAL]
Files affected: [N direct, N indirect]
Users affected: [none/some/all]
Environments: [dev/staging/production]
Estimated impact: [LOW/MEDIUM/HIGH/CRITICAL]
─────────────────────────────────
| Level | Meaning | Approval needed |
|---|---|---|
| LOCAL | Only the changed file is affected | Proceed with caution |
| MODULE | Other files in the same module are affected | Review before proceeding |
| SERVICE | Other services or APIs could be affected | User confirmation required |
| GLOBAL | Production, all users, or infrastructure affected | Explicit user approval + rollback plan |
Before proceeding, confirm the operation can be undone.
| Question | Answer |
|---|---|
Can this be reverted with git revert? | [yes/no] |
| Is there a database backup? | [yes/no/N/A] |
| Can the deployment be rolled back? | [yes/no/N/A] |
| Is there a feature flag to disable this? | [yes/no/N/A] |
| What is the recovery time if this goes wrong? | [minutes/hours/days/never] |
REVERSIBILITY
─────────────────────────────────
Reversible: [YES/PARTIAL/NO]
Rollback method: [git revert / backup restore / feature flag / manual]
Recovery time: [estimate]
Data loss risk: [NONE/POSSIBLE/CERTAIN]
─────────────────────────────────
If Reversible = NO and Blast Radius = SERVICE or GLOBAL: → STOP. Do not proceed without explicit user approval AND a mitigation plan.
Present the risk summary and wait for explicit approval.
╔══════════════════════════════════════╗
║ ⚠️ CONFIRMATION REQUIRED ║
╠══════════════════════════════════════╣
║ ║
║ Operation: [description] ║
║ Blast radius: [level] ║
║ Reversible: [yes/partial/no] ║
║ Risk: [LOW/MEDIUM/HIGH/CRIT] ║
║ ║
║ Worst case: [what could happen] ║
║ Mitigation: [how to recover] ║
║ ║
║ Proceed? (yes/no) ║
║ ║
╚══════════════════════════════════════╝
Do not proceed until the user explicitly confirms.
If the user confirms:
If the user declines:
When in doubt, apply these defaults:
| Situation | Safe default |
|---|---|
| Delete file vs. rename/move | Rename to .bak first |
| Force push vs. regular push | Regular push (fail if rejected) |
| Drop column vs. deprecate | Deprecate first, drop later |
| Edit production config | Edit staging first, verify, then production |
| Run migration | Run on dev/staging first, verify, then production |
| Overwrite file | Create backup copy first |
CAREFUL ASSESSMENT
════════════════════════════════════════
Operation: [what was requested]
Trigger: [what activated this skill]
Blast radius: [LOCAL/MODULE/SERVICE/GLOBAL]
Reversibility: [YES/PARTIAL/NO]
Risk level: [LOW/MEDIUM/HIGH/CRITICAL]
User confirmed: [yes/no/not yet]
Outcome: [executed successfully / blocked / alternative proposed]
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
════════════════════════════════════════
TEL_DUR" "OUTCOME" 2>/dev/null || true
Nothing is sent to external servers. Data is stored only in `~/.omni-skills/analytics/`.
### Plan Mode Fallback
If you have already entered Plan Mode (via `EnterPlanMode`), these rules apply:
1. **Skills take precedence over plan mode.** Treat loaded skill instructions as executable steps, not reference material. Follow them exactly — do not summarize, skip, or reorder.
2. **STOP points in skills must be respected.** Do NOT call `ExitPlanMode` prematurely to bypass a skill's STOP/gate.
3. **Safe operations in plan mode** — these are always allowed because they inform the plan, not produce code:
- Reading files, searching code, running `git log`/`git status`
- Writing to `docs/superomni/` (specs, plans, reviews)
- Writing to `~/.omni-skills/` (sessions, analytics)
4. **Route planning through vibe workflow.** Even inside plan mode, follow the pipeline: brainstorm → writing-plans → plan-review → executing-plans. Write the plan to `docs/superomni/plans/`, not to Claude's built-in plan file.
5. **ExitPlanMode timing:** Only call `ExitPlanMode` after the current skill workflow is complete and has reported a status (DONE/BLOCKED/etc).
# Careful — Safety Guardrails
**Goal:** Prevent costly mistakes by enforcing risk assessment, blast radius calculation, and user confirmation before any high-risk operation.
## Iron Law
**ALWAYS CONFIRM BEFORE DESTRUCTIVE OPERATIONS.**
Never execute a destructive, irreversible, or security-sensitive operation without explicit user approval. "I assumed it was fine" is never an acceptable justification for data loss or a security incident.
## Trigger Conditions
This skill activates automatically when any of the following are detected:
### Destructive Operations
- `rm -rf`, `DROP TABLE`, `DELETE FROM` without `WHERE`
- `git push --force`, `git reset --hard`, branch deletion
- Overwriting files without backup
- Truncating logs or databases
### Production-Touching Changes
- Editing files matching `*prod*`, `*production*`, `*.env.prod*`
- Modifying deployment configs (`Dockerfile`, `docker-compose.yml`, `k8s/*.yaml`)
- Changing CI/CD pipelines (`.github/workflows/*`, `Jenkinsfile`, `.gitlab-ci.yml`)
- Updating infrastructure-as-code (`*.tf`, `*.tfvars`, `cloudformation*`)
### Security-Sensitive Files
- Anything containing secrets, keys, tokens, or credentials
- Auth/authorization logic
- Encryption configuration
- CORS or CSP policies
- `.env` files, certificate files, key stores
### Database Migrations
- Schema changes (`ALTER TABLE`, `ADD COLUMN`, `DROP COLUMN`)
- Data migrations that transform existing records
- Index changes on large tables
- Any migration that cannot be rolled back
## Phase 1: Risk Assessment
When a trigger condition is detected, STOP and assess:
⚠️ HIGH-RISK OPERATION DETECTED ───────────────────────────────── Operation: [what you're about to do] Trigger: [which trigger condition matched] Files: [files that will be affected]
Answer these questions:
1. **What could go wrong?** — list specific failure modes
2. **What is the worst-case outcome?** — data loss? downtime? security breach?
3. **Has this been done before?** — is there precedent in the project?
## Phase 2: Blast Radius Calculation
Determine how much of the system this change affects.
```bash
# For code changes: who depends on this?
grep -rl "$(basename <changed-file> | sed 's/\..*//')" . \
--include="*.js" --include="*.ts" --include="*.py" --include="*.go" \
2>/dev/null | grep -v "node_modules\|.git" | wc -l
# For config changes: what environments are affected?
grep -l "<config-key>" . -r --include="*.env*" --include="*.yaml" --include="*.json" \
2>/dev/null | head -10
# For database changes: how many rows affected?
# (estimate or query with EXPLAIN before executing)
BLAST RADIUS
─────────────────────────────────
Scope: [LOCAL/MODULE/SERVICE/GLOBAL]
Files affected: [N direct, N indirect]
Users affected: [none/some/all]
Environments: [dev/staging/production]
Estimated impact: [LOW/MEDIUM/HIGH/CRITICAL]
─────────────────────────────────
| Level | Meaning | Approval needed |
|---|---|---|
| LOCAL | Only the changed file is affected | Proceed with caution |
| MODULE | Other files in the same module are affected | Review before proceeding |
| SERVICE | Other services or APIs could be affected | User confirmation required |
| GLOBAL | Production, all users, or infrastructure affected | Explicit user approval + rollback plan |
Before proceeding, confirm the operation can be undone.
| Question | Answer |
|---|---|
Can this be reverted with git revert? | [yes/no] |
| Is there a database backup? | [yes/no/N/A] |
| Can the deployment be rolled back? | [yes/no/N/A] |
| Is there a feature flag to disable this? | [yes/no/N/A] |
| What is the recovery time if this goes wrong? | [minutes/hours/days/never] |
REVERSIBILITY
─────────────────────────────────
Reversible: [YES/PARTIAL/NO]
Rollback method: [git revert / backup restore / feature flag / manual]
Recovery time: [estimate]
Data loss risk: [NONE/POSSIBLE/CERTAIN]
─────────────────────────────────
If Reversible = NO and Blast Radius = SERVICE or GLOBAL: → STOP. Do not proceed without explicit user approval AND a mitigation plan.
Present the risk summary and wait for explicit approval.
╔══════════════════════════════════════╗
║ ⚠️ CONFIRMATION REQUIRED ║
╠══════════════════════════════════════╣
║ ║
║ Operation: [description] ║
║ Blast radius: [level] ║
║ Reversible: [yes/partial/no] ║
║ Risk: [LOW/MEDIUM/HIGH/CRIT] ║
║ ║
║ Worst case: [what could happen] ║
║ Mitigation: [how to recover] ║
║ ║
║ Proceed? (yes/no) ║
║ ║
╚══════════════════════════════════════╝
Do not proceed until the user explicitly confirms.
If the user confirms:
If the user declines:
When in doubt, apply these defaults:
| Situation | Safe default |
|---|---|
| Delete file vs. rename/move | Rename to .bak first |
| Force push vs. regular push | Regular push (fail if rejected) |
| Drop column vs. deprecate | Deprecate first, drop later |
| Edit production config | Edit staging first, verify, then production |
| Run migration | Run on dev/staging first, verify, then production |
| Overwrite file | Create backup copy first |
CAREFUL ASSESSMENT
════════════════════════════════════════
Operation: [what was requested]
Trigger: [what activated this skill]
Blast radius: [LOCAL/MODULE/SERVICE/GLOBAL]
Reversibility: [YES/PARTIAL/NO]
Risk level: [LOW/MEDIUM/HIGH/CRITICAL]
User confirmed: [yes/no/not yet]
Outcome: [executed successfully / blocked / alternative proposed]
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
════════════════════════════════════════