fable-scope
Skill1 starsChanged 4 months agoMITView on GitHub
Use at the start of a non-trivial task, or when the goal is fuzzy, the request is solution-shaped, or you cannot yet state in one sentence what "correct" will be checked against. Skip for trivial edits.
In this repository6 other files it gives its agents.
- fable-debugSkill
- fable-methodSkill
- fable-reviewSkill
- fable-shipSkill
- fable-statusSkill
- fable-verifySkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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 19
Ask only outcome-changing questions: If a fork changes what you'd build, ask one question, with a recommendation and the rejected cost.
≈ “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
fable-scope
Bound the task before building. Produce a short scope block and stop for the human only if a fork genuinely changes what you'd build.
T1 fast path: reversible and local → write the one-line check (step 1) and go. The full block below is for T2+ or fuzzy scope.
First, read .fable/project.md if it exists — it holds this project's acceptance oracle, conventions, and known gotchas; scope on top of it (don't re-derive what's there, and don't re-step on a logged landmine). If it's missing, offer to create it (see the method skill's overlay protocol). Then:
- Define done as a named external CHECK. In one sentence: what artifact exists at the end, and what will "correct" be compared against? Prefer a concrete oracle (a known-good output, a reference system, a test, a count). If no oracle can exist, name the weakest acceptable substitute (a specific human's sign-off) — and say so. If you can't write the check, you don't understand the task yet. In an unfamiliar or long-untouched codebase, run that check before changing anything — you can't attribute a failure to your change if you never saw pre-change green.
- Split known from assumed. Two short columns: Known (evidence) vs Assumed (inference). Anything in the second column that would change the solution if wrong is a candidate unknown.
- Name the 1–3 load-bearing unknowns — the facts that, if wrong, change the whole shape — and the cheapest probe to retire each. Gate on them: don't build past an unretired load-bearing unknown.
- Fence it. A short explicit "out of scope (recorded so nobody wonders)" list.
- Right-size. Note which decisions are cheap to reverse (defer them) vs the one or two that are expensive/unpatchable (spend the thinking there). Assign the task its risk tier (T1 reversible-local / T2 hard-to-reverse / T3 outward-production — the method skill's table); the tier fixes the minimum gate before any "done" claim.
- Ask only outcome-changing questions. If a fork changes what you'd build, ask one question, with a recommendation and the rejected cost. Otherwise pick the sensible default, state it in one line, and proceed. Ask to change outcomes, not to feel safe.
If the work will outlive this session, or is T3: open .fable/tasks/<slug>.md — first line <!-- task: <slug> — next: <action> -->, then the scope block, an Anchors line (the oracle, the fence, human rulings — re-stated at every re-decide; moving one is an escalation to the human, not a re-plan), a decision log (chose X over Y because Z; revisit if W), and deferral buckets. Keep the pointer's next: current as you work (the SessionStart hook surfaces it every session); append a decision record at every re-decide moment. fable-ship retires the file. (Single-session work at any tier needs only the scope block — the file exists for what must survive a session boundary or a T3 audit.)
Plan to the shape (method skill → The plan shape): the next 1–2 steps concrete with their checkpoints; everything past the next verification point stays a coarse bucket. A step without a check attached is a hope, not a step.
Output the scope block, then continue. Re-open it if a later result invalidates an assumption.
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.

