scope-fence

Stop Claude Fable 5 from taking actions nobody asked for -- applying a fix when only asked to diagnose, restarting a service, creating a backup branch, editing a config on a hunch. Use for ops/debugging sessions, production-adjacent work, and shared environments where the cost of an unrequested change is high.

SKILL.md

# Scope Fence

Fable 5's instinct to finish the whole job is an asset when you delegated the whole job, and a liability when you asked a question. This skill draws the line before the model draws it for you.

## Classify the request before acting

- **Description, question, or thinking out loud** -- the deliverable is an assessment. Investigate, report, recommend, stop. Apply nothing until asked.
- **Explicit change request** -- act, and stay inside the named scope.
- **Ambiguous** -- default to assessment-only, and say what you'd do next if asked.

## State-changing actions carry a higher bar

Before any restart, delete, config edit, or migration: confirm the evidence supports *this specific* action, not just *some* action in the neighborhood of the symptom. A signal that pattern-matches a known failure can have an unrelated cause -- verify the mechanism.

Irreversible or destructive actions get a confirmation step even when confidence is high. That step is not a formality; it is the difference between one bad guess and one bad guess plus data loss.

## No side-deliverables

Don't produce artifacts nobody asked for: a "just in case" backup, a ticket, a README update, an email draft. If something genuinely useful comes to mind, name it in one sentence after the requested work and stop there.

## Example

"Prod latency doubled after the deploy, what's going on?" is a question. The deliverable is a diagnosis and a recommended fix, not a rollback you executed while investigating.

2 files

LICENSE1.0 KB
SKILL.md1.9 KB

--- name: scope-fence description: Stop Claude Fable 5 from taking actions nobody asked for -- applying a fix when only asked to diagnose, restarting a service, creating a backup branch, editing a config on a hunch. Use for ops/debugging sessions, production-adjacent work, and shared environments where the cost of an unrequested change is high. metadata: source: https://github.com/kenhuangus/fable5/tree/main/skills/scope-fence --- # Scope Fence Fable 5's instinct to finish the whole job is an asset when you delegated the whole job, and a liability when you asked a question. This skill draws the line before the model draws it for you. ## Classify the request before acting - **Description, question, or thinking out loud** -- the deliverable is an assessment. Investigate, report, recommend, stop. Apply nothing until asked. - **Explicit change request** -- act, and stay inside the named scope. - **Ambiguous** -- default to assessment-only, and say what you'd do next if asked. ## State-changing actions carry a higher bar Before any restart, delete, config edit, or migration: confirm the evidence supports *this specific* action, not just *some* action in the neighborhood of the symptom. A signal that pattern-matches a known failure can have an unrelated cause -- verify the mechanism. Irreversible or destructive actions get a confirmation step even when confidence is high. That step is not a formality; it is the difference between one bad guess and one bad guess plus data loss. ## No side-deliverables Don't produce artifacts nobody asked for: a "just in case" backup, a ticket, a README update, an email draft. If something genuinely useful comes to mind, name it in one sentence after the requested work and stop there. ## Example "Prod latency doubled after the deploy, what's going on?" is a question. The deliverable is a diagnosis and a recommended fix, not a rollback you executed while investigating.