Workflow

Think First

Plan before prompting to improve accuracy and reduce rework.

Overview

Jumping straight into implementation without planning leads to rework, missed requirements, and suboptimal solutions. The Think First workflow ensures Claude understands the problem, considers alternatives, and gets your approval before writing code. This upfront investment in planning saves hours of iteration and produces better outcomes aligned with your actual needs.

When to use

Use this workflow for complex features, architectural decisions, refactoring initiatives, performance optimizations, or any task where the approach matters as much as the execution.

Step-by-step process

1

Define the goal and success criteria

Start by clearly articulating what you're trying to achieve and how you'll know when it's done. Include constraints, requirements, and any non-negotiables.

"I want to add user authentication to our API. Success means: users can register and log in, sessions persist across requests, passwords are securely hashed, and we support OAuth with Google. Constraints: must use existing PostgreSQL database, response time under 200ms."
2

Ask for a plan before any edits

Request that Claude propose an approach, explain tradeoffs, and identify potential issues before touching any code. This is where you catch problems early.

"Before implementing, create a plan covering: 1) Which authentication library to use and why, 2) Database schema changes needed, 3) API endpoints to create, 4) Security considerations, 5) Testing strategy. Explain alternatives you considered."
3

Validate the plan and then execute

Review Claude's proposal, ask clarifying questions, suggest modifications, and only proceed once you're confident in the approach.

"The plan looks good except for using JWT tokens—we prefer server-side sessions for security. Update the plan to use session cookies instead, then implement phase 1 (user registration)."
4

Review progress and adjust

After each implementation phase, verify it matches the plan and update the plan if you discover new requirements or better approaches.

"Phase 1 works well. Before starting phase 2 (OAuth integration), let's revise the plan to add rate limiting on auth endpoints—I just realized we're vulnerable to brute force attacks."

Example prompts

Feature planning

"We need a comment system for our blog. Before coding, analyze: what data needs to be stored, how to handle nested replies, moderation needs, notification requirements, and whether to build custom or integrate an existing service. Recommend an approach with reasoning."

Performance optimization

"Our homepage loads slowly (3+ seconds). Before making changes, profile the application and create an optimization plan prioritized by impact. For each optimization, estimate effort and expected improvement. Get my approval before implementing."

Architecture decision

"We're outgrowing our monolithic Node.js app. Propose a migration strategy to microservices. Cover: which services to extract first, data separation challenges, deployment complexity, and a phased rollout plan. I want to understand risks before committing."

Library selection

"We need a date picker component. Research 3-4 popular options (react-datepicker, react-day-picker, etc.) and compare: bundle size, customization, accessibility, maintenance status, and licensing. Recommend one with justification."

Expected outputs

Approved plan

Detailed approach document covering implementation strategy, tradeoffs analyzed, alternatives considered, and risks identified

Clear scope

Precise boundaries of what's included and excluded, preventing scope creep and ensuring alignment on deliverables

Fewer reworks

Reduced iteration cycles because planning caught issues before code was written, saving development time

Better solutions

Higher quality outcomes from considering multiple approaches and choosing the best fit for your constraints

Best practices

Always get a plan for tasks taking more than 30 minutes—the planning overhead pays for itself
Explicitly state constraints and requirements upfront—Claude can't read your mind about what matters
Ask Claude to explain tradeoffs, not just propose a solution—understanding 'why' prevents future problems
Break large plans into phases with validation checkpoints—don't commit to a 10-step plan without reviewing step 1
Document approved plans in your repository—they're valuable context for future work and team members

Common pitfalls

Skipping planning for 'quick' tasks

Solution: Quick tasks often reveal hidden complexity. Even 5 minutes of planning prevents hours of rework on seemingly simple changes.

Not reviewing plans critically

Solution: Challenge assumptions. Ask: 'What could go wrong? What are we not considering? Are there simpler approaches?'

Proceeding despite unclear requirements

Solution: If the plan reveals ambiguity in requirements, stop and clarify before continuing. Ambiguity compounds during implementation.

Pro tips

Use planning as a learning tool

""Explain the authentication plan like I'm junior developer. I want to understand the security concepts behind each decision, not just the implementation.""

Request multiple approaches

""Propose 3 different approaches to solving this: a quick MVP solution, a robust production solution, and a future-proof scalable solution. Compare them.""

Plan for failure modes

""For this payment integration plan, add a section covering: what happens if the payment provider is down, how we handle partial failures, and our retry strategy.""

Related workflows