After building a feature, you're too close to it. You know how it works, so you don't see what's broken. This technique forces a fresh-eyes product review that catches real problems — not style nits, but UX dead-ends, performance bugs, and logic errors.

How it was discovered: After building a full feature (10 commits, 16 new files), this prompt found 6 real issues in one pass — a useState performance bug causing double renders, copy buttons that copied the wrong content, decorative elements that looked interactive but did nothing, and missing data in UI components. All were fixable in under an hour.

The prompt

Use deep thinking to evaluate what was done so far. Put on your sharpest product-review hat — think like a senior engineer doing a real code review, not a polite one. Look at every component, every interaction, every edge case.

For each problem found, provide:

1. **What's wrong** — the specific issue
2. **Why it matters** — impact on users or developers
3. **How to fix it** — concrete change, not vague advice
4. **Severity** — critical (broken), moderate (degraded UX), minor (polish)

Focus on:
- UX dead-ends (elements that look interactive but aren't)
- Performance bugs (unnecessary re-renders, leaked listeners, missing cleanup)
- Copy/content errors (wrong labels, raw IDs shown to users)
- Missing features that the existing UI implies should exist
- Accessibility gaps

Do NOT flag:
- Style preferences or formatting
- Missing features that aren't implied by the current UI
- Hypothetical future problems

When to use it

• After completing a feature branch, before opening a PR
• After a large refactor — catches things tests don't cover
• When you feel "done" but want a sanity check
• During self-review when no other reviewer is available

Why it works

The key ingredients:

1. "Deep thinking" — triggers extended reasoning, not surface-level scanning
2. "Not a polite one" — overrides the default tendency to praise before criticizing
3. Concrete output format — forces actionable findings, not vague observations
4. Explicit focus areas — directs attention to the categories where LLMs actually find real bugs (UX interactions, state management, DOM manipulation)
5. Explicit exclusions — prevents the review from drowning in style nits and speculative concerns

Tips

• Run this on your actual codebase, not a paste of individual files. Claude Code can read your components, see how they connect, and find issues that span multiple files.
• If the first pass is too polite, follow up with: "Now find the problems you were too polite to mention the first time."
• After fixing the issues found, run the prompt again. The second pass often catches things exposed by the first round of fixes.