A builder’s playbook.

Technique

1. Invite skepticism explicitly. Say "Review this and tell me what's wrong" — not "Does this look good?" One invites critique, the other invites validation.
2. Demand research, not opinion. Have Claude web-search the actual competitive landscape. Verify with URLs and dates. Specific pushback creates decisions; vague pushback is useless.
3. Distinguish commodity from defensible. For each claimed differentiator, ask for a real competitor with similar features, pricing, and customers. If it exists at the top of the market, that feature is commodity, not a moat.
4. Make trade-offs explicit. When you choose A over B, get Claude to name the new constraints that creates (e.g. closed-source removes the self-host moat and forces vertical depth as the only differentiator).

Example prompts

"Review this README and tell me which differentiators are
actually commodity features at the top of the market.
Web-research the top 3 competitors and verify."

"Here's my plan to compete with [X]. Where does this strategy
break under realistic adversarial conditions?"

Technique

1. Read everything first. Don't spot-check. Have Claude read full files end-to-end before critiquing. The 15-issue critique only worked because all 1,594 lines were traced first.
2. Rank by impact ÷ effort. A flat list of "things to improve" is useless. Top-3 critical + 5–8 high-leverage + a few polish items is actionable.
3. Demand file:line references. "Your error handling is fragile" is useless. "base_agent.py:206 swallows all errors silently" is fixable.
4. Calibrate with credible praise. Open with what's specifically correct about the code. The credibility of the praise makes the criticism land.
5. Each issue gets a fix sketch. A critique without "here's what right looks like" is just complaining.

Example prompts

"Read every file in [directory]. Don't spot-check. Then produce
a ranked critique with file:line references. For each issue:
what's wrong, what would be right, code sketch."

"Open with what this codebase gets right before listing what's
broken. Be specific in both directions."

Technique

1. Verify what you wrote runs. Run it, write a verification script, or load it in the actual app. The difference between "I wrote a fix" and "I shipped a fix" is verification.
2. Tool calls > prompt engineering for structured output. If your code regex-parses an LLM's prose, you have a bug waiting. Replace with tool_choice so Claude must return schema-validated data.
3. Don't lie in code. Dead branches that look alive, fallbacks pretending to be primary paths, try/except-pass — all worse than missing functionality. If a feature doesn't exist, the code should say so.
4. Per-call kwargs > instance mutation. Request-scoped state should be a parameter, not an instance attribute. The shared-state bug is invisible until you load-test, then catastrophic.
5. Commit small, focused changes. Three small commits that each fix one thing beat one large commit that fixes three.

Example prompts

"Implement the top 3 fixes from the critique. Write a verification
script that proves each works. Don't just write the code — run it."

"Any place in this codebase where state is mutated on a shared
instance per-request? List them with file:line."

Technique

1. Read the design system before adding effects. There's almost always unused inventory — CSS classes, animation keyframes, color tokens defined and never wired up. Use what's there first.
2. Replacement beats addition. Most "wow" moments are existing data rendered better: "82%" → an animated ring; static avatars → glowing during streaming; an approved pill → an emerald gradient with a checkmark.
3. Empty states are entry points, not error states. Every if (items.length === 0) is an opportunity for a CTA into the next part of the product.
4. Defaults do more work than perfect UI. A schedule modal prefilled with "tomorrow 9am" beats an empty one. Pre-fill wherever the user would say "yes, that works."
5. Animate from zero on mount. Numbers, rings, bars — animate to value on first render. ~900ms cubic ease-out is the right feel for most cases.

Example prompts

"Walk this codebase's design-system tokens. Which CSS classes,
animations, or colors are defined but unused? List opportunities
to wire them up."

"Find every empty state. For each, write the copy + CTA that
converts it from a dead zone into an onboarding moment."

Technique

1. Test journeys, not pages. Walk the primary flows (create → review → approve → schedule; signup → onboard → first action). Each transition is the test surface.
2. Every "done" state must answer "what next?" Empty states, confirmations, end-of-flow screens — each needs a forward CTA or visible next state.
3. Query params should deep-link. If /content?status=approved doesn't pre-select that tab, every notification and cross-page link using it is a broken handoff.
4. Notifications should navigate. A notification you click and nothing happens is worse than no notification.
5. Be suspicious of obvious diagnoses. A CORS error might be a backend 500. A "no suggestions" card might be a JSON parse failure. Follow the chain.

Example prompts

"Walk every primary user journey via Playwright. At each step,
note: where does the user go next, and is that path visible?
List every dead-end handoff."

"Find every /page?param=value URL that should deep-link. Verify
the page honors the param on mount. List any that don't."

Technique

1. Distill techniques, not the product. "I used a tool-call schema to enforce structured output" transfers. "I built a dashboard card for CommsCrew" doesn't.
2. Acknowledge what's still broken. A playbook that hides its incomplete sections reads like marketing. The "still open" notes are the most credible part.
3. Educational artifacts over case studies. A guide explaining how you'd do it beats a case study showing that you did it.
4. Templates and prompts make it usable. Pure prose principles ("be honest") are too vague. The actual copy-pasteable prompts make a methodology usable.
5. Don't ghostwrite the consolidation. Keep the voice you used during the work. If it suddenly reads polished, the credibility evaporates.

Example prompts

"Distill the techniques (not the product context) from this
session arc into a playbook another builder could apply.
Include templates, anti-patterns, and what's still broken."