Rewrite error messages
Fixes messages so they say what happened and what the reader can do about it.
| Category | Development › Technical writing |
|---|---|
| Tags | RewritingReviewingDeveloper |
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 |