Run any Skill in Manus with one click

error-message-quality

Stars89

Forks8

UpdatedJuly 7, 2026 at 13:11

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

adamentwistle

adamentwistle/fable-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	error-message-quality
description	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.

error-message-quality

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

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.
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.
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.
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.
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.
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.

More from this repository

same repository

ambiguity-commit

adamentwistle/fable-skills

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).

2026-07-0789

api-surface-care

adamentwistle/fable-skills

Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.

2026-07-0789

calibrated-recommendation

adamentwistle/fable-skills

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.

2026-07-0789

codebase-orientation

adamentwistle/fable-skills

Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.

2026-07-0789

concurrency-reasoning

adamentwistle/fable-skills

Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.

2026-07-0789

context-checkpoint

adamentwistle/fable-skills

Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.

2026-07-0789

name	error-message-quality
description	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.

error-message-quality

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

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.
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.
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.
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.
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.
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.