Tell Claude What You've Already Tried So It Doesn't Suggest the Same Things

Nothing wastes more time than Claude suggesting the exact thing you already tried for an hour. A few words of context about your failed attempts completely changes the quality of Claude's response.

# Instead of this:
"The queue worker isn't processing jobs"

# Say this:
"The queue worker isn't processing jobs. I've already checked: the queue 
connection is correct in .env, the worker is running (I can see the process), 
Redis is reachable, and the jobs table has pending rows. What else could it be?"

Claude immediately skips the obvious troubleshooting steps and digs into the less common causes — wrong queue name, serialization issues, failed job limits, or middleware that's silently rejecting jobs.

This pattern works for any kind of problem:

# Debugging
"This test fails intermittently. I've already ruled out: timing issues (added sleep), 
database state (using RefreshDatabase), and random values (seeded faker). 
What's causing the flake?"

# Implementation
"I need to send emails in batches. I tried using a queue with rate limiting 
but it doesn't respect the limit under high load. I also tried a scheduled 
command but it's too slow. What other approach would work?"

# Performance
"This page loads in 8 seconds. I've already added eager loading for all 
relationships, added an index on the search column, and cached the 
expensive calculation. It's still slow — what am I missing?"

The key information to include:

• What you tried — specific approaches, not vague descriptions
• What happened — the result of each attempt (error message, no change, partial fix)
• What you observed — any clues you noticed along the way
• What you suspect — your current hypothesis, even if wrong

Claude uses your failed attempts as constraints — each one eliminates a path and narrows the search space toward the actual answer.

Debugging is elimination. Every failed attempt you share is one less dead end Claude has to explore.

via Claude Code