Advanced Prompting

Advanced Prompting Patterns

Quick Start

Use these when Claude's first response feels safe/generic:

1. Challenge - "Grill me on these changes" 2. Verify - "Prove to me this works" 3. Reset - "Scrap this and implement the elegant solution"

Pattern Categories

Challenge Prompts

Force Claude to critique rather than accept:

• "Grill me on these changes" - Get pushback on your approach
• "What would a 10x engineer do differently" - Surface better patterns
• "Find 3 ways this could fail" - Adversarial review

Verification Prompts

Demand evidence over assertions:

• "Prove to me this works" - Request test output, diffs
• "Show me the before/after" - Force concrete comparison
• "Walk through this line by line" - Prevent hand-waving

Reset Prompts

Break out of local optima:

• "Scrap this and implement the elegant solution" - Fresh approach
• "You're overcomplicating this" - Simplification pressure
• "What's the 80/20 version" - Cut scope ruthlessly

When to Use

Anti-Patterns

• Don't use reset prompts mid-implementation (waste tokens)
• Challenge prompts need context (share the code first)
• Verification prompts pointless for trivial changes

References

• challenge-prompts.md - Critique and adversarial review
• verification-prompts.md - Evidence and proof patterns
• reset-prompts.md - Fresh starts and simplification

Challenge Prompts

Force Claude out of agreement mode into critical analysis.

Core Prompts

"Grill me on these changes"

Triggers adversarial code review. Claude will:

• Question architectural decisions
• Point out edge cases you missed
• Challenge naming/abstraction choices

Example exchange:

User: [shares PR diff] Grill me on these changes

Claude: Three concerns:
1. This mutex pattern won't survive concurrent writes - line 47 releases before the callback
2. Why a custom retry loop when you have `p-retry` in package.json?
3. `processData` does 4 things - extract the validation into its own function

"What would a 10x engineer do differently"

Surfaces patterns you might not know:

• Better stdlib/library usage
• Idiomatic approaches for the language
• Performance patterns

Example exchange:

User: [shares function] What would a 10x engineer do differently

Claude: Three changes:
1. Replace the loop with `Object.fromEntries(arr.map(x => [x.id, x]))`
2. This is a textbook case for memoization - add `useMemo` around line 23
3. The early returns are good but consider guard clauses at function entry

"Find 3 ways this could fail"

Adversarial testing mindset:

• Race conditions
• Edge cases (empty, null, huge)
• External dependency failures

Example exchange:

User: [shares API handler] Find 3 ways this could fail

Claude:
1. No timeout on the fetch - hangs forever if upstream is slow
2. `user.email` accessed without null check after line 12's early return
3. Rate limit response (429) treated as success - will corrupt cache

Combining Patterns

Chain for thorough review:

1. "Grill me on these changes"
2. [address feedback]
3. "Find 3 ways this could still fail"
4. [address feedback]
5. "What would a 10x engineer do differently"

When NOT to Use

• Trivial changes (config updates, typo fixes)
• When you need encouragement, not critique
• Time-sensitive fixes (challenge after shipping)

Reset Prompts

Break out of local optima. Force fresh thinking.

Core Prompts

"Scrap this and implement the elegant solution"

Abandons sunk cost, starts fresh:

• Forget current approach entirely
• Consider the problem from scratch
• Often finds 10x simpler solution

Example exchange:

```` User: [after 3 iterations of patching] Scrap this and implement the elegant solution

Claude: Looking at the actual requirement - you need rate limiting per user.

Delete all of this. Use express-rate-limit with a custom keyGenerator:

const limiter = rateLimit({
  windowMs: 60_000,
  max: 100,
  keyGenerator: (req) => req.user?.id ?? req.ip
});
app.use('/api', limiter);

That's it. No custom middleware, no Redis complexity, no cleanup jobs.

### "You're overcomplicating this"

Direct simplification pressure:
- Removes unnecessary abstractions
- Cuts features to core need
- Questions each moving part

**Example exchange:**

User: You're overcomplicating this

Claude: You're right. Stripped down version:

• Removed the factory pattern (you have one implementation)
• Removed the event emitter (you only need the callback)
• Removed the retry logic (let the caller handle it)

From 145 lines to 23 lines. Same behavior.

### "What's the 80/20 version"

Ruthless scope cutting:
- What 20% delivers 80% of value
- Defer complexity to later
- Ship something now

**Example exchange:**

User: What's the 80/20 version

Claude: Drop these for v1:

• Custom themes (ship with one good default)
• CSV export (users can copy-paste from table)
• Batch operations (they can do one at a time)

This cuts 70% of the code and you ship this week instead of next month.

## Reset Signals

Use reset prompts when:
- You've iterated 3+ times on same code
- The solution keeps growing in complexity
- You feel like you're fighting the code
- Claude is patching patches

## Timing Matters

**Good timing:**
- Before implementation (during design)
- After first attempt fails
- When requirements change

**Bad timing:**
- Mid-implementation (wastes tokens)
- Near completion (sunk cost is real)
- When current approach is working

## Combining Resets

1. "Scrap this and implement the elegant solution" 2. [review new approach] 3. "What's the 80/20 version of this" 4. [implement stripped version] 5. "Prove to me this works"

## The Nuclear Option

When truly stuck:

Forget everything we've discussed. I need [core requirement]. What's the simplest possible implementation?

This resets Claude's context bias toward previous approaches.

Verification Prompts

Demand evidence over assertions. Prevent hand-waving.

Core Prompts

"Prove to me this works"

Forces Claude to demonstrate, not claim:

• Run tests and show output
• Show diffs with before/after
• Execute and capture results

Example exchange:

User: Prove to me this works

Claude: Running the test suite:
$ npm test -- --grep "auth"
✓ redirects unauthenticated users (23ms)
✓ preserves return URL in redirect (18ms)
✓ handles expired tokens (31ms)

Here's the actual diff in behavior:
Before: 401 response, no redirect
After: 302 to /login?return=/dashboard

"Show me the before/after"

Concrete comparison prevents vague claims:

• Code diffs
• Output diffs
• Behavior differences

Example exchange:

```` User: Show me the before/after

Claude: Before (line 45-52):

const data = await fetch(url);
const json = await data.json();
return json;

After:

const data = await fetch(url, {
  signal: AbortSignal.timeout(5000),
});
if (!data.ok) throw new HttpError(data.status);
return data.json();

Behavior change: Timeout after 5s instead of hanging. Non-2xx now throws.

### "Walk through this line by line"

Prevents skipped complexity:
- Forces explanation of each step
- Exposes assumptions
- Catches logic errors

**Example exchange:**

User: Walk through this line by line

Claude:

• L1: const cache = new Map() - In-memory cache, cleared on restart
• L2: const TTL = 60_000 - 60 second expiry, might be too short for your use case
• L3: function get(key) - Synchronous lookup, blocks if slow
• L4: const entry = cache.get(key) - Returns undefined if missing
• L5: if (!entry) return null - Caller must handle null, not undefined
• L6: if (Date.now() > entry.exp) - Clock skew could cause issues

## Verification Triggers

Use when Claude says:
- "This should work" → "Prove it"
- "This handles edge cases" → "Show me which ones"
- "This is more efficient" → "Show me the benchmark"
- "This fixes the bug" → "Show me before/after"

## Combining with Tests

User: Prove to me this works

Claude: I'll add a test and run it: [writes test] [runs test] [shows passing output]

The existing tests also pass: [shows test output]

## Anti-Pattern: Premature Verification

Don't demand proof for:
- Obvious changes (renaming, formatting)
- Standard library usage
- Changes you can verify yourself in 10 seconds