Taku Think 用于在规划前澄清模糊的开发请求、新功能想法、产品与设计选择以及构思阶段的工作，核心目标是防止错误的工作被启动。它要求设计尽量简短，同时按风险程度保持明确。
规则分为两类：[IRON LAW] 是不可协商的正确性约束，[GUIDANCE] 是强默认值，可在上下文合理时调整。铁律是：在所选设计路径可见且用户批准之前，不进行任何实现。
模式按请求成熟度而非关键词选择。Quick 适用于单一明确改动、实现位置明显、无架构决策、成功标准已给出或强烈暗示的情况；Design 适用于数据模型、集成点、组件结构或行为边界尚未确定的常规功能工作；Explore 适用于成功标准未知、真正问题是是否要构建或构建什么的构思阶段。不确定时使用 Design，Quick 应明显安全。
Quick 模式只问一个对齐问题，确认理解是否正确，然后展示聊天可见的迷你设计，包含改动、原因、触点、风险和完成标准；批准后直接路由到 /taku-build，或在需要任务拆分时路由到 /taku-plan。小任务不必为流程创建 DESIGN.md 或 PLAN.md。
Design 模式先阅读直接相关的项目文档、配置和文件，检查邻近模式，最多分两次各问一个澄清问题，跳过用户已回答的问题；随后给出 2-3 个真正不同的方案，推荐一个并说明权衡，用户选择后按 references/design-doc.md 脚手架写 DESIGN.md。设计深度随风险扩展，批准前须清除 TBD、TODO 等占位符。
Explore 模式提出最小一组强制性问题，判断是否存在真实任务；若用户坚持推进，则问剩余最重要的两个问题并尊重回答。仅在产生值得保留的决策时记录到 .taku/explore-{date}.md。
交接前需确认：已有批准的设计或迷你设计、已选定一个方案、成功标准具体可测、范围边界明确、开放问题已解决或作为已知风险接受。若请求包含多个独立子系统，应拆分，先对第一个连贯切片运行 Think。设计系统模式仅在明确的设计系统或视觉识别请求时激活，后端、CLI 和 API 项目跳过。资料未提供安装方式、收费与平台信息。