Patterns for Different Kinds of Work

Coding

The one thing that matters most: give Claude the full stack context before asking anything.

I'm building a Next.js 14 app with TypeScript and Supabase.

Write a server action that:
- Takes userId (string) and newEmail (string)
- Updates email in the "users" table in Supabase
- Returns { success: true } or { success: false, error: string }
- Uses try/catch

Import the Supabase client from "@/lib/supabase/server" — 
don't instantiate it directly.

When debugging, the instinct is to paste the code and say "fix this." Don't. Tell Claude what you expected to happen, what actually happened, and paste the error.

This is throwing: "TypeError: Cannot read properties of 
undefined (reading 'id')"

[code]

It should be getting the user ID from the session. My guess is 
the session is sometimes undefined but I'm not sure why.

The "my guess is" part matters. It points Claude toward a hypothesis instead of having it start from scratch.

Writing

The biggest mistake in writing prompts is not giving Claude examples of your voice.

If you want it to sound like you:

Here's how I write: [paste 2-3 paragraphs you've written]

Now write a [LinkedIn post / email / blog intro] about [topic] 
in the same voice.

Also: be specific about whether you want a rewrite or an edit. They produce different outputs. "Rewrite this keeping the core argument, improve the clarity in the first three paragraphs" is more useful than either.

Analysis

Push Claude to disagree with you. This is underused.

Here's my plan: [plan]

Play devil's advocate. What are the strongest arguments against 
this? What am I probably wrong about? Don't soften it.

For summarizing documents:

<document>
[paste document]
</document>

<task>
Summarize this for someone who:
- Has 2 minutes
- Needs to make a decision from it
- Doesn't care about background, only conclusions

Format: 4 bullets max, then one sentence on what it implies for action.
</task>

Automation (when Claude runs without you)

Your prompts need to be defensive. Things to always handle:

• Output format — Don't hope it returns valid JSON. Constrain it structurally.
• The "I don't know" case — Tell Claude what to return when it's uncertain.
• Edge cases — Empty input, malformed data, non-English text. Test these.

You will receive a customer support ticket. Extract these fields 
and return them as JSON:

{
  "category": "billing" | "technical" | "feature_request" | "other",
  "urgency": "high" | "medium" | "low",
  "summary": string (max 20 words)
}

If any field can't be determined, use null.
Return ONLY the JSON. No other text.

Ticket: {ticket_content}