Enter planning mode before implementing non-trivial tasks. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment.

## When to Use — call enter_plan PROACTIVELY when ANY of these apply:

1. **New Feature Implementation**: Adding meaningful new functionality
   - Example: "Add a logout button" — where should it go? What should happen on click?
   - Example: "Add form validation" — what rules? What error messages?

2. **Multiple Valid Approaches**: The task can be solved in several different ways
   - Example: "Add caching to the API" — could use Redis, in-memory, file-based, etc.
   - Example: "Improve performance" — many optimization strategies possible

3. **Code Modifications**: Changes that affect existing behavior or structure
   - Example: "Update the login flow" — what exactly should change?
   - Example: "Refactor this component" — what's the target architecture?

4. **Architectural Decisions**: The task requires choosing between patterns or technologies
   - Example: "Add real-time updates" — WebSockets vs SSE vs polling
   - Example: "Implement state management" — Redux vs Context vs custom solution

5. **Multi-File Changes**: The task will likely touch more than 2-3 files
   - Example: "Refactor the authentication system"
   - Example: "Add a new API endpoint with tests"

6. **Unclear Requirements**: You need to explore before understanding the full scope
   - Example: "Make the app faster" — need to profile and identify bottlenecks
   - Example: "Fix the bug in checkout" — need to investigate root cause

7. **User Preferences Matter**: The implementation could reasonably go multiple ways.
   If you would use `question` to clarify the approach, use enter_plan instead — it lets you explore first, then present options with context.

## When NOT to Use

Only skip enter_plan for simple tasks:
- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
- Adding a single function with clear requirements
- Tasks where the user has given very specific, detailed instructions
- Pure research/exploration tasks (use `task` with explore subagent instead)

<example>
GOOD — Use enter_plan:
User: "Add user authentication to the app"
→ Requires architectural decisions (session vs JWT, storage, middleware)

User: "Optimize the database queries"
→ Multiple approaches possible, need to profile first

User: "Add a delete button to the user profile"
→ Involves placement, confirmation dialog, API call, error handling, state updates

User: "Update the error handling in the API"
→ Affects multiple files, user should approve the approach
</example>

<example>
BAD — Don't use enter_plan:
User: "Fix the typo in the README"
→ Straightforward, no planning needed

User: "Add a console.log to debug this function"
→ Simple, obvious implementation

User: "What files handle routing?"
→ Research task, not implementation planning
</example>

## After calling enter_plan:

1. Thoroughly explore the codebase using `glob`, `grep`, and `read`
2. Understand existing patterns and architecture
3. Design an implementation approach
4. Present your plan with `exit_plan` for user approval
5. Use `question` if you need to clarify approaches DURING planning
6. Wait for approval before making any code changes