用途：该技能属于逆向工程的第三阶段，目标是从源代码与逻辑图中提取系统需求，采用 EARS 记法编写，并在一次执行中完成 Doer（提取）与 Critic（校验）的流程。
主要能力：读取 docs/reverse/{analysis}/manifest.json 中 Phase 2 产出的目标，确定待处理组件。遵循三条原则：代码即事实（记录实际行为，疑似缺陷标注 [Suspected Bug]）、可追溯到行（每条需求必须引用 file:line，无证据的按捏造拒绝）、行为优先于意图（描述可观察行为，使用代码中的具体值）。支持 EARS 五种类型：Ubiquitous（System SHALL ...）、Event-driven（WHEN ... SHALL ...）、Unwanted（IF ... SHALL ...）、State-driven（WHILE ... SHALL ...）、Optional（WHERE ... MAY ...）。
使用方式：先校验 manifest 中 phase2.status 为 verified，再按 component 参数或 phase3.remaining 确定目标并置 phase3.status 为 in_progress；随后逐组件扫描源码并按五种 EARS 类型提取，记录类型、语句、file:line、证据代码片段与具体值；再由 Critic 重读源码，核对行号、代码匹配、条件边界与具体值，分类为 APPROVED、CORRECTED 或 REJECTED 并移除捏造项；最后写入 docs/reverse/{analysis}/03-requirements-{component}.md，并更新 manifest 的 phase3 状态与时间戳。
适用场景：对已有代码库做需求逆向、建立需求与代码的溯源、整理阈值/错误消息/配置键等具体值清单。
限制：不得仅以对话形式输出需求，必须生成 Markdown 文件；不得为代码中不存在的行为添加需求，不得使用含糊措辞，不得跳过 Critic 步骤，不得在无行号时发布需求，不得修改源代码文件。具体依赖语言参考等细节暂未提供。