| name | scope-freeze |
| description | Explicitly limit blast radius before any implementation or file changes. |
Scope Freeze
Purpose
Prevent uncontrolled changes by defining a narrow, enforceable boundary. This freezes write scope, not discovery.
When to use
Immediately before editing files or running state-changing commands.
Inputs
- SPEC.md / PLAN.md / TODO.md
- Selected task
- Current repo state
Workflow
- Name the exact task.
- List allowed files/folders.
- List read-only files/folders.
- List forbidden operations.
- Set max files/lines changed (if helpful).
- List allowed commands.
- List compatibility seams and test-integrity triggers before editing.
- Define clear stop condition.
- Note that reads/searches are allowed unless explicitly forbidden.
Outputs
Canonical output block:
SCOPE FREEZE
Task: ...
Allowed writes: ...
Read-only: ...
Forbidden: ...
Compatibility seams to preserve:
- Public imports / APIs: ...
- CLI behavior: ...
- Output schema: ...
- Fixture/data meaning: ...
- Existing tests that must remain meaningful: ...
Test integrity:
- Existing tests may be added to: yes/no
- Existing tests may be changed only if: ...
Review required if:
- tests changed
- dependencies changed
- protected paths touched
- compatibility seams changed
Allowed commands: ...
Stop when: ...
Invalid if: ...
Success looks like
The canonical block above.
Stop conditions
- Scope is narrow enough for safe implementation.
- Task requires changes outside boundary → pause and renegotiate.
Anti-patterns
- Roaming the entire repo for a small fix.
- Expanding scope because "nearby code looked easy."
- Running write commands before boundary is agreed.
- Forbidding necessary discovery reads.