用途：该技能针对需求本身，用一套 18 项质量特征框架（资料称为改编自 BCS 业务分析实践）审计已有需求，或从原始上下文编写新需求。
主要能力：支持两种输入模式，先判断适用哪一种。Mode A 审查：输入一条或多条已有需求，按 18 项特征审计，返回缺陷日志与改写建议。Mode B 编写：输入原始上下文，如笔记、会议记录、讨论串、方案陈述、问题描述，提取并写出从起点即满足 18 项特征的需求。混合输入时先从零散上下文提取需求，再作为同一集合审计。
关键方法：需求分三个层级——业务/战略层（为什么做、组织目标，由发起人负责）、干系人/用户层（用户需要系统为其做什么，表达意图）、解决方案/功能层（系统如何表现，由交付团队负责）。审计前应先判断层级；层级含糊时应询问用户意图，不得默认按解决方案层处理。同一特征在不同层级上满足标准不同，例如可测试性在业务层看结果指标能否测量，在解决方案层才要求今天就能写出具体测试。高层级中看似“缺细节”的内容应列入“分解阶段待定决策”，而非缺陷日志。除非用户要求、原需求在同一层级确实复合，或用户确认要解决方案层，默认不拆分。
18 项特征：前 9 项逐条适用于单个需求，后 9 项（Owned、Relevant、Traceable、Categorised、Unique、Consistent、Conformant、Current、Modifiable、Concise、Correct、Clear 等，资料列举见原文）适用于整体需求集，无法只看单条判断。每项都给出测试方法、坏例/好例与决策逻辑，例如无歧义要求扫描“适当、合理、用户友好、高效、快速、健壮、可扩展、安全、现代、简单、灵活、高质量、必要时”等模糊词，能量化就量化，不能量化不要编造数字，而应记为待定问题。
使用方式与限制：不要强加用户未要求的格式，应沿用需求原有格式或用户指定格式；若用户无偏好，每条需求写成单句。资料未提供安装命令、运行命令、收费、价格或平台信息，这些暂未提供。