clarify 是一个前置规格访谈循环，目标是在进入后续工作流之前消除材料性歧义。它不实现、不制定执行计划、不生成最终需求，输出的是可追溯的上下文。
用途与模式 默认模式为 requirements。可用模式：requirements（在 /specify 前明确产品/功能意图，关注用户、目标、非目标、成功标准、范围、流程、边界情况、约束）；design（规划前的架构或实现方向，关注备选方案、边界、接口、数据流、权衡、风险、可逆性、验证）；domain（术语、概念与领域模型）；plan（蓝图/执行前的工作排序，关注依赖、验收标准、阻塞决策、验证、回滚、归属）。
核心循环 先用 2-4 条要点复述当前理解；列出活跃的歧义分支；每次只问一个问题，并说明为何重要、推荐答案及权衡；若答案可从代码库或现有文档中发现，则先探索而非发问；每次问答后立即追加到 qa-log.md；将分支标记为 resolved、ambiguous、assumption 或 deferred；在 3-5 轮问答后、每个主要分支后及总结前，调用 clarity auditor；审计返回 CONTINUE 则继续提问，返回 SUFFICIENT 则写 clarity-summary.md。
产物与用法 创建 .hoyeon/clarify/<topic-slug>/ 目录，包含 qa-log.md 与 clarity-summary.md，并参考 templates 下同名模板。topic slug 使用短 kebab-case。运行时在 Claude Code 用 AskUserQuestion、Task(subagent_type="clarity-auditor") 和 code-explorer；在 Codex 用原生结构化输入或一次一个纯文本问题，原生适配器不可用时执行最小的只读检查并在 qa-log.md 记录回退。
问题规则与限制 一次一问；面向用户的问题必须附推荐答案（纯事实且需发现的问题除外）；优先给出具体选项但允许 Other；不向用户询问代码/文档可答的事实；不重复提问，用户不知道时选暂定默认并标记 assumption 或 deferred。需持续追问 fast、simple、good、production-ready、secure、later、nice UX、admin、sync、done 等模糊词。硬性规则：不实现、不生成最终 requirements.md/plan.json/ADR（除非明确要求）、一次一问、每次交换先记录再问下一个、直到 SUFFICIENT、暂停或用户明确停止。
交接 SUFFICIENT 后写 clarity-summary.md 并给出一个下一步动作，例如 requirements 模式为 $hoyeon-specify --context .hoyeon/clarify/<topic>/clarity-summary.md "<topic>"。除非用户要求，不运行交接工作流。具体平台适配与模板细节暂未提供更多说明。