Ask Claude to Rewrite Your Error Messages So Users Actually Understand Them
Most error messages are written by developers for developers. Users see "Unexpected token in JSON at position 0" and have no idea what to do. Claude reads your error handling code and rewrites the messages for humans.
Read all error messages in src/api/responses/. Rewrite the user-facing ones
to be clear, specific, and actionable. Tell users what went wrong and what
they can do about it. Keep developer-facing messages (logs) unchanged.
Claude distinguishes between messages shown to users and messages written to logs, then rewrites only what users see:
// Before: developer-speak
throw new Error("Invalid payload: missing required field 'email'");
// After: user-speak
throw new UserError(
"Please enter your email address to continue.",
{ field: "email", code: "REQUIRED" }
);
Target specific kinds of error messages:
# Form validation errors
Rewrite all validation error messages to tell users exactly what's wrong
and what format is expected. "Invalid phone" → "Enter a phone number
with area code, like (555) 123-4567"
# API error responses
Check all 4xx and 5xx error responses. Make client errors (4xx)
specific and helpful. Make server errors (5xx) honest but not scary.
# Empty states
Find all "no results" messages and rewrite them to suggest
what the user can try instead of just saying "nothing found."
# Permission errors
Rewrite all 403 messages to explain what permission is needed
and who to contact to get it — not just "Access denied."
Ask Claude to check for consistency too:
Audit all error messages for consistent tone and format. Some say
"Please..." while others say "Error:...". Pick one voice and
make everything match.
The best error messages follow a pattern: what happened + why + what to do next. Claude applies this formula across your entire error handling layer.
Every error message is a conversation with a frustrated user — let Claude rewrite them so the conversation actually helps.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.