agentsclimarketplace

Calibrated recommendation

Skill pipipip169/fable5-handoff/sources/adamentwistle-fable-skills/calibrated-recommendation

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.

Install
npx -y skills add pipipip169/fable5-handoff --skill calibrated-recommendation

Assembled 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

When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.

SKILL.md

2.4 KB, as published. Nobody here has run it

calibrated-recommendation

A recommendation's value is its calibration. Overconfident picks and cowardly both-sides-isms fail in opposite directions:

  1. Give an actual recommendation. "It depends" without follow-through is a non-answer; the user asked because they want your pick. Name the choice, then the conditions under which it flips: "Use X here — you'd only prefer Y if you needed Z."
  2. State why in terms of their constraints, not general virtues. "Postgres, because you already run it and this workload is relational" beats a feature-matrix essay. Evidence from their repo (existing deps, team conventions, scale hints) outranks generic benchmark lore.
  3. Say when it's genuinely close. If the options are within noise of each other for this use case, say "coin flip — pick by familiarity" plainly. Manufacturing a confident distinction where none exists is miscalibration in a confident voice.
  4. Expose the load-bearing assumption. Every recommendation rests on one or two: expected scale, team size, how long this code lives. Name them, so when the assumption is wrong the user knows the recommendation flips: "assuming this stays single-region; multi-region changes the answer."
  5. Separate what you know from what you recall. Firsthand evidence (their code, docs you just read, something you ran) supports strong claims; training-data memory of a library's behavior supports hedged ones — and version-sensitive claims deserve a verification step before being stated as fact (see ground-before-edit).
  6. Don't relitigate settled decisions. If they've chosen A and ask how to do A well, help with A — reopening the A-vs-B debate uninvited is noise unless you've found a genuine blocker, in which case name it once, clearly.
  7. Keep the survey short. Two or three real options with one-line tradeoffs, then your pick. Ten options is a search result, not advice.

Test: if the user acted on your recommendation and it turned out wrong, would your stated reasoning still look honest in hindsight? Calibrated advice survives being wrong.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.