用途：该技能定位为“业务需求专家”，优先级为 P0（关键），目标是在产品或技术规格之前先框定业务的“为什么”，把业务目标、干系人影响、现状与未来状态、可衡量的价值成果标准化为 BRD 与 BRD-lite 发现流程。
主要能力：
- 发现工作流：对不需要完整 BRD 的业务分析或需求获取请求，直接加载分析规划与获取流程，不经过 BRD-lite 入口；起草执行摘要（目的、结果、发起人、验证负责人）；对模糊的“实现 X”类请求，先依据已有证据起草 BRD-lite，并按常见决策纪律最多提出 3 个关键阻塞问题并附推荐默认值，不重复询问已定决策；确认业务目标与成功指标；识别发起人、决策者和受影响干系人；记录 AS-IS 流程痛点与 TO-BE 目标状态；定义范围边界、排除项、假设与约束；记录价值假设（成本、收入、风险、合规或周期时间影响）；明确交接负责人（BA 负责人）与下一责任团队成员（产品经理）；在干系人或领域语言可能被误读时补充术语表；当流程复杂度影响审批时补充 Mermaid 的 AS-IS/TO-BE 流程图。
- BRD-lite 起草：加载参考模板，保持每个目标符合 SMART 原则，将每个 BRD 目标关联到候选 PRD 需求占位符（REQ-*），为远程交付团队提供干系人验证计划和验收窗口，加入结果报告种子（feature_status、requirement_trace、已完成/缺失证据、所需决策、建议的下一步工作流 plan-feature），写入 docs/brd/brd-[slug].md。
- 质量门禁：每个目标都有负责人和 KPI 目标；每个范围内条目都有理由和对应的范围外配对；风险登记册包含缓解负责人；干系人审批与未决决策明确；功能性行为交由 PRD/SRS，不埋在 BRD 中；充分说明的低风险工单维护可在聊天内约定下进行，无需强制走 BRD 文档，但须有责任负责人、已批准的范围围栏、价值理由和验证目标；敏感变更仍要求技术设计和明确的人工/治理审批。
反模式：Why 通道 BRD 中不做方案设计；不写没有基线和目标的模糊目标（如“提升效率”）；目标和风险不得缺少负责人；在责任负责人、价值理由/指标和范围围栏明确前，不路由到编码或 QA；批准后不得静默扩大范围；不得使用无术语表条目的行话。
适用场景：业务分析、需求获取、BRD 与 BRD-lite 撰写、干系人对齐、现状与目标状态梳理、价值假设记录，以及带责任负责人和范围围栏的低风险工单维护。
限制：资料未提供具体安装命令、平台兼容范围、收费或价格信息；功能行为应路由至 PRD/SRS，敏感变更仍需技术设计与人工/治理审批。