\r \r

Taku Think - Minimum Necessary Design\r

\r Think prevents wrong work from starting. It should be as short as the task\r allows and as explicit as the risk requires.\r \r Rule labels: [IRON LAW] means a non-negotiable correctness constraint. [GUIDANCE] means a strong default that may adapt when context justifies it.\r \r [IRON LAW] No implementation until the selected design path is visible and the\r user approves it.\r \r

Mode Selection\r

\r Choose by request maturity, not keywords.\r \r

• Quick: one clear change, obvious implementation location, no architecture\r decision, success criteria are already stated or strongly implied.\r
• Design: normal feature work where data model, integration points,\r component structure, or behavior boundaries are open.\r
• Explore: idea-stage work where success criteria are unknown or the real\r question is whether/what to build.\r \r When in doubt, use Design. Quick should feel obviously safe.\r \r

Quick Mode\r

\r Use Quick when heavy artifacts would be wasteful.\r \r

1. Ask one alignment question:\r \r

   I understand this as: [change], touching [files/areas], verified by [check].\r
   Is that right?\r
   ```\r
   

\r 2. If corrected, restate once.\r 3. Present a chat-visible mini design:\r \r

MINI DESIGN\r
- Change:\r
- Why:\r
- Touch points:\r
- Risk:\r
- Done when:\r
```\r
\r
4. After approval, route directly to `/taku-build` for a single obvious change,\r
or `/taku-plan` when task breakdown matters.\r
\r
Do not create `DESIGN.md` or `PLAN.md` just to satisfy process for tiny tasks.\r
The mini design is enough when it contains scope, risk, and verification.\r
\r
## Design Mode\r
\r
Use Design when implementation choices matter.\r
\r
Before proposing a design:\r
\r
- read the directly relevant project docs/config/files\r
- inspect nearby patterns\r
- ask at most two clarifying questions, one at a time\r
- skip questions already answered by the user\r
\r
Present 2-3 distinct approaches:\r
\r
- one minimal viable path\r
- one stronger long-term architecture\r
- one lateral option only if it is genuinely different\r
\r
Recommend one and explain the tradeoff. After the user chooses, write\r
`DESIGN.md` using `references/design-doc.md` as the local scaffold.\r
\r
Design depth scales to risk:\r
\r
- **Lightweight:** problem, approach, touch points, risks, done when.\r
- **Standard/Deep:** add architecture, data flow, error handling, testing\r
strategy, and open questions.\r
\r
Before asking for approval, remove placeholders such as TBD, TODO, "appropriate",\r
or "handle later." A design with placeholders is not a contract.\r
\r
## Explore Mode\r
\r
Use Explore when the request is not ready to become a build contract.\r
\r
Ask the smallest set of forcing questions needed to identify whether there is a\r
real task:\r
\r
- What evidence shows this is needed?\r
- Who is the first user or maintainer affected?\r
- What is the smallest useful version?\r
- What happens if we do nothing?\r
- What existing code or workflow already solves part of it?\r
\r
If the user asks to proceed despite unanswered questions, ask the two most\r
important remaining questions, then respect the answer.\r
\r
Record useful exploration notes in `.taku/explore-{date}.md` only when the\r
session produces decisions worth preserving. Otherwise summarize in chat.\r
\r
## Handoff Contract\r
\r
Before routing to `/taku-plan` or `/taku-build`, verify:\r
\r
- approved design or approved mini design exists\r
- one approach is selected\r
- success criteria are concrete and testable\r
- scope boundaries are explicit\r
- open questions are answered or accepted as known risk\r
\r
If any item is missing, resolve it before handoff. Plan and Build must not invent\r
design decisions.\r
\r
## Scope Guard\r
\r
If the request contains multiple independent subsystems, split it. Run Think on\r
the first coherent slice and list what remains out of scope.\r
\r
## Design System Mode\r
\r
Only activate for explicit design-system or visual-identity requests. Load\r
`references/design-system.md` when triggered. Backend, CLI, and API projects skip\r
this mode.\r
\r
## Known Pitfalls\r
\r
**Quick mode used for a non-quick task.** "Add settings" often hides storage,\r
permissions, audit, migration, and UI decisions.\r
\r
Prevention: Quick requires one obvious implementation path. If two reasonable\r
approaches exist, use Design.\r
\r
**Three fake approaches.** "React", "React with hooks", and "React with hooks\r
and TypeScript" are not distinct options.\r
\r
Prevention: present two real options instead of three cosmetic ones.\r
\r
**Design doc with TBDs.** Build treats TBD as permission to invent behavior.\r
\r
Prevention: placeholder scan before approval.\r