用途：将模糊业务想法梳理成 BRD，或访谈业务需求、整理已有业务材料。触发场景包括“帮我梳理业务需求”“老板说要做 XXX”“这个需求不太清楚”“写 BRD”。仅修改已有文档片段时只处理指定片段，不重启全套访谈；不用于替代 API/HLD/LLD 设计或业务批准。
主要能力：保留原始意图，BRD 聚焦 WHAT/WHY、目标用户、范围、成功定义、依赖与约束；已知事实直接引用，不确定信息标记假设，不代替用户决定或批准；访谈每轮最多 2-3 个关键问题，尊重用户指定的检查点；按访谈模式与事实标准选择 interview、synthesis 或 gap_followup；量化不是所有任务的硬门禁，实测、估算、测量计划、离散验收分别记录；默认跟随用户语言，字段名、枚举、ID 与 comment markers 保持英文。
使用方式：执行前读取工作流执行约定，先读取用户材料，从本次安装位置定位资源，按真实工具能力工作。最小工作流为：读取指定材料、原始目标和已有批准依据，不因文件名或标签认定批准；判断需要局部编辑、访谈或材料整理，不重复索取已有内容；资料充分就直接整理，仅有局部歧义只问缺口，需要访谈时按访谈问题库相关阶段补全；生成文档时按用户语言读取中文或英文模板，使用用户指定路径，没有路径时选工作区内合理默认并说明；检查范围、成功定义、依赖和假设，缺少历史数值仍可交付明确标注的草稿，不猜数字、不按假设数量阻塞；只要求草稿就保持草稿，正式批准必须有对应版本或范围的真实依据；返回实际文件、来源、未决项和交付状态，不主动进入实施或发布。
按需资源：需要具体问题、分支或当前准出清单时用访谈问题库；需要问题组织方法时用访谈框架；需要沟通技巧时用顾问风格；涉及行业特有需求时只读 Fintech、Healthcare、B2B SaaS、Retail、Manufacturing 相关分支。技术建议可保留到附录并注明待评估，不从技术名称推导用户未给的业务阈值；接口契约、架构及实现细节分别留给 API/HLD/LLD 职责。
适用场景：老板想做会员体系但目标不清楚时先访谈关键业务缺口；根据会议记录整理 BRD 时先读取记录、复用已知事实；只改 BRD 产品名时局部修改并检查差异，不加载行业问卷、不重开准出。
限制：不替代 API/HLD/LLD 设计或业务批准；不猜数字；正式批准需真实依据；资料未提供具体安装命令、价格、平台支持等信息。