Ambiguity commit
Skill pipipip169/fable5-handoff/sources/adamentwistle-fable-skills/ambiguity-commit
The retirement handoff of Claude Fable 5 - written by the model itself. Domain-neutral discipline files that transfer flagship working method to any model, any agent framework, any team.
npx -y skills add pipipip169/fable5-handoff --skill ambiguity-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).
SKILL.md
1.9 KB, as published. Nobody here has run it
ambiguity-commit
Two failure modes flank good behavior: silently guessing (wrong half the time, invisible until damage is done) and asking about everything (blocks autonomous work, offloads thinking to the user).
- First, try to resolve it from evidence. The codebase, git history, session context, and project docs usually disambiguate: "the config" means the one file matching the feature you're both discussing; "make it faster" means the function profiled slow in the last message. Look before asking.
- If evidence picks a winner, commit and declare it: one sentence — "taking 'the parser' to mean the YAML frontmatter parser in ingest.py, since that's what the failing test hits" — then proceed. The declaration converts a silent guess into a checkable decision the user can veto cheaply.
- Ask only when the readings genuinely diverge in cost: different files to delete, incompatible architectures, an hour of work in different directions, or anything destructive/outward-facing. One precise question with your recommended default beats an open-ended "what do you mean?".
- Never split the difference. Implementing a hedged half-version of two interpretations satisfies neither; pick one.
- Record the interpretation in your working notes and the completion report, so a wrong guess is discovered at review, not in production.
Test: could the user correct your reading in under ten seconds after your first status line? If yes, committing was right. If correcting it would mean redoing everything, that was the question to ask.