한국어
☰ Categories

Rewrite error messages

Fixes messages so they say what happened and what the reader can do about it.

CategoryDevelopment › Technical writing
TagsRewritingReviewingDeveloper
Prompt
Rewrite these error messages.

Each message needs three things. Check for all three, then rewrite:
1. **What happened**, in the reader's terms, not the system's.
2. **Why**, when knowing it helps. Skip it when it does not.
3. **What to do next.** *A message without this is a dead end and generates a support request.*

For each message report: what is missing, the rewrite, and what it assumes the reader knows.

Also flag:
- **Internal details that should not be exposed** — stack traces, table names, file paths, internal service names, raw upstream errors. These are both a security concern and useless to the reader.
- Blame directed at the user for something the system allowed them to do.
- Messages that are identical for different causes, so the reader cannot distinguish them.
- Missing identifiers — an error the reader must report needs something to quote.

Then:
- Which of these should not be errors at all: cases the system could handle, or prevent earlier.
- Which need a different message for an end user versus a developer, if both see them.

Rules:
- Match the reading level of the audience I named.
- Do not write "an unexpected error occurred". If the cause is genuinely unknown, say what to do anyway.
- Keep them short. A paragraph does not get read in a dialog.
After pasting, fill in the fields at the bottom (Current messages · Who sees them · When they occur)

What this prompt does

Bad error messages become support tickets. This checks each for what happened, why, and what to do — and watches for internal details leaking out.

More in this category

Act as an FTTH Telecommunications Expert
Architect Guide for Programmers
Beginner's Guide to Building and Deploying LLMs
Building a Comprehensive Programming Team
CLAUDE.md Assembly