thinklisted

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 quest