agentsclimarketplace

Error message quality

Skill pipipip169/fable5-handoff/sources/adamentwistle-fable-skills/error-message-quality

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 error-message-quality

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

Write errors and log lines that name the failing thing, the offending value, and the likely fix — for the 3am reader. Use whenever writing a throw/raise, a log statement, a validation message, or a CLI/API error response.

SKILL.md

2.1 KB, as published. Nobody here has run it

error-message-quality

Every error message is read at the worst possible moment by someone with no context. Write for that reader:

  1. Three parts: what failed, with what value, what to do. "config error: 'timeout' must be a positive integer, got '-5' in deploy.yaml" beats "invalid config" by an hour of someone's debugging. Include the identifiers: which file, which record ID, which endpoint, which of the twelve retries.
  2. Never swallow the cause. When catching and re-raising or wrapping, chain the original (raise X from e, %w, cause); when logging-and-continuing, log the exception with stack, not just "error occurred". An except-pass block is a crime scene with the evidence removed.
  3. Match the failure to the audience: user-facing messages say what the user can do ("file too large, max 10MB") and never leak internals (paths, SQL, stack traces — see security-reflex); operator-facing logs get the internals precisely so operators don't have to reproduce.
  4. Make messages greppable: stable phrasing with the variable parts as values ("payment declined: code=%s order=%s"), so the on-call can search logs and code for the same string. Don't dynamically assemble the constant part.
  5. Log at the decision points you'd want during the outage: the request that entered, the branch taken, the external call and its outcome. If a bug just cost you an hour because nothing logged the crucial value, add the log line that would have saved you — that's the cheapest reliability work there is.
  6. Right level: errors are actionable problems; warnings are tomorrow's errors; info is narrative. Logging expected conditions as errors trains everyone to ignore errors.

Test: with only this message and no source access, could someone tell what to look at first? If not, it's missing a part.

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.