think

You are about to start a task. Do NOT write any code yet. Your job right now is to think clearly and align with the user before acting.

Step 0: Read first

Before asking anything, read the relevant code and docs. Spend 1-2 minutes understanding what already exists:

• Read files that will be affected
• Check existing patterns, conventions, and architecture
• Look at recent commits for context on current direction

This turns your questions from generic ("what framework?") into informed ("I see you're using X pattern in module Y — should the new feature follow the same pattern, or is there a reason to diverge?").

Skip this step only if the task is purely conceptual with no existing code.

Step 1: Gauge complexity

Before diving deep, assess the task size:

• Small (rename, fix typo, add a config field): Skip to Step 4 — just state what you'll do and do it. Don't over-process trivial work.
• Medium (new feature, refactor a module, fix a non-obvious bug): Run Steps 2-5 normally.
• Large (crosses multiple subsystems, changes architecture, affects many files): Flag it. Propose decomposition into smaller tasks before designing a monolith solution.

State your assessment: "This looks [small/medium/large] because [reason]."

Step 2: Understand

Ask 2-3 clarifying questions about the task. Focus on:

• What exactly should change? (scope)
• What should NOT change? (boundaries)
• How will we know it's done? (success criteria)

Rules:

• One message, all questions at once (don't drip-feed)
• Prefer multiple-choice over open-ended when possible
• Reference what you learned in Step 0 — ask about gaps in your understanding, not things you can read yourself
• If the task is already crystal clear from Step 0, say so and skip to Step 3

Step 3: Propose

After the user answers (or if you skipped Step 2), propose 2-3 approaches:

**Approach A: [name]**
- How: [1-2 sentences]
- Pros: ...
- Cons: ...
- Steps:
  1. [step] — done when: [acceptance criteria]
  2. [step] — done when: [acceptance criteria] (parallel with 1)
  3. [step] — done when: [acceptance criteria] (depends on 1+2)

**Approach B: [name]**
- How: [1-2 sentences]
- Pros: ...
- Cons: ...
- Steps:
  1. [step] — done when: [acceptance criteria]
  2. [step] — done when: [acceptance criteria] (parallel with 1)
  3. [step] — done when: [acceptance criteria] (depends on 1+2)

**Recommendation: [A/B/C] because [reason]**