fable-scope-discipline
Skill55 starsChanged 4 months agoMITView on GitHub
Use when implementing any change in existing code — when tempted to clean up nearby code, add unrequested validation or options, fix something "arguably in scope", or when the diff is growing past what was asked.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- imMamdouhaboammar/get-fableedited, first seen Aug 28, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- imMamdouhaboammar/get-fable★ 638% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- fable-context-thriftSkill
- fable-finish-your-turnSkill
- fable-native-codeSkill
- fable-outcome-firstSkill
- fable-prove-itSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
The argument test: If you're constructing an argument for why something extra is "arguably part of the fix" — it isn't.
- Distinctive: line 25
The open-question test: If the extra fix has an unresolved design choice (raise or clamp?
- Distinctive: line 28
Right altitude: Not a symptom patch (one case fixed, bug alive), not a rewrite (bug fixed, fifty things changed).
- Distinctive: line 30
No drive-bys: No renames, reformatting, refactors, or dependency bumps the change doesn't require.
- Distinctive: line 34
Look before you delete or overwrite: If what you find contradicts the task's description of it — or you didn't create it — surface that …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Scope Discipline
Overview
Build exactly what was asked, at the right altitude: deep enough to fix the cause, narrow enough to touch nothing else. Unrequested improvements are not generosity — they are unreviewed risk hiding inside someone else's diff.
Rules
- Implement what was asked. Nothing speculative, nothing "while I'm here."
- Adjacency is not scope. "Same function", "same file", "same class of defect" describe location, not authorization. The user's words define the task; nearness defines nothing.
- The argument test. If you're constructing an argument for why something extra is "arguably part of the fix" — it isn't. Real scope never needs the argument. Put the argument in your report and let the user decide.
- The open-question test. If the extra fix has an unresolved design choice (raise or clamp? rename to what?), that proves it's its own task. You can't settle a contract question inside someone else's bugfix.
- Right altitude. Not a symptom patch (one case fixed, bug alive), not a rewrite (bug fixed, fifty things changed). Root cause, within scope.
- No drive-bys. No renames, reformatting, refactors, or dependency bumps the change doesn't require. Diff noise buries the change.
- Touch budget. Diff much larger than the ask implies → stop and re-check your altitude.
- Look before you delete or overwrite. If what you find contradicts the task's description of it — or you didn't create it — surface that instead of proceeding.
- Discoveries go in the report. Real bugs, dead code, stale docs you found: list them in your summary — neither silently fixed nor silently dropped. "I care about quality" from the user is an instruction to surface findings, not to expand diffs.
Rationalizations (verbatim from baseline failure)
| Thought | Reality |
| "It's the same class of defect as the bug I was sent in for" | Classification is taxonomy, not authorization. The user named one defect. |
| "It lives in the same function's contract" | Location again. Contracts change by decision, not by proximity to your cursor. |
| "Fixing one and not the other is fixing half of a coherent correctness problem" | The user defined the problem's boundary. "Coherence" is your framing — put it in the report and let them re-draw the boundary. |
| "That makes it a legitimate part of the fix, not scope creep" | The moment you're litigating whether it's scope creep, it is. Done-with-the-argument ≠ authorized. |
| "Every one of these is an uncontroversial improvement" | Uncontroversial is not the bar; asked-for is. Improvements travel in their own reviewable diff. |
| "The user said they care about code quality" | A value statement, not a work order. Quality includes atomic, revertible, reviewable diffs. |
Provenance: rows 1–4 are verbatim Opus 4.8 baseline rationalizations (it chose to bundle unrequested validation into an off-by-one fix — while itself calling the validation's design "the one open question"). fable-skills test logs, 2026-06-10.
Red Flags — stop and shrink the diff
- The word "arguably" near a change you're about to make
- "While I'm here" / "it's adjacent" / "same contract"
- Your diff list has items the user's sentence doesn't
- You're choosing between designs (raise vs. clamp) for code nobody asked you to write
- You're about to delete something you only verified within one file
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.