Skip to main contentUse this when the cost of mistakes is high. Guardrails constrain what the assistant touches and force confirmation before risky moves.
Why it works
- Prevents collateral changes in sensitive areas.
- Creates an explicit contract: scope, rules, and approvals.
- Keeps validation front-and-center before merging.
Core patterns
- Scope lock: name the files/dirs allowed and forbid others.
- Approval gate: require restatement and consent before edits.
- Change budget: limit size (e.g., “touch max 3 files, avoid migrations”).
- Test-first: demand a test/validation plan before changes.
Prompt templates
- Scope lock: “Edit only
<files/dirs>. Do not touch anything else. If needed, ask before changing scope.”
- Pre-change checklist: “Before edits, list current behavior, intended change, files to touch, risks, and tests. Wait for approval.”
- Fragile area: “This is critical. No refactors. Make the smallest viable change. Call out any unintended diffs.”
- Rollback ready: “If things break, how do we revert? Provide a rollback plan before coding.”
Bad vs. good (safety)
- Bad: “Fix auth.”
- Good: “Fix auth in
<file>. No other files. Restate the issue, propose a minimal fix and tests, and wait for approval before edits.”
When to use
- Auth, payments, data migrations, infra scripts.
- Shared libraries or widely used components.
- End-game stages: pre-merge, pre-release, hotfixes.
