用途：distill 接收一个含糊的软件请求，输出一份紧凑、可执行的实现简报，让没有参与原始对话的较弱模型也能照做。它只澄清对下游实现真正重要的歧义，不添加篇幅。
主要能力：区分已确认事实、约束、假设、待决决策与建议；用 EARS 句式（The system shall / When / While / Where / If / shall not）编写可观察需求，并为每条需求配可验证的判定依据；按请求规模调整简报（微小任务、功能、大型功能或迁移、缺陷或变更、全新产品）；检测阻塞性歧义，最多一次性提 5 个问题，非阻塞项写成编号假设（A1:）。
使用方式：先提取目标并用一句话复述；轻量查看仓库确认涉及的页面、模块、数据与命令真实存在；扫描歧义并做重要性判断；按参考模板 references/brief-template.md 写简报，核心段落包括目标、上下文、约束与惯例、范围、非目标、可执行规格、边界情况、非功能需求、兼容与迁移、UX 预期、验证方式、已知未知与编号假设；做完后做一次实现就绪检查。产出可放在对话中，或写到 docs/briefs/<slug>.md 并带生成日期标注。
适用场景：需求尚不精确、需要交给其他实现者时；需要明确范围与非目标、权限边界、验收标准时。不适用：仅判断是否要做某个想法、在方案间选择，应转向 hotseat；请求已足够精确；只是小的机械改动（如重命名变量）。
限制：不会自行成为产品负责人、架构师、安全审批者或实现代理；不得推断删除数据、破坏公共契约、改价格、对外沟通、访问生产数据、花钱或部署的权限，这些属于显式审批边界。缺少仓库访问时只能给出临时简报并标注路径或命令假设。何时读取 references/research.md 取决于决策是否涉及外部标准、数值主张或快速变化的实践。收费、价格与平台信息暂未提供。