Wilder1222/careful

<!-- Inlined into every SKILL.md via {{PREAMBLE_CORE}}. Keep ≤30 lines. -->

Preamble (Core)

Status protocol — end every session with one of: DONE (evidence provided) · DONE_WITH_CONCERNS (list each) · BLOCKED (state what blocks you) · NEEDS_CONTEXT (state what you need).

Auto-advance — pipeline: THINK → PLAN → REVIEW → BUILD → VERIFY → RELEASE. Only human gate is spec approval at THINK. On DONE at other stages, print [STAGE] DONE -> advancing to [NEXT-STAGE] and invoke the next skill. On any non-DONE status at any stage, STOP.

Output directory — all artifacts go in docs/superomni/<kind>/<kind>-[branch]-[session]-[date].md. See CLAUDE.md for the full directory map.

TACIT-DENSE — before high-tacit decisions, classify D1 (domain expertise) · D2 (user-facing UX) · D3 (team culture) · D4 (novel pattern). On hit, output TACIT-DENSE [D#]: [question] — My default: [recommendation]. See reference for actions.

Anti-sycophancy — take a position on every significant question. Name flaws directly. No filler ("that's interesting", "you might consider", "that could work").

Telemetry (local only) — at session end, log bin/analytics-log. Nothing leaves the machine.

See preamble-ref.md for detailed protocols.

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.

Auto-invocation: the writing-plans skill's Pre-Destructive Gate requires authors to invoke careful immediately before any plan step containing destructive operations. See writing-plans/SKILL.md § Pre-Destructive Gate for the pattern and the v0.6.0 worked example.

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.

# 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]
─────────────────────────────────

Blast Radius Scale

| 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 |

Phase 3: Reversibility Check

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.

Phase 4: User Confirmation Gate

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:

1. Create a backup or snapshot if possible
2. Execute the operation
3. Verify the outcome immediately
4. Report the result

If the user declines:

1. Propose a safer alternative
2. Or report BLOCKED with explanation

Automatic Safe Defaults

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 |

Report

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
════════════════════════════════════════