BRD Writer 的用途是帮助产品与项目相关方写出一份能支撑决策、指导正确建设的商业需求文档（BRD），适用于软件功能、工作流调整和界面重新设计等场景。它的核心不是套用模板，而是先弄清读者是谁、文档要促成什么决策或交付结果、当前工作流及其问题、还有哪些约束或决定未知。
主要能力体现在写作与审阅两方面。写作前要求确立四项信息：谁阅读或批准文档、需要支撑何种决策或交付结果、对现状与问题已知什么、哪些约束或决定仍未知。仅在缺失答案会实质性改变范围或行为时，才提出最多三个针对性问题；否则用明确标注的假设或待决问题继续起草。文档规模按风险选择最轻量级别：简要级适合单一工作流、小改动或一次会议可决的事项；标准级用于多个工作流或团队需要共享上下文与边界；受控级用于监管、迁移、合同或跨系统可追溯性要求。
正文通常按摘要、为何重要、成果与成功、范围、需求、验收、待决决策的顺序组织，标题可按团队语言调整。需求按用户工作流或业务能力分组，先说明用户需求或业务规则，再按用户体验顺序描述正常行为，并点出异常、权限、校验和失败行为；仅在需要引用、批准、测试或追溯时编号。验收默认写成可观察结果清单，仅在团队要求、QA 自动化使用或 Given/When/Then 更清晰时使用 Gherkin。可选材料按需添加，如现状与提案对比表、业务规则示例或决策表、字段清单、接口与依赖描述、非功能要求、风险清单和可追溯性矩阵，密集清单放入附录。
写作风格强调结论和请求行动前置，直接、具体、简洁，使用具体名词和主动动词，不解释读者已知概念，不重复同一信息，不写空泛价值和排比式套话，避免“稳健”“无缝”“赋能”等词，不用过多加粗和破折号，也不在交付稿中保留占位行、空标题或方括号提示。
使用方式上，该技能以资料驱动：起草时依据提供的材料，不声称检查过生产环境、API、分析数据、设计稿或法规，除非确有证据。交付前需进行审阅核对：首页是否讲清问题、预期成果和请求决策；每条需求是否有证据、标注为假设或列为待决；范围与验收是否一致；需求是否在无业务理由时规定技术实现；交叉引用、编号、术语和数字是否一致；表格是否易于理解；是否出现编造的字段、指标、政策、审批或现状行为；删除任一剩余章节是否会丢失读者需要的信息。审阅已有 BRD 时，先指出可能导致错误决策或错误建设的少数问题，再给出具体修改建议，并保留原作者的声音。
适用场景包括产品经理、项目管理者为软件功能、工作流变更、重新设计编写或评审 BRD，以及需要跨团队共享范围边界、在受控环境中追溯需求的情况。限制方面：该技能不替代对生产环境、接口、分析、设计或法规的实际核查；资料未提供具体收费、价格、平台支持范围、效果数据或强制使用步骤，这些信息暂未提供。