repo-orchestration

RepoSkillOpt — 目标态设计与实现编排（规范技能）

目的

此技能使用现状制品（架构视图 + 变更影响分析）和明确的目标，产出（a）可供评审的目标态设计——以现状证据为依据的 ADR + 简明的设计文档；以及（b）实现编排计划：一份机器可读的任务台账，将工作分解为规模小、彼此独立、可单独验收测试的子任务，并声明依赖关系和拓扑顺序。该计划是一份制品，而非执行器——任何编排器都可以使用它；此技能绝不执行实现工作。与供应商无关：不依赖任何特定的编码 Agent 运行时。

触发条件

当用户要求设计目标态、规划工作／拆分任务或为目标 X 制定实现计划，或提出可识别的同类请求时，激活此技能。对于无关请求，不要激活；也不要执行生成的计划。

前置条件

现状制品（架构视图、变更影响分析）和明确的目标。如果缺少现状信息，先引导用户使用现状架构技能；不要基于未经验证的当前系统图景进行设计。

操作原则

• 以现状为设计依据。 每项设计主张都必须可追溯至现状证据（通过引用的现状制品中的 file:line）。将推断标记为 **[inference]**，将未知项标记为 **[unknown]**。
• 明确作出决策。 有争议的选择必须形成 ADR，权衡 ≥2 个选项，不得默默采用默认方案。
• 只规划，不执行。 任务台账是可移植的制品；此技能负责编写并在此停止。
• 任务彼此独立，且可单独验收测试。 每个子任务都应足够小，可以单独执行并由评审者验证，并声明其依赖关系；若任务无法独立验收测试，就将其拆分。
• 仓库事实仅适用于该仓库。 只有适合通用化的候选模式才纳入收敛。

工作流

(a) 阅读现状制品和目标。 识别约束及受影响范围。

(b) ADR（.reposkillopt/decisions/ADR-NNN-<slug>.md，参照 templates/adr.md）：每项决策各自成文，包含背景、所考虑的选项（≥2 个，含利弊）、决策、后果。若目标与现状约束冲突，应将其记录为 ADR 中的权衡，而非掩盖冲突。

(c) 设计文档（.reposkillopt/design/design-doc.md，参照 templates/design-doc.md）：目标、目标态概述、与现状的映射（每项变更都要关联并引用其涉及的当前组件／流程）、风险与权衡（链接相关 ADR）、范围外事项。

(d) 任务台账（.reposkillopt/plan/task-ledger.md，参照 templates/task-ledger.md）：以表格列出工作——id | goal | acceptance | depends_on；每项任务都必须彼此独立且可单独验收测试，声明依赖关系，依赖关系图必须无环，并在前置元数据 topological_order 中按依赖项先于其所依赖任务的顺序列出每个 id。

(e) 确定性检查门槛。 制品必须通过确定性检查（check_adr、check_task_ledger）：每个 ADR 至少有 2 个选项；每项任务都必须有目标和验收标准；依赖项必须存在；依赖关系图无环；拓扑顺序有效。

输出规范

采用与现状技能相同的 R10 标签和引用格式；设计主张必须引用其依据的现状制品。简单复述无需标签。

人工反馈循环

对决策或任务分解的修正，应作为反馈项（templates/human-feedback.md）记录在 .reposkillopt/feedback/ 下，并直接更新制品。

技能收敛循环

反复出现的通用候选项反馈（≥3 个相关项）会转化为技能编辑提案 （templates/skill-edit-proposal.md），仅在通过验证门槛 （rubric/validation-gate.md）后才会被接受：针对一个不重叠的留出集重新生成产物，且各维度评分标准均无退步（见 rubric/tobe-orchestration-rubric.md），确定性检查也仍然通过。任何内容都不会被悄悄提升；接受提案后会更新版本号和 CHANGELOG，并同步到四个适配器中。