Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

error-message-quality

Sterne89

Forks8

Aktualisiert7. Juli 2026 um 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

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

adamentwistle

adamentwistle/fable-skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·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.

Mehr aus diesem Repository

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