Think

1---2name: think3description: Invoke before writing any code for a new feature, design, or architecture decision. Turns rough ideas into approved plans with validated structure. Not for bug fixes or small edits.4metadata:5  version: "3.10.1"6---7 8# Think: Design and Validate Before You Build9 10Prefix your first line with 🥷 inline, not as its own paragraph.11 12 13Turn a rough idea into an approved plan. No code, no scaffolding, no pseudo-code until the user approves.14 15Give opinions directly. Take a position and state what evidence would change it. Avoid "That's interesting," "There are many ways to think about this," "You might want to consider."16 17## Before Reading Any Code18 19- Confirm the working path: `pwd` or `git rev-parse --show-toplevel`. Never assume `~/project` and `~/www/project` are the same.20- If the project tracks prior decisions (ADRs, design docs, issue threads), skim the ones matching the problem before proposing. Skip if none exist.21 22## Check for Official Solutions First23 24Before proposing custom implementations, check if an official or built-in solution exists:25 261. **Framework built-ins**: Search official docs and API references for native components or methods that solve the problem directly.27   - Examples: Flutter's PageView for swipe navigation, React's Suspense for loading states, Next.js Server Actions for mutations.28   - Use Context7 MCP tools to query the latest official documentation.29 302. **Official patterns**: Check framework best practices, official examples, and migration guides for recommended approaches.31   - Examples: React 19 recommends `use()` over `useEffect` + fetch, Next.js 15 recommends Server Components over client-side data fetching.32 333. **Ecosystem standards**: Identify officially maintained or widely adopted standard libraries.34   - Examples: Rust's serde for serialization, Python's requests for HTTP, Go's net/http for web servers.35 36If an official solution exists, it must be Option 1 in your proposal. If you recommend a custom approach instead, explain why the official solution is insufficient for this specific case.37 38## Propose Approaches39 40Offer 2-3 options with tradeoffs and a recommendation. Always include one minimal option. For each option: one-sentence summary, effort, risk, and what existing code it builds on.41 42**If an official solution exists from the previous step, it must be Option 1.** State why it fits (or doesn't fit) the current scenario. If recommending a custom approach over the official one, explain why the official solution is inadequate.43 44For the recommendation, run attack angles before presenting it. Four common ones (not exhaustive):45 46| Attack angle | Question |47|---|---|48| Dependency failure | If an external API, service, or tool goes down, can the plan degrade gracefully? |49| Scale explosion | At 10x data volume or user load, which step breaks first? |50| Rollback cost | If the direction is wrong after launch, what state can we return to and how hard is it? |51| Premise collapse | Which assumption in this plan is most fragile? What happens if it does not hold? |52 53If an attack holds, deform the design and present the deformed version. If it shatters the approach entirely, discard it and tell the user why. Do not present a plan that failed an attack without disclosing the failure.54 55Get approval before proceeding. If the user rejects, ask specifically what did not work. Do not restart from scratch.56 57## Validate Before Handing Off58 59- More than 8 files or 1 new service? Acknowledge it explicitly.60- More than 3 components exchanging data? Draw an ASCII diagram. Look for cycles.61- Every meaningful test path listed: happy path, errors, edge cases.62- Can this be rolled back without touching data?63- Every API key, token, and third-party account the plan requires listed with one-line explanations. No credential requests mid-implementation.64- Every MCP server, external API, and third-party CLI the plan depends on verified as reachable before approval.65 66**No placeholders in approved plans.** Every step must be concrete before approval. Forbidden patterns: TBD, TODO, "implement later," "similar to step N," "details to be determined." A plan with placeholders is a promise to plan later.67 68## Gotchas69 70| What happened | Rule |71|---------------|------|72| Moved files to `~/project`, repo was at `~/www/project` | Run `pwd` before the first filesystem operation |73| Asked for API key after 3 implementation steps | List every dependency before handing off |74| User said "just do it" or equivalent approval | Treat as approval of the recommended option. State which option was selected, finish the plan. Do not implement inside `/think`. |75| Planned MCP workflow without checking if MCP was loaded | Verify tool availability before handing off, not mid-implementation |76| Rejected design restarted from scratch | Ask what specifically failed, re-enter with narrowed constraints |77| Built against wrong regional API (Shengwang vs Agora) | List all regional differences before writing integration code |78| Added FastAPI backend to a Next.js project | Never add a new language or runtime without explicit approval |79 80## Output81 82**Approved design summary:**83- **Building**: what this is (1 paragraph)84- **Not building**: explicit out-of-scope list85- **Approach**: chosen option with rationale86- **Key decisions**: 3-5 with reasoning87- **Unknowns**: only items that are explicitly deferred with a stated reason and a clear owner. Not vague gaps. If an unknown blocks a decision, loop back before approval.88 89After the user approves the design, stop. Implementation starts only when requested.