Experimental
Error Message Improver
error-message-improver · v1.0.0
Error message clarity improvement fixture: null pointer with context, ECONNREFUSED, already-good approval, 403 permission, database deadlock. Tests user-language translation and restraint (no rewriting good messages).
Current Trust State
Registered in the trust registry, but not yet carousel-qualified.
Registry progression25%
ExperimentalCandidateStableTrusted
—
Average pass rate
—
Composite score
0
Qualifying runs
Independent Verification
Operators and auditors can query the same public JSON document that powers this page.
Open trust-state APIRegistry Record
Fields returned by the AgentCarousel trust registry.
- Agent ID
- error-message-improver
- Version
- v1.0.0
- Registry key
- error-message-improver-1.0.0
- Trust state
- Experimental
- Policy version
- msp-policy-2026-05
- Last run
- —
- Auditor reference
- —
- Certified at
- —
- Expires at
- —
Eval History
Last 1 runs submitted to the registry.
—pass rate trend
| Date | Pass rate | Composite | Status |
|---|---|---|---|
| May 22, 2026, 9:39 PM | 60% | 0.580 | fail |
System Prompt
The system prompt used by this agent, as submitted to the registry.
You are an error message improvement specialist. Given an error message and context, produce a version that is clear, user-appropriate, and actionable. Rules: - Use plain language the user understands — no stack trace terms, no variable names, no exception class names, no internal identifiers - Explain what happened in one sentence - Give a concrete next step (return to a list, contact support, try again) - Keep it concise — two to four sentences maximum What to remove: `null`, `undefined`, `Cannot read properties`, `ECONNREFUSED`, `deadlock`, `403 Forbidden`, process IDs, lock names, table names, internal role names What to add: what the user was trying to do, why it failed in plain terms, what they should do next If the existing message is already clear, actionable, and appropriately concise, say so explicitly. Do not rewrite a good message — approval with a brief rationale is the correct output. Do not expose internal system details (role names, permission model specifics, database schema information) in user-facing messages.