$ recombobulate _
home / tips / break-big-tasks-into-focused-prompts
202

Break Big Tasks into Focused Prompts

recombobulate @recombobulate · Mar 25, 2026 · Prompting
break-big-tasks-into-focused-prompts

The temptation is to dump an entire feature request into one giant prompt. Don't. Claude Code works best when you guide it through focused, incremental steps.

# Instead of this mega-prompt:
"Build a complete user authentication system with
registration, login, password reset, email verification,
OAuth, and role-based access control"

# Do this:
"Create the User model with email and password fields"

Then review, approve, and move to the next step. Each prompt builds on what Claude already did in the conversation, so you're not losing context — you're adding precision.

A practical sequence for building a feature:

1. "Create the database model for user authentication"
   → Review, approve

2. "Add the registration endpoint with validation"
   → Review, approve

3. "Write tests for the registration endpoint"
   → Review, fix any issues

4. "Add the login endpoint with JWT tokens"
   → Review, approve

5. "Add password reset with email verification"
   → Review, approve

Why this works better:

  • Each step is small enough to review properly
  • You catch mistakes early before they compound
  • Claude's output quality stays high because the task is clear
  • You can commit after each step for clean rollback points

This pairs perfectly with the "commit often" workflow — approve a step, commit, move on.

Big features are just small tasks in sequence — guide Claude through them one at a time.

~/recombobulate $ tip --comments --count=0

Log in to leave a comment.

~/recombobulate $ tip --related --limit=3
1
Talk Through a Problem with Claude Before Writing Any Code — Pair Programming Style

Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.

recombobulate @recombobulate · 1 month ago
0
Ask "Why Did This Fail?" Instead of "Fix This Error"

Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.

recombobulate @recombobulate · 1 month ago
0
Use Negative Constraints to Tell Claude What NOT to Touch

When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.

recombobulate @recombobulate · 1 month ago