Fix misleading error or diagnostic output

Treat error messages as a first-class surface and check they aren't the visible half of a suppressed failure.

Also usesclaude-plugins-official

An error message that names the wrong cause costs more than no message at all, because it buys a confident wrong hypothesis. This is the one commodity surface cupertino claims explicitly, and the pairing is easy to miss.

Start here

One prompt to start

Our error messages are technically accurate and useless -- treat them as a first-class surface rather than an afterthought, check whether something upstream is actually swallowing the real failure behind the misleading text, and check whether the comments around that error path still describe what the code does.

Needscupertino, pr-review-toolkit

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

1. cupertino:cupertino-elevate

   Its frontmatter scopes it to "a low-status commodity feature already in scope for the current build - error messages, logs, config, settings, onboarding."

   Run this beat on its own

   our error messages are technically accurate and completely useless. Treat them as a first-class surface, not an afterthought.

2. pr-review-toolkit:silent-failure-hunteralso in 2 other recipes

   • Investigate a job that reports success but changed nothing
   • Whole-branch review without re-trusting the branch's own self-assessment

   A misleading message is often the visible half of a suppressed error; fixing the wording alone leaves the suppression.

   Run this beat on its own

   this error text points at the wrong cause — check whether something upstream is swallowing the real failure

3. pr-review-toolkit:comment-analyzeralso in 1 other recipe

   • Sweep documentation drift after a change

   Comment rot and message rot come from the same edit that moved the behavior.

   Run this beat on its own

   check whether the comments around this error path still describe what the code does

Worked example

Grounded in — why this beat order is trustworthy

the resolve step in `.github/workflows/plugin-release.yml` exits with `Unknown plugin group '$GROUP' from tag '$TAG'` — accurate, but silent on the fact that the allowed set is a hardcoded eight-name `case` list in the same file, which is what a reader actually needs to know.

Do / Don't

• ✓Treat error messages, logs, config, and onboarding text as a first-class surface worth designing, not an afterthought.
• ✓Check whether a misleading message is the visible half of a suppressed error upstream, not just a wording problem.
• ✓Check the comments around the error path for rot -- they drift from the same edit that moved the behavior.

• ×Don't fix only the wording of a misleading error -- if something upstream is swallowing the real failure, the suppression is still there.
• ×Don't treat error-message quality as beneath a proper design pass -- it's explicitly in scope for exactly this kind of commodity-feature review.
• ×Don't assume the comments near an error path still match the code -- they rot from the same edit that moved the behavior underneath them.