用途：把一句话的模糊想法变成双方明确认可的书面规格，再进入规划与编码。核心原则是从不假设：任何不确定处都变成问题，而非自行决定。
主要能力：按九个维度分轮提问，每轮挑 3–5 个最关键问题，维度依次为问题与用户、范围、领域与数据、API 契约、授权、边界与失败模式、非功能需求、集成、验收标准。回答立即写入草稿规格。遇到自相矛盾会当场指出；"不知道"可作为回答，但须进入"推迟决策"并选定临时兜底方案，禁止隐式推迟。某维度再提一轮无新问题即算完成，九维全部完成才结束提问。
使用方式：先复述理解并请开发者确认，再分轮提问；随后生成 docs/specs/<NNN>-<slug>.md，含 Problem、Scope（In/Out）、Domain Model、API Contract、Authorization、Edge Cases、Non-Functional、Integrations、Acceptance Criteria（AC-1…）、Deferred Decisions、Open Questions 等章节。状态为 Draft → In Review → Approved。审批须开发者明示，Open Questions 必须清空方可批准。批准后 /plan 读取规格并映射验收标准，/tdd 将 AC-n 转为首个失败测试，提交信息引用规格编号。实现中发现假设有误须回退至 In Review 并同步修正。
适用场景：一句话说不清的功能、新产品或模块想法、非平凡功能在 /plan 之前、实现中需求变模糊时。触发词包括 spec、requirements、PRD、define the feature、acceptance criteria。
限制：缺陷修复、重构、实体明确的单端点 CRUD 可跳过。具体平台支持、收费与价格信息暂未提供。