该技能名为 orchestrate-repair-requirements-loop，用于将单个现有需求通过“评审—基于证据的修复—复评”循环收敛。其职责是协调评审调用、最小修复步骤、停止条件和报告；评估委托给 review-requirements，需求文档契约由 requirement-modeling Spec 负责，质量标准由 requirement-quality Rule 负责，本编排器不额外添加质量检查清单。
用途：当用户要求修复需求发现项，或持续修复需求直到评审通过时使用。若只需评审而不修改，应使用 review-requirements；若需修复代码并收敛测试，应使用 orchestrate-repair-loop。本技能不引导新产品需求、不选择架构、不实现代码，也不重写下游设计和任务。
主要能力：读取目标需求及其权威业务来源和项目文档约定，可选接收 findings-list 格式的现有发现、范围约束、完成目标和迭代上限。执行基线评审（只读），检查已有发现的有效性，保留来源并解释过时或无效发现。在迭代中分类发现为可修复或需缺失事实/业务决策/授权，按严重性和位置排序，应用最小证据支撑的修复批次，关联每个变更与发现及来源定位符，保持需求意图、范围和稳定标识符。每轮修复后重新完整评审，仅当复评确认缺陷消失时才标记发现已解决。不编造指标、风险、约束、负责人、截止日期、可行性证据或验收行为；占位符或开放问题只记录缺口，不算解决。需要决策时说明已验证缺口、后果和所需具体选择或证据，完成独立修复后停止依赖工作。不削弱验收标准、不删除必需章节、不修改质量规则或降低发现严重性以换取通过。检查下游引用影响但只报告必要修订，不超出授权范围应用。
使用方式：输入一个现有需求路径或完整内容，附带权威业务来源和适用项目文档约定；可选提供 findings-list 格式的现有发现、范围约束、完成目标和迭代上限。输出为修复后的草稿（提供可写路径时更新文件，否则为修订内容）和简洁循环报告。报告包含所用来源、逐轮变更和评审结果、剩余发现、未解决决策和最终状态。评审发现保留在共享 findings-list 契约下，修复跟踪与发现分开。默认最多5轮修复迭代，完成目标为零发现；可接受更窄目标如无严重或主要发现，但需披露残留发现且不得称为干净评审。一轮迭代为一次修复批次加一次复评，基线评审不计入迭代。评审专用请求不授权此循环。选择编辑目的地前检查生命周期：Spec 冻结已批准需求，草稿可原地修复，但已批准、已实现和已取代的快照需保留；冻结目标需使用项目后继流程和新草稿 ID，若后继目的地或所需授权未解决，应先询问再写入，且不自动取代原需求或标记后继为已批准。
适用场景：已有需求文档存在评审发现需修复；需要反复修复并复评直至通过；需在修复过程中区分可修复项与需业务决策项；需保留已批准快照并走后继流程的修订。
限制：默认迭代上限为5轮，可指定更窄目标或时间预算；不处理新需求引导、架构选择、代码实现或下游设计/任务重写；不发布、提交、批准、取代或实现需求，生命周期转换仅通过项目流程和现有授权进行；评审就绪本身不等于发布或批准；循环报告默认保留在响应中，除非用户要求持久化。缺失来源或评审覆盖不完整是限制，不能视为未解决标准已通过。