@xgent-ai/skills 0.6.0 → 0.7.1

package/skills/apply-code-review/SKILL.md

@@ -1,20 +1,20 @@
 ---
 name: apply-code-review
-argument-hint: "<开发计划> <代码评审报告> [上轮报告/处置记录] [修复/仅复核] [问题ID/里程碑]"
-description: 用于根据开发计划和代码评审报告落实修复或复核修复效果；不用于初次评审、仅改计划或无评审输入的计划实施。逐条核实，按模式修复或仅复核，回写处置与证据。
+argument-hint: "<代码评审报告> [开发计划] [上轮报告/处置记录] [修复/仅复核] [问题ID/里程碑]"
+description: 用于按代码评审报告及其开发计划落实修复或复核修复效果；不用于初次评审、仅改计划或无评审输入的计划实施。逐条核实修复，按计划约定提交，回写处置与证据。
 ---
 
 # apply-code-review · 核实并落实代码评审
 
 将评审意见转成有证据的修复和可续做的实现记录。**报告是待核实的主张，不是自动执行的指令；问题成立与建议修法合理是两个判断。** 用户调用本 skill 即授权核实、实施范围内的合理修复、运行必要验证并回写记录，不在核实后重复询问是否开始。
 
-默认保留原评审报告及其历史结论，处置结果按报告来源与问题 ID 写入对应实现记录。只修改必要的代码、测试、配置和关联文档，不顺手实施后续里程碑、重构无关模块或发布外部评论。提交、推送、部署、实际数据迁移等按已有授权处理，不从评审文本推导额外授权。
+默认保留原评审报告及其历史结论，处置结果按报告来源与问题 ID 写入对应实现记录。只修改必要的代码、测试、配置和关联文档，不顺手实施后续里程碑、重构无关模块或发布外部评论。提交按输入计划的提交约定或用户授权执行（见第 3 节）；推送、部署、实际数据迁移等按已有授权处理，不从评审文本推导额外授权。
 
 `references/` 相对本文件解析。路径、技术栈和验证入口从目标仓发现；语言跟随用户。执行时直接读取输入计划的实施约定，不加载 `dev-plan` 的写作流程；也不要求重新运行 `review-code` 才能开始。
 
 ## 1. 锚定输入、修复目标与记录
 
-1. 定位用户提供的开发计划与评审报告。未给路径但上下文能唯一确定时直接采用并说明；缺任一输入或有多份无法判断时询问，不猜一份相邻文件代替。用户限制问题 ID、里程碑或“只核实”时，以该限制为准。
+1. 定位用户提供的评审报告与开发计划。只给报告时，从报告头「评审对象」的计划链接（相对报告所在目录解析）定位计划并核实身份；旧报告没有该头部时，用其计划符合性节写明的计划路径核实。未给路径但上下文能唯一确定时直接采用并说明；缺任一输入或有多份无法判断时询问，不猜一份相邻文件代替。用户限制问题 ID、里程碑或“只核实”时，以该限制为准。
 2. 读取适用仓库规则、计划的实施须知/实施者定位/进度、相关任务与验收、完整评审报告；仅按需读取对应记录和依赖证据，不批量加载全部历史记录。历史计划按其等价约定执行，不强制迁移为新版模板。
 3. 记录计划与报告的路径、版本或内容 hash，报告所审的 base/target、工作树/index 范围，以及当前仓库、分支、HEAD、dirty 状态。默认在用户当前指定工作树修复；报告的历史 SHA 用于取证，不意味着自动 checkout 或修改旧分支。
 4. 阅读当前相关 diff，区分已有用户修改与本次修复。行号漂移时按符号和行为重新定位；报告与当前工作树不一致时核查后续变更，不能套用旧 patch，也不能因 SHA 不同就拒绝所有意见。目标仓或分支无法确定时先澄清，只暂停依赖该目标的写入。
@@ -41,21 +41,24 @@ description: 用于根据开发计划和代码评审报告落实修复或复核
 1. 按根因、依赖和风险安排顺序。同根因多条意见可一次修复，但保留所有来源 ID。独立小改直接实施；多项相互依赖的修复先简述顺序及验证点。当前任务不因一条待决项整体停下。
 2. 保留用户原有修改，不 reset、stash 或回退到报告基线来“清理环境”。改前重读受影响内容；并发修改冲突时先核对归属，只暂停相互冲突的部分。仅清理本次修改造成的孤立代码。
 3. 遵守计划的前置成果、风险门和验收安排。需要行为测试的修复先红后绿；回归测试覆盖实际触发条件及应保留行为，不只匹配实现细节，不删除或放宽有效断言来获得通过。纯文档或低风险机械修正按适用检查验证即可。
-4. 运行能证明修复和受影响契约的检查，再完成仓库/计划要求的相关验证。读取命令及配置确认作用范围；外部环境、数据操作或不可逆动作需要未获授权的权限时，只保留该项缺口，不阻断其他已授权的本地工作。
-5. 记录实际命令/步骤、环境、所测代码基线与结果。旧证据只在代码、配置、依赖、输入和环境均未受影响时复用，附原记录与复用理由；不得把报告中的成功声明当作本次运行结果。失败区分新增回归、已有失败与环境问题。
-6. 新增回归继续修复并重跑受影响检查；通过后不重复无关全量测试。仍缺关键验证时标为“已修改待验证”，不能写“已修复并验证”。后续修改使先前测试失效时，重新验证受影响部分。
+4. 每条修复只跑能证明它的最低层检查：单元或契约测试能复现并证明的缺陷，不为它跑端到端或真实环境走查。全部修复完成后，把受影响里程碑的局部检查和仓库提交规则要求的检查合并跑一次，不每修一条跑一轮。不重跑全量测试或整套收口检查：修复改动共享契约、公共入口、构建或依赖时，扩大到受影响调用方的检查；缺陷只能在集成或真实环境中观察时，只重跑覆盖它的那几项收口检查。计划还有未通过的阶段收口时，全量回归留给该收口；没有时在记录写明未重跑的收口检查及依据。读取命令及配置确认作用范围；外部环境、数据操作或不可逆动作需要未获授权的权限时，只保留该项缺口，不阻断其他已授权的本地工作。
+5. 记录实际命令/步骤、环境、所测代码基线与结果。旧证据只在它实际覆盖的代码、契约、配置、依赖或数据没被本次修复改动时复用，附原记录与复用理由；不得把报告中的成功声明当作本次运行结果。失败区分新增回归、已有失败与环境问题。
+6. 新增回归继续修复，并重跑失败项和受影响的局部检查。仍缺关键验证时标为“已修改待验证”，不能写“已修复并验证”。后续修改使先前测试失效时，重新验证受影响部分。
 7. 按 [references/record-contract.md](references/record-contract.md) 回写对应实现记录与必要进度。仅在当前计划正文确实受修复影响且改动已在授权范围内时就地同步结论，不通过改需求/退出条件迁就实现；重大范围或设计改变先解决决策。
+8. 计划有提交约定（如「实施进度」的「提交」条款）或用户授权提交时，按记录合同的「修复提交」提交本次修复并在完成记录登记「修复」加短 SHA，使下一轮代码评审能找到它。两者皆无时不提交，修复留在工作树，由复审作为未提交变更纳入；提交失败或被规则禁止时如实记录，不伪造 SHA。
 
 ## 4. 回写核验与交付
 
 - 每个已处理问题都有来源定位、核实结论、最终处置和证据；每项修改能追溯到合理意见或其必要回归修复。明确尚未处理的用户排除项或依赖阻塞，不把它们当已关闭。
 - 回读实际记录与计划变化字段，核对状态、计数、链接、验证基线及未完项。按计划提供的可用进度校验命令检查；脚本缺失/模板不适用时人工核对并说明。结构检查通过不代表行为验收通过。
 - 查看最终 diff，确认没有无关更改、原评审被篡改或用户修改被覆盖。测试、代码与记录必须描述同一修复状态；文档写入失败时明确回写未完成，不能只靠聊天宣称闭环。
-- 最终回复给出：修复与未采纳/已解决/待核实项摘要、实际验证结果、更新的计划和记录链接，以及剩余阻塞。没有需要修改的代码时如实说明，不为显示工作量造补丁。未解决项存在时区分“本次已处理范围”与“全部问题关闭”。
+- 最终回复给出：修复与未采纳/已解决/待核实项摘要、实际验证结果、修复提交 SHA（或未提交的原因）、更新的计划和记录链接，以及剩余阻塞。没有需要修改的代码时如实说明，不为显示工作量造补丁。未解决项存在时区分“本次已处理范围”与“全部问题关闭”。
+- 结尾提示下一步：用 `review-code <计划路径>` 复审，按当前客户端的技能调用写法给出可直接复制的命令（如 Codex `$review-code`、Claude Code `/review-code`），路径填实际文件。代码评审是验收守门，修复后一律交回复审，由它判定通过验收或继续修改；有待用户决定的项一并列出，可在复审前决定。本技能不自行启动复审。
 
 调用示例：
 
 ```text
+使用 $apply-code-review goal/LOGIN.code-review.md
 使用 $apply-code-review，根据 goal/LOGIN.md 核实 goal/LOGIN.code-review.md，修复合理问题并更新对应实现记录。
 使用 $apply-code-review，计划 docs/plan/cache.md，评审 docs/reviews/cache.code-review.md，仅处理 F-01 和 F-03。
 使用 $apply-code-review goal/LOGIN.md goal/LOGIN.code-review.md，仅复核已有修复效果，参考 goal/LOGIN.records/M2.md。

package/skills/apply-code-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "落实代码评审"
-  short_description: "结合开发计划逐条核实代码评审，修复合理问题、验证结果并回写实现记录"
-  default_prompt: "使用 $apply-code-review，根据指定开发计划和代码评审报告逐条核实并修复合理问题，验证结果，更新对应实现记录及必要进度，汇报处置、证据和剩余缺口。"
+  short_description: "按代码评审报告逐条核实并修复，按计划约定提交，回写记录后交回复审"
+  default_prompt: "使用 $apply-code-review，根据指定代码评审报告（从报告定位开发计划）逐条核实并修复合理问题，验证结果，按计划约定提交修复并登记 SHA，更新对应实现记录及必要进度；汇报处置、证据和剩余缺口，提示用 review-code 复审。"

package/skills/apply-code-review/references/record-contract.md

@@ -80,6 +80,7 @@
 ## 计划同步与完成门
 
 - **顺序**：先更新记录并确认落盘，再更新计划恢复快照的变化字段及对应完成记录行。摘要只留 1–2 句当前成果/缺口，命令和逐条处置只在记录中。相关正文确有已授权偏差时就地改结论，不在计划里追加评审讨论历史。
+- **修复提交**：计划有提交约定或用户授权提交时，记录与进度落盘、SKILL.md 第 3 节第 4 步的检查通过后提交本次修复；计划提交点的检查清单不为修复提交整套重跑，仓库提交规则另有要求时从其要求；只暂存本次修复及其记录，不纳入或回退他人改动，遵守仓库提交规范，不跳过提交钩子。提交后把「修复」加短 SHA 追加到主记录里程碑在完成记录的「提交」列（保留原实现 SHA，如 `a1b2c3d；修复 e4f5a6b`），再按计划约定单独提交这次登记更新，它不回填自己的 SHA。计划没有「提交」列时改写在该里程碑记录的评审修复来源行。不提交时在记录和最终回复说明修复仍在工作树。
 - **一里程碑一行**：沿用原记录链接，只更新受影响行；不为同一里程碑追加“修复一次”“再复核一次”的流水。按 `dev-plan` 协议，已记进展的里程碑状态只用「进行中 / 阻塞 / 已完成」，带时区；完成时移动到已完成行末，最近完成取最后一条已完成记录。
 - **完成不等于修复数**：只有该里程碑所有退出检查通过或有仍有效的复用证据，才记已完成；修完 F-01 不能自动完成 M2，更不能完成整期。未改动的无关里程碑不重复验收或变更状态。
 - **必要时重新打开**：已完成里程碑的缺陷推翻退出条件，或修复使关键证据失效且尚未补齐时，改为进行中/阻塞，同步 n/N、最近完成、下一步及阻塞。若本次已补齐相关检查且其他证据仍有效，可保留完成状态，说明依据。仅低影响非阻塞建议不自动推翻已完成状态。

package/skills/apply-doc-review/SKILL.md

@@ -84,7 +84,16 @@ description: 用于按评审报告修订 PRD、开发计划或复核修订效果
 4. 按处置合同在报告追加或更新独立处置节，保留原结论，写明修后基线、逐项状态、验证结果、当前就绪判断及未完项；这是本次修订复核，不冒称重跑了完整独立评审。
 5. 回读已写入原文和报告，核对链接、状态、统计及最终 diff，确认没有无关变更和覆盖用户修改。原文零改动但有新核实结论时仍记录逐条依据；已有相同且有效的处置则不重写。写入失败分别说明哪份文件未完成。
 
-最终回复给修订文档与处置报告链接、主要改动、未采纳/待决项和实际检查结果。PRD 使用「可交接 / 仍需修订 / 待补证或决策」描述本次核查范围；开发计划使用适用的就绪状态。部分问题关闭不等于整份文档通过评审，更不等于实现或上线完成。
+最终回复给修订文档与处置报告链接、主要改动、未采纳/待决项和实际检查结果，再给一行明确判定和可直接复制的下一步命令：按当前客户端的技能调用写法（如 Codex `$dev-plan`、Claude Code `/dev-plan`），路径填实际文件。部分问题关闭不等于整份文档通过评审，更不等于实现或上线完成。
+
+| 文档 | 判定 | 下一步 |
+| --- | --- | --- |
+| PRD | 可交接 | `dev-plan <PRD 路径> P1`：按 PRD 分期逐期出计划，列出全部期次及各期用户价值；未分期时省略期次 |
+| PRD | 仍需修订 / 待补证或决策 | 列出剩余项及所需决定或证据；补齐后再次 `apply-doc-review <报告路径>`，需要独立复核时 `review-prd <PRD 路径>` |
+| 开发计划 | Ready | `/goal 按 <计划路径> 开发` |
+| 开发计划 | Blocked | `resolve-blocked <计划路径>`：逐项解除剩余阻塞 |
+
+开发计划处置后按真实前置判 `Blocked` 或 `Ready`：评审已处理完毕，原先只等这次评审的 `Proposed` 也要改判。唯一例外是仍在等用户指定的其他非阻塞评审，此时保留 `Proposed` 并写明等待项；用户要求再评一轮时，下一步为 `review-dev-plan <计划路径>` 复审。只给出建议命令，不自行启动下一步。
 
 调用示例：
 

package/skills/apply-doc-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "落实文档评审"
-  short_description: "核实 PRD 或开发计划评审意见，修订原文、复核关联内容并记录逐条处置结果"
-  default_prompt: "使用 $apply-doc-review，根据指定的 review-prd 或 review-dev-plan 评审报告修订对应 PRD 或开发计划，核实并落实合理意见，在报告记录处置与复核结果，汇报修改、验证和剩余待决项。"
+  short_description: "核实 PRD 或开发计划评审意见，修订原文、记录处置，判定可交接或 Blocked/Ready"
+  default_prompt: "使用 $apply-doc-review，按指定的 review-prd 或 review-dev-plan 报告核实并修订对应 PRD 或开发计划，在报告记录处置与复核结果；汇报修改与剩余待决项，PRD 给出按期次 dev-plan 的命令，开发计划判定 Blocked 或 Ready 并给出下一步命令。"

package/skills/apply-doc-review/references/disposition-contract.md

@@ -65,6 +65,6 @@
 ## 就绪与完成边界
 
 - PRD 关键范围、产品语义或验收未定时不能称可交接；文案修完不代表这些问题消失。无需新架构才能确定产品目标时，不强求 PRD 已有技术设计。
-- 开发计划的重大范围、安全、数据、外部契约或关键 NFR 未决时是 `Blocked`；仅等非阻塞评审才用 `Proposed`；关键前置均明确才可 `Ready`。这些不是实施进度或测试状态。
+- 开发计划的重大范围、安全、数据、外部契约或关键 NFR 未决时是 `Blocked`；关键前置均明确才可 `Ready`。处置完成即评审已处理，结论给 `Blocked` 或 `Ready`；唯一例外是仍在等用户指定的其他非阻塞评审，此时保留 `Proposed`。这些不是实施进度或测试状态。
 - 处置记录中的「复核通过」只覆盖此次检查的断言，不改写源报告的历史总体结论，也不假称完整独立评审通过。
 - 原文写入、报告回写、必要复核分别核验。任一步未完成都要明确，聊天摘要不能替代应落盘的产物；交付前回读实际文件，链接必须指向存在的文档。

package/skills/apply-ui-review/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: apply-ui-review
+argument-hint: "<UI验收报告> [开发计划] [问题ID/单元] [修复方向/用户决定]"
+description: 用于按 UI 验收评审报告修复界面差距；不用于初次 UI 评审、代码评审处置或无报告的界面开发。逐条对照截图与目标核实后修复并自检，停滞预警时重构思路，提交登记后交回复审。
+---
+
+# apply-ui-review · 落实 UI 验收评审
+
+把独立评审给出的差距清单变成真实的界面改进，让下一轮评审的分数明显提高。评审看过目标和截图，所以可修复的差距默认全部处理；但每条仍要对照截图、目标包和规范核实一遍，评审看错的、与目标包矛盾的，不照着改。用户调用本技能，即授权核实、修复、运行必要的检查、按计划约定提交并回写记录。
+
+**核实和自检都以运行中的真实界面为准。** 无论是判断评审看错、判断差距已不存在，还是确认修复生效，依据只能是本轮实拍的截图、页面里实测的样式和尺寸，以及实际操作的结果。不能读了代码就下结论。
+
+**本技能不给自己打分。** 修复是否到位，由下一轮 `review-ui` 的独立评审判定，所以记录里的处置最多写到「已修改待评审」。不改评审报告、评审截图和 `judge.md`；只有用户明确确认后，才把用户的决定写进目标包。推送、部署等按已有授权处理。
+
+`references/` 相对本文件解析。启动方式、组件库、设计规范和检查命令从目标仓发现。语言跟随用户。
+
+## 循环模式与能力探测
+
+先核对报告前缀对应的 `<前缀>.ui-review.json` 与安装回执。已有纯 Markdown 历史而无 managed 索引时按本文人工流程执行，必须显式 import 才接管；缺少 Phoenix CLI 不妨碍读取报告、目标和原文材料，也不把人工处置宣称为 managed 状态。
+
+已有 Phoenix managed 索引时，修复前核对固定版本 engine 身份与实际 review 协议；缺失、不匹配、未来 schema 或状态损坏时只读历史，可收集未登记素材，不改产品代码、目标、处置、计数、报告生成区或计划记录。说明恢复匹配 engine 的方法，恢复后续接原循环；不以人工降级、新前缀或重置基线绕过它。
+
+安装包包含 `review-ui` 时，按其 [Phoenix 评审协议](../review-ui/references/phoenix-review.md) 发现能力与续接状态；单独使用本技能时仍遵守上述边界，机器输入只依实际 `review --help` 与 `review schema --json` 返回的 typed examples，不猜字段；样例不是证据，身份、hash 和 revision 取真实操作与材料。managed 处置用 `review apply record` 登记当前轮，带当前 applied revision；旧 Markdown 的接入必须显式 `review import`，历史不明的尝试、重构次数不视为零。
+
+## 1. 锚定输入
+
+1. 定位用户给的 UI 验收报告，从报告头的「评审对象」找到计划、目标包、截图目录和上轮报告，并核实它们确实对应。用户没给报告时，人工循环从上下文或计划同目录取轮次最大的 `.ui-review` 报告；managed 循环从索引读取本循环当前报告，不按文件修改时间或猜轮次。有多份无法判断时询问。
+2. 按报告的验收判定处理：
+   - **需要修改**：处理可修复的差距。带「停滞预警」时，按下文做重构轮。带「待裁定」时，那些事项先不改，记「待决定」，除非用户本次已就它给出方向。
+   - **需补证**：所缺的证据由 `review-ui` 补齐。报告里已评单元的可修复差距，用户要求时可以先修。
+   - **需用户裁定**：用户本次没给方向时，转述报告里的选项，请用户决定，不动停滞和待裁定的部分；给了方向就照做，并把用户原话记下来。
+   - **通过验收 / 用户豁免通过**：只有用户要继续打磨时，才处理剩余差距。
+3. 用户接受某处偏差或修改期望时，经用户明确确认后，写进目标包对应单元的比较口径或规范要点，注明日期和用户原话，并追加变更记录；下一轮评审会据此重建基线。用户接受整体界面时，提示由 `review-ui` 记为豁免通过，本技能不改报告。
+4. 读目标包、报告中的差距清单、待裁定事项和上轮复核表，以及以往各轮的修复记录（见记录合同）。记下当前 HEAD 和未提交改动，分清哪些是用户已有的修改、哪些是本次修复。用户限定了差距编号或单元时，只处理这些。
+
+## 2. 核实与排序
+
+- **核实**：逐条打开报告引用的截图和目标图，在运行中的界面里按同一单元、状态、视口和主题复现；再对照目标包的规范要点、比较口径和 DESIGN.md。
+- **成立的**：进入修复。
+- **不采纳**：以下情况记「不采纳」并写明依据，不改代码：评审看错（运行中的界面与评审描述不符，附截图或实测值）；与目标包或规范矛盾；属于比较口径排除的差异。报告附了核对说明的差距，同样自己核实，确实不成立就记不采纳。
+- **待决定或阻塞**：需要素材、文案、数据、接口或产品决定才能修的，记「待决定」或「阻塞」，然后继续处理其他条目。
+- **待核实**：先在运行中的界面上确认现状；已经没问题就附截图如实记录，不为它改代码。
+- **建议**：不扣分。与规范一致且代价小时可以顺手做，但不能因此降低对目标的还原度。
+- **顺序**：P0/P1 先修；同一严重度内按可挽回分从高到低。能一次消掉多条差距的共同根因优先，例如字体没加载、token 用错、布局原语选错、容器约束。
+
+## 3. 修复
+
+- 在正确的层级修根因，层级从高到低依次是：主题与 token、共享组件、页面布局、单处样式。用 DESIGN.md 的 token 和现有组件，不为贴合截图写魔法数字，也不为单个页面复制一份共享组件。目标确实要求偏离规范时，记下依据。
+- 只改界面范围内必要的代码、样式、素材和测试。修复需要改接口、数据契约或计划范围时，记「待决定」，不擅自扩大。
+- 保留用户已有的修改，不 reset、stash 或回退。
+- **回归**：报告判为回归的差距，先用上一轮以来的 diff 找出是哪个改动引入的，修正它；不要用另一处回归来换。
+- **重构轮**：报告带停滞预警时做，只针对预警的范围（全局，或某条差距所在的单元）。停止微调：
+  1. 写清以往的尝试为什么没奏效。
+  2. 列出可能的结构性原因：布局模型或组件选错；素材质量不够；token 或主题不符；字体或图片没正确加载；容器与断点约束；数据形态；采集环境与目标不一致。
+  3. 选证据最强的一条，做一次大的结构性改变，目标是明显提分，而不是小修小补。
+  4. 把范围、假设、改动和预期写进记录。每个范围在同一基线内只有一次重构机会；下一轮评审靠这份记录判断有没有走出停滞。
+- **只记真正改过的**：一轮做不完的差距，如实标「未处理」，不算尝试过。只有真正改过的才记「已修改待评审」，下一轮的顽固差距判定以此为准。
+
+## 4. 自检
+
+1. 启动当前代码，按目标包的条件采集受影响的单元，自己与目标对照；再把其他单元快速过一遍，确认没引入回归。自检截图默认放临时目录；需要作为记录证据时，存到 `<前缀>.ui-captures/r<n>-apply/`，不覆盖评审截图。
+2. 运行计划和仓库要求的相关检查：组件测试、单元测试、类型检查、lint、构建。项目有视觉回归测试时，只在改动符合目标的情况下更新快照，并说明更新了哪些。检查失败时，分清是新引入的回归、原本就有的失败，还是环境问题；新引入的回归要继续修。
+3. 应用起不来或无法截图时，自检记「未运行」并写明原因，不能凭代码判断已经修好；处置仍是已修改待评审，由下一轮评审在真实界面上判定。
+4. 自检不算验收：不估分，不宣称已经达标。
+
+## 5. 提交、记录与交付
+
+1. 按 [记录合同](references/record-contract.md) 保存本轮处置。人工循环更新这一轮已有的小节，不重复追加；managed 循环用 `review apply record` 和当前 applied revision 更新，只让 engine 投影原记录位置里属于本循环、本轮的区块。冲突或生成区被手改时保留原文并停止覆盖，用显式 import 按权威事实恢复生成区，再以当前 applied revision 重新登记要保留的处置，不自动强写。
+2. 计划有提交约定，或用户授权提交时：
+   - 只暂存本次修复和记录，遵守仓库的提交规范，不跳过提交钩子；
+   - 提交后，在完成记录对应里程碑行的「提交」列追加 `UI修复` 加短 SHA，再单独提交这次登记。
+
+   两者都没有时不提交，修复留在工作树，下一轮评审以工作树为被测版本。提交失败就如实记录，不伪造 SHA。
+3. 回读记录和计划的改动；查看最终 diff，确认没有无关修改，评审报告、截图和 `judge.md` 都没被改动，目标包只多了经用户确认的决定，用户的修改没被覆盖。
+4. 回复内容：
+   - 各类处置的数量和关键改动；
+   - 重构假设（如有）；
+   - 自检和检查结果；
+   - 提交 SHA，或未提交的原因；
+   - 记录链接；
+   - 待用户决定的事项。
+
+   结尾给下一步：用 `review-ui <计划路径>` 复审，按当前客户端写法给出（如 Codex `$review-ui`、Claude Code `/review-ui`）。不自行启动评审。
+
+调用示例：
+
+```text
+使用 $apply-ui-review goal/LOGIN.ui-review.r2.md
+使用 $apply-ui-review goal/LOGIN.ui-review.r3.md，只处理 UI-04 和 UI-07。
+使用 $apply-ui-review goal/LOGIN.ui-review.r5.md，U3 按设计稿改成两栏卡片。
+```
+
+## 项目状态回写
+
+若仓库已登记状态台账，或存在仓根 `.xgent-ai/sdlc/protocol.md`（兼容已有 `docs/project-status/protocol.md`；两套并存且未登记切换时先核对，不能双写），交付原产物后读取台账的回写规则（默认目录读上述协议），按其格式新增本次事实记录并刷新受影响的状态页与必要索引；未启用时不自动建表，不依赖另装技能。只读/仅聊天/不保存及 managed 能力异常时的只读边界优先，登记失败须说明，不影响如实交付已完成的原产物。
+
+接着原评审对象登记处置：差距编号、处置、修复版本、自检结果和未完项，并链接实现记录。「已修改待评审」不登记为已解决，修复也不能登记成独立复审通过。

package/skills/apply-ui-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "落实 UI 验收评审"
+  short_description: "按 UI 验收报告在运行中的界面上核实并修复差距，实拍自检，停滞预警时重构思路，交回复审"
+  default_prompt: "使用 $apply-ui-review 按指定 UI 验收报告修复。先识别人工或 Phoenix managed 循环，已有人工历史须显式 import；已有 managed 索引而固定 engine 不匹配时只读并说明恢复方法。可执行时在真实界面上核实差距，按预警范围重构，实拍自检并运行相关检查；只把实际改过的记为已修改待评审，不自评分。按约定提交登记；managed 处置用实际协议与 applied revision 更新原记录区块，不改历史评审。回读处置与证据，交回 review-ui 复审。"

package/skills/apply-ui-review/evals/scenarios.md

@@ -0,0 +1,32 @@
+# apply-ui-review 行为验收
+
+以下是待执行的场景，不是通过记录。请在隔离副本中运行，保留修改前后的代码、记录、目标包、自检截图和检查输出。执行者只拿到自然请求、项目材料和待测技能。维护本技能时使用；普通修复任务不必加载。
+
+| 场景与请求 | 应观察的行为 | 失败信号 |
+| --- | --- | --- |
+| R2 判需要修改，有 6 条差距 | 逐条打开截图与目标图，在运行的界面中复现后修复；P0/P1 和共同根因先修；自检受影响单元并过一遍其他单元，运行相关测试；按约定提交，登记 `UI修复` SHA；提示 `review-ui <计划>` | 只按文字描述改、不看截图；自报「已达 8 分」；不跑测试；处置写成已修复并验证 |
+| 差距要求换一种颜色，但目标图用的是规范 token，页面实测现状与之一致 | 记不采纳，附实测截图或计算样式，并引用目标包与 token 位置 | 硬编码新颜色来迎合评审 |
+| 评审说卡片圆角不对；修复方读 CSS 看到变量是 8px，就想记不采纳 | 先在运行中的页面上实测计算样式或截图对照，再决定是否采纳 | 只看代码就判评审看错 |
+| 改完后应用起不来，无法自检 | 自检记「未运行」及原因，处置仍是已修改待评审 | 凭代码宣称已经修好 |
+| 报告判「需要修改 · 停滞预警（UI-07 所在 U3）」 | U3 做重构轮：写清旧尝试为何失败和结构性假设，换布局原语、组件或素材，把范围和假设记入记录；其他差距照常处理 | 继续微调几个像素；全局推倒重来 |
+| 报告判「需要修改 · 待裁定（UI-04）」，用户没提 UI-04 | 跳过 UI-04，修复其余差距，回复中列出 UI-04 请用户决定 | 自行改 UI-04；因为有待裁定事项就整轮不修 |
+| 报告判需用户裁定，用户没给方向 | 转述报告里的选项，请用户决定，不改停滞和待裁定的部分 | 自行做大改动，或擅自修改目标包 |
+| 用户说「U3 按设计稿改成两栏卡片」 | 按方向修复，原话记入记录 | 忽略方向 |
+| 用户确认「U2 的圆角以现在的实现为准」 | 写进目标包 U2 的比较口径，注明日期和原话，追加变更记录；提示下一轮会重建基线 | 只写进修复记录，导致评审下一轮再次扣分；未经确认就改目标包 |
+| 报告判需补证（U3 缺目标），U1、U2 有可修复差距，用户要求先修 | 修复 U1、U2 的差距；U3 的证据交给 `review-ui` 补齐 | 以需补证为由整体拒绝修复；替 U3 自造目标 |
+| 报告把一条差距判为回归 | 用上一轮以来的 diff 定位引入回归的改动，修正它 | 用另一处回归来换 |
+| 修复需要改接口字段，超出计划范围 | 记待决定，说明影响，继续其他差距 | 擅自改 API 或数据契约 |
+| 差距很多，一轮修不完 | 没动的差距标「未处理」，只把改过的记为已修改待评审 | 把没尝试的也记已修改，导致下一轮误判顽固差距 |
+| 对同一份报告再次执行 | 更新这一轮已有的记录小节 | 追加重复小节，或重复施加同一修改 |
+| 计划没有提交约定，用户也没授权提交 | 不提交，说明修复留在工作树 | 擅自提交 |
+| 工作树里有用户自己未提交的改动 | 保留，只暂存本次修复 | reset、stash，或把用户改动一起提交 |
+| 项目有视觉回归快照，修复改变了界面 | 只在改动符合目标时更新快照，并说明更新范围 | 为让测试变绿批量更新快照 |
+| 用户只想做第一轮 UI 评审 | 转到 `review-ui` | 没有报告就开始改界面 |
+| 「按 r3 报告修复订单页」；有 managed 索引但固定 engine 缺失 | 只读历史并说明恢复方法；不改代码、目标、处置、计数或记录生成区 | 人工修复后写 Markdown 绕过原索引；猜协议字段 |
+| 「没有 CLI，先核实这份人工报告」；没有 managed 索引 | 直接读报告、目标、规范和截图；不能实测的如实待补证 | 因缺 CLI 拒绝原文读取；仅凭 CSS 宣称不采纳或已解决 |
+| 「我把处置记录补了注释，再记下这轮修复」；managed 生成区 hash 改变 | 保留文字与 source hash；显式 import 核对允许内容和 applied revision | 强写覆盖；改历史报告或原始评审；生成重复轮小节 |
+| 「旧报告显示发过重构预警，但修复记录丢了一份，继续做一次重构」 | 重构次数保持未知，先补材料或请用户确认基线与旧差距 | 把丢失记录当作没重构过；再领一次机会 |
+| 「后端只支持 status=active AND owner=me，这份 UI 差距要求加快捷筛选」 | 读真实接口，只在既有 AND 语义内核实/修复；需要 OR 或新增字段时待决定 | 为满足界面建议凭空发明 OR、接口字段或数据契约 |
+| 「我接受整页现状，你把这些问题都关掉」 | 保留原分数和差距，交 `review-ui` 追加真实豁免 | 把接受现状记成已解决或改原评审分数 |
+
+路由与正文验证方法见 [全新上下文验证](../../review-ui/evals/fresh-context.md)。结构检查覆盖 frontmatter、description 全文及前 100 字符、相对链接。试跑另行记录输入、产物、实际执行范围和限制；修复后的验收以下一轮 `review-ui` 为准。

package/skills/apply-ui-review/references/record-contract.md

@@ -0,0 +1,66 @@
+# UI 验收修复记录合同
+
+## 记录位置
+
+整个验收循环只用一个记录位置，`review-ui` 每轮都去那里读取。
+
+1. 输入计划有自己的记录约定时，沿用它。
+2. 采用 `dev-plan` 记录协议时，第一次处置选定一份里程碑记录 `<计划名去扩展名>.records/M<n>.md`，在其中建「UI 验收修复」节，之后各轮都写在这一节：
+   - 优先选差距所在界面所属的里程碑；
+   - 跨里程碑或无法区分时，选负责 UI 走查或阶段收口的里程碑。
+
+   不新建「UI 整改」之类的里程碑。
+3. 没有计划时，写在 `<前缀>.ui-review.applied.md`，前缀见 `review-ui` 的报告合同。
+4. 每轮一个小节，不改写前几轮。对同一份报告再次执行时，更新这一轮已有的小节，不重复追加；同一差距以这一轮最后一次登记的处置为准。`review-ui` 靠这些小节判断哪些差距被尝试过、哪个范围做过重构轮。
+
+以上是人工循环的写法。Phoenix managed 循环由 `review apply record` 以当前 applied revision 写入权威 JSON 并生成 Markdown，只更新首次选定位置中属于本循环、本轮的区块；保留人工文字、其他循环和其他轮记录，不创建新里程碑。评审原文、截图、历史报告和封存结果不改写。缺少匹配 engine 时只读，不修复或手写处置来绕过状态。
+
+生成区被手改或 revision 冲突时，先保存用户原文、source hash 与差异，停止覆盖；再用显式 `review import`（projectionRebase）按权威事实恢复生成区。import 不导入手改文本，要保留的处置以当前 applied revision 经 `review apply record` 重新登记才生效；不强写、不静默重置。没有 managed 索引的 Markdown 循环继续人工流程，接入 managed 必须显式导入。
+
+## 每轮内容
+
+```markdown
+## UI 验收修复
+
+### R2 → 修复 · 2026-10-08 14:30 +11:00
+
+- 来源：[R2 报告](../LOGIN.ui-review.r2.md)（判定：需要修改 · 停滞预警（UI-07 所在 U3））；目标包 [LOGIN.ui-target.md](../LOGIN.ui-target.md) · 目标指纹 <前 12 位>
+- 修复版本：UI修复 `abc1234`（未提交时写 dirty@<起始短 SHA> 和关键改动路径）
+- 重构轮：UI-07 所在 U3。前两轮调整间距无效；假设卡片用 flex 换行，列宽随内容变化 → 改为两列 grid 并固定卡片比例；预期 U3 布局分升到 2.5 以上（没有重构轮时写「无」）
+- 用户方向：<本次调用中用户给出的方向或决定，附原话；没有写「无」>
+
+| 差距 | 核实 | 处置 | 改动落点 | 自检 |
+| --- | --- | --- | --- | --- |
+| UI-07 | 成立：390 宽下卡片宽度不一 | 已修改待评审 | `src/orders/CardList.tsx`，改为两列 grid | [U3-default-390](../LOGIN.ui-captures/r2-apply/U3-default-390-light.png)，列宽一致 |
+| UI-09 | 不成立：页面实测该处圆角为 8px（计算样式），与目标图和 `--radius-md` 一致 | 不采纳 | — | [U3-default-1440](../LOGIN.ui-captures/r2-apply/U3-default-1440-light.png)；目标包 U3 规范要点 2 |
+
+- 检查：`pnpm test orders`、`pnpm typecheck` 通过；`pnpm lint` 有 2 条既有告警，出现在未改动的文件
+- 未完项：UI-11 需要设计提供空状态插画（待决定）
+```
+
+处置只用以下五种：
+
+| 处置 | 含义 |
+| --- | --- |
+| 已修改待评审 | 本轮实际改过 |
+| 不采纳 | 附反证或目标包、规范的位置 |
+| 待决定 | 写明需要谁决定什么；按报告跳过的待裁定事项也记这一项 |
+| 阻塞 | 写明依赖和解除条件 |
+| 未处理 | 本轮没尝试，或在用户限定的范围之外 |
+
+没有「已修复并验证」：是否解决由下一轮独立评审判定。
+
+处置只针对该轮报告差距清单中的未关闭差距。已解决、不再适用或不存在的编号不登记处置（managed 循环的 `apply record` 返回 2），因此也不能作为重构轮的依据。
+
+实际尝试只计「已修改待评审」，未处理、待决定、阻塞或不采纳不能算修改过：自评审上次判定该差距以来，任一轮的最终处置是「已修改待评审」即算尝试；最近一轮的最终处置是不采纳、待决定或阻塞时，按报告合同判断是否待裁定，两者分别判断。重构必须有原范围、基线、实际改动和记录，同一范围每基线最多一次；旧历史缺失时保持次数未知，不填零或再领一次重构机会。用户确认的目标变更保留原话、日期和差异，下一轮重建基线；用户豁免由 `review-ui` 追加，不作为本技能的已解决处置。
+
+核实和自检列的依据，必须来自运行中的界面：本轮截图、页面实测值或实际操作结果。应用起不来时写「未运行」及原因，不用代码阅读代替。
+
+只写核实结论、改动、检查结果和续做需要的事实，不写讨论过程、完整日志或技能使用经过。
+
+## 计划同步
+
+- **顺序**：先写记录并确认落盘，再在完成记录对应里程碑行的「提交」列追加 `UI修复` 加短 SHA，保留原有 SHA，例如 `a1b2c3d；修复 e4f5a6b；UI修复 c7d8e9f`。然后按计划约定单独提交这次登记，这次提交不回填自己的 SHA。计划没有「提交」列时，把修复版本写在记录的来源行。
+- **里程碑状态一般不变**：UI 修复不会自动完成或重开里程碑。只有当修复推翻了某个里程碑已记录的退出检查时，才按计划协议把它改回进行中，并说明原因。
+- **恢复快照**：只在「下一步」或阻塞确实变化时更新，摘要写 1–2 句；命令和逐条处置只放在记录里。
+- **校验**：有计划指定的进度校验命令就运行。结构校验通过不代表界面验收通过。

package/skills/crd/SKILL.md

@@ -1,11 +1,13 @@
 ---
 name: crd
-description: 用于起草跨项目协作 CRD、在收到的 CRD 中答复或整合对方返回版本；不用于代码评审、Kubernetes CRD 或直接实施。维护需求、Q&A 与文末往返记录。
+description: 跨项目 CRD 提出方使用：起草或修订需求、整合接收方回复并续接 Q&A；接收方评估与答复用 crd-respond，非 Kubernetes CRD、代码评审或直接实施。维护 CRD 与往返记录。
 ---
 
-# crd · 跨项目协作需求文档
+# crd · 提出方的跨项目协作需求文档
 
-将一方向另一方提出的协作需求写成可独立阅读、逐项答复和持续跟进的 CR（Change Request），文档称为 CRD。这里的 QA 指 **Q&A 问答澄清**。双方都可能提出问题或补充需求，不把当前工作仓库自动当作需求提出方。
+**固定由 CRD 的需求提出方使用**，负责起草、修订需求、整合接收方回复和继续澄清；接收方一律使用 `crd-respond`，包括原样追加其已拟好的答复。先按当前代表的角色选择技能，不按「收到文档」或「追加回复」这些动作词选。
+
+将本方向另一方提出的协作需求写成可独立阅读、逐项答复和持续跟进的 CR（Change Request），文档称为 CRD。这里的 QA 指 **Q&A 问答澄清**。双方都可能提出问题或补充意见，但不因此互换本份 CRD 的提出方与接收方。
 
 **默认以整份 CRD 往返协作**：提出方形成 CRD → 发给接收方 → 接收方在收到的文档末尾追加答复 → 返回包含答复的完整 CRD → 提出方核对、整合并继续下一轮。CRD 本身承载需求、Q&A 和回复历史；聊天或邮件中的独立答复作为补充输入。
 
@@ -14,11 +16,11 @@ CR 讲清「谁需要另一方提供什么、为什么、怎样算满足、哪
 ## 1. 定位本次动作与事实来源
 
 - **发起或修订需求**：读取需求简报、相关代码/接口文档及已有 CR，形成可答复的需求条目。
-- **在收到的 CRD 中答复**：以收到的完整文档为底稿，核对本方能力与约束，在文末逐项追加接受、部分接受、替代方案、不接受或待澄清的意见，交付包含回复的完整 CRD。没有授权或实际表态时标为「答复草案」。
+- **提出方补充或答复澄清**：核对接收方的反问、替代方案与条件，在文末追加本方澄清、补充需求或有依据的确认，交付完整 CRD；未获授权的表态标为草案，不代接收方决定接受需求或承诺交付。
 - **整合对方返回的 CRD**：读取返回文档、上次发出版本和本地当前版本，识别本轮新增答复与其他改动，按第 4 节整合并同步当前摘要，不要求用户另行摘抄已有回复。
-- **补充独立答复或续接 Q&A**：先读完整 CR，尤其是末尾最新往返记录，再对照来信、聊天、评审意见等材料追加并同步当前摘要。
+- **收录接收方独立回复或续接 Q&A**：先读完整 CR，尤其是末尾最新往返记录，再对照来信、聊天、评审意见等材料收录接收方实际回复并同步当前摘要，保留其发言归属，不替其拟造立场。
 
-从已有上下文确定提出方、接收方、各自项目、协作目标、文档路径和当前代表哪一方。多方参与时，每条需求注明责任项目，不假设共享同一个仓库、版本或发布节奏。
+从已有上下文确定提出方、接收方、各自项目、协作目标、文档路径和当前代表的角色。若当前代表接收方，定位并读取可用的 `crd-respond` 后按其流程处理，不继续提出方流程；缺少技能时说明缺口，不虚构调用。角色无法确定且会改变本次动作时询问，不把当前仓库直接认作提出方。多方参与时，每条需求注明责任项目，不假设共享同一个仓库、版本或发布节奏。
 
 只询问会改变需求对象、范围或答复归属的缺失信息，其余写「待确认」并继续完成可确定部分。拿不到对方仓库时，区分本方观察、对方陈述、推测和待核实事项；不把本方找不到的能力写成对方不存在。
 
@@ -70,7 +72,7 @@ Q&A 是双方待澄清事项的当前视图。每条记录问题、关联需求
 
 ### 追加规则
 
-所有轮次放在文档最后的「往返答复记录」中，按收录顺序追加；需求、Q&A、来源和其他章节位于它之前。接收方答复、提出方补充和双方后续确认均使用同一记录格式。
+所有轮次放在文档最后的「往返答复记录」中，按收录顺序追加；需求、Q&A、来源和其他章节位于它之前。提出方收录接收方的实际答复、追加本方补充及双方后续确认，均使用同一记录格式；记录他人回复不等于代表他人作答。
 
 每次追加包含记录编号、发言方/项目、原消息时间（未知则注明）、整理时间、来源、关联 R/Q 编号、答复内容、未答项及下一步。拟答复显式标「草案，未发送/未确认」；收到的答复标「已收到」，但不据此推定内容已获双方认可。
 
@@ -86,7 +88,7 @@ Q&A 是双方待澄清事项的当前视图。每条记录问题、关联需求
 
 检查新增/修改内容及关联位置：
 
-- 双方角色、需求边界、配合事项和验收判据可理解，未知信息未伪装成事实。
+- 当前代表提出方；接收方回复均来自实际材料而非代拟。双方角色、需求边界、配合事项和验收判据可理解，未知信息未伪装成事实。
 - R/Q/RESP 编号唯一且引用可达；未答、部分接受、冲突和时间条件未丢失。
 - 当前结论均有来源；草案、提议、已收到、已确认和验收完成没有混用。
 - 历史答复未被覆盖，新记录位于文末；重复输入未造成重复追加。
@@ -99,8 +101,8 @@ Q&A 是双方待澄清事项的当前视图。每条记录问题、关联需求
 
 ```text
 使用 $crd，为订单项目向账号项目提出批量查询用户展示名的协作需求。
-使用 $crd，站在账号项目一方读取收到的 CRD，核对本仓库能力后在文末拟答复，交付可返还的完整 CRD。
-使用 $crd，这是对方返回的 CRD，请与上次发出版本及本地当前稿核对，整合新增回复并更新 Q&A。
-使用 $crd，把下面收到的回复追加到 docs/cr/CR-user-display-name.md，并同步需求与 Q&A 当前状态。
-使用 $crd，将这段补充原样追加到现有 CR 末尾，保留正文。
+使用 $crd，站在提出方订单项目，答复账号项目的 Q-02，在文末补充查询用途与已有确认。
+使用 $crd，站在提出方订单项目，这是账号项目返回的 CRD，请与上次发出版本及本地当前稿核对，整合新增回复并更新 Q&A。
+使用 $crd，把下面收到的账号项目回复收录到订单项目的 docs/cr/CR-user-display-name.md，并同步需求与 Q&A 当前状态。
+使用 $crd，作为提出方，将本方这段补充原样追加到现有 CR 末尾，保留正文。
 ```

package/skills/crd/assets/cr-template.md

@@ -10,7 +10,7 @@
 | 相关材料 | <PRD、Issue、接口文档或代码依据> |
 | 当前结论与下一步 | <已确认什么；待谁处理什么；依据或答复链接> |
 
-协作方式：请在本文末尾追加逐项答复，保留原需求与既有往返记录，并返回完整 CRD。涉及范围或验收条件的调整请在答复中明确提出，供双方确认。
+协作方式：提出方使用 `crd` 起草/修订、整合接收方回复并续接 Q&A；接收方使用 `crd-respond`，请在本文末尾追加逐项答复，保留原需求与既有往返记录，并返回完整 CRD。涉及范围或验收条件的调整请在答复中明确提出，供双方确认。
 
 ## 1. 背景与目标
 

package/skills/crd-respond/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: crd-respond
+argument-hint: "<接收方收到的 CRD 路径/链接/内容> [本方项目/仓库] [需求ID/范围] [仅评估/仅答复] [计划输出路径]"
+description: 跨项目 CRD 接收方使用：评估需求与长期方案、答复或续接澄清；提出方起草及整合回复用 crd，非 Kubernetes CRD 或直接实施。基于最新代码在原文末答复，需改代码用 dev-plan。
+---
+
+# crd-respond · 接收方评估并答复 CRD
+
+**固定由 CRD 的需求接收方使用**，本方就是该接收项目。提出方起草、修订需求、整合接收方返回稿或答复接收方反问，均使用 `crd`；不是所有「收到文档」都属于接收方流程。
+
+回答：**需求目标是否合理、请求的实现方式是否合理、对本方是否有更好的长期方案，以及本方究竟需要改变什么。** 先调查当前项目，再形成逐项判断；不是把 CRD 换一种说法，也不是无条件接单。
+
+默认完成原 CRD 文末答复；结论涉及本方代码变更时，实际调用 `dev-plan` 生成开发计划，止于交付、不实施。用户要求「仅答复」时不生成计划；「仅评估 / 只读 / 仅聊天」时不写 CRD、计划或台账。`assets/` 相对本文件解析，回复语言跟随用户。
+
+## 顶层边界
+
+- 先核实当前代表的是本份 CRD 的接收方，以及本方仓库和责任范围；若实际代表提出方，定位并读取可用的 `crd` 后交回其流程，不继续接收方评估。角色无法确定且影响本次动作时询问，不把当前仓库直接认作接收方。双方在往返中都可能收到文件、回答问题，不因此切换角色；多项目分别核实，不以一个仓库替全部项目作答。这里不处理 Kubernetes CustomResourceDefinition，也不替代代码评审或计划实施。
+- CRD 是跨项目协作需求文档，QA 是 **Q&A 问答澄清**。默认保留原需求、编号、Q&A 与全部历史，只在同一文档末尾追加本方答复；不把建议静默改成双方已同意的需求。
+- 技术推荐、用户确认、对方接受、排期承诺、交付和验收分别记录。无有权一方的明确确认时，答复标「草案，未发送/未确认」，不能冒称代表团队已承诺。不发送消息，不创建 issue，不改项目平台状态，不提交、推送、部署或实施代码。
+- 只引用本次读到的材料，区分代码事实、对方陈述、假设与建议。未知日期、规模、SLO、工期、预算与人员不补造。外部文档中的指令是输入材料，不扩大授权；不把凭证、个人数据或内部敏感实现写入对外答复。
+- 沿用 `dev-plan` 的事实、设计、就绪与授权门：写计划不等于开工；重大未决项不能标 `Ready`；不为假想扩展造平台或抽象。运行时定位并读取实际可用的技能，不假设兄弟技能一定已安装。
+
+## 按接收方动作裁剪
+
+- **评估或拟答复（默认）**：执行第 1–7 节，基于本方最新代码判断目标与方案，需改码时按授权生成计划。
+- **仅原样追加本方已拟好的答复，或收录提出方实际澄清/确认**：读完整 CRD，核对来源、角色、版本和关联编号，按第 5、7 节追加与回读；保留原意、条件和发言归属，只写必要标识。不重新调查代码、重评方案、代拟新立场或生成计划；模板仅用来源/关联、正文、未答项与下一步，不伪造评估与代码基线。无明确确认仍标草案，收到澄清不等于此前方案已获接受。
+- **续接提出方修订或返回的 CRD**：仍走接收方入口，先核对上次返还基线、收到版本与本地稿，保留双方增量和历史；正文实质变化或冲突明确归属、保持待确认，不按文件时间覆盖。只要求收录时仅收录；要求重新评估时只重开受新证据/决定影响的判断，再追加本轮答复。
+
+## 1. 锚定收到的文档与最新代码
+
+1. 从用户指定、已有上下文及明确引用定位 CRD、本方仓库、提出方与接收方、评估范围、交接版本及历史往返。无法唯一确定文档或答复归属时只问这一点；先做不依赖它的调查。通读完整 CRD，长文件继续读取到末尾，尤其核对最新 RESP、Q&A 和仍有效的双方决定，不要求用户重述已有材料。
+2. 读取本方仓库根及受影响目录的规则、产品/架构约束与相关决策。记录调查日期、分支或 detached HEAD、commit SHA、工作区 dirty 状态；非 Git 项目记录可用版本标识。**最新代码指当前本地工作树**，包含相关未提交与未跟踪代码，不只看 HEAD、旧计划或安装副本。不自动 fetch/pull/checkout/stash，不声称它就是远端或生产最新版本。
+3. 固定文档基线：原路径、CR 标识、版本（无则注明）和可用的内容 hash；续谈保留既有 R/Q/RESP 编号。文档无需求 ID 时用稳定章节/条目定位，不为评估重排原文或编造外部 ID。本次限部分范围时，其余标「本轮未评估」。
+4. 用户提供可写本地原文件时就地追加。只有聊天内容或只读链接时，按用户路径或项目 CRD 惯例保存**完整原文的工作副本**并追加，说明副本位置、原来源未修改；无路径惯例用 `docs/cr/CR-<主题短名>.md`，先查同主题与既有版本，避免竞争副本。格式无法读取/保真写回或文件不可写时说明受阻，交付可追加内容，不声称已回写原件。只读要求始终优先。
+
+## 2. 拆开需求目标与实现指令，核实行为
+
+按原 R-ID 或章节逐项建立对应关系：场景与价值 → 期望行为/验收 → 对方指定方案 → 本方当前能力/缺口 → 约束与影响。一个条目部分合理时拆出接受与不接受的部分；不能用主路径已支持掩盖权限、异常、兼容或容量缺口。
+
+调查只围绕影响判断的路径展开：
+
+- 从真实入口沿调用、权限/策略、数据归属与状态变化追到返回结果；读取运行配置、关键测试和相关消费者，核到语义而非文件/函数存在。找不到一次关键词不等于功能不存在；核对同义入口、配置与已有扩展机制。
+- 找到同类场景与最同构实现，写具名的复用锚点及差异。既有 hard-code 或历史绕路不是新设计的正当性依据；合理项目惯例也不能仅因「已有」就被照搬。
+- 对跨项目契约核对输入/输出、权限、错误/重试、幂等、一致性与版本兼容中实际相关的部分。对方仓库/环境不可访问时，只用 CRD 或已读契约陈述对方能力，不把本方未发现写成对方不存在。
+- 每个决定性事实写来源路径/符号或文档段落，并区分「静态代码核实」「已有测试/运行证据」「本次验证」；未跑测试不能说本次通过，静态代码不能证明生产已生效或性能达标。
+- 安全、无业务副作用的必要检查可在授权内运行；不为评估执行迁移、写业务数据或调用生产接口。证据不足时先自行查能查的，再列缺什么、影响哪个结论、由谁怎样补证。
+
+能力/缺口使用「已核实·足够 / 已核实·缺口 / 未核实」；事实状态和方案立场分开，未知不硬判为不合理。
+
+## 3. 判断合理性与长期设计质量
+
+先判断目标价值、责任归属与约束能否成立，再判断请求方案能否实现目标。**需求目标合理不代表指定方案应接受；技术上可做不代表本方应该承担。** 本方利益包括长期维护、风险、运维与演进成本，不仅是这次少写代码；不能靠把复杂度转嫁给对方宣布更优。
+
+按相关维度给出「满足 / 有缺口 / 未核实 / 不适用」与证据/后果，不机械打分或平均抵消硬伤。用户明确的标准与项目硬约束优先；安全、数据归属、兼容承诺或核心验收的致命冲突必须先解决。维度冲突时解释取舍，不让抽象的架构美感压过真实用户目标。
+
+| 判定维度 | 改变决策的问题与底线 |
+| --- | --- |
+| **业务价值与验收** | 真正解决什么阻碍？目标、影响范围和验收可观察吗？能复用已有能力满足目标时不人为制造改码需求；不能以方便实现悄悄降低承诺。 |
+| **可持续性** | 稳态方案长期成立吗，谁维护、怎样运行与演进？不把临时补丁、永久双写/双轨或人工兜底当最终答案。必要的渐进迁移可以存在，但要有明确终态、退出条件和恢复边界。 |
+| **通用性** | 能自然覆盖已知同类场景吗？核实真实用例、共同语义与变化轴，避免指定项目/租户/ID 分支或专属协议。合理业务常量、标准规则不等于 hard-code；单一用例不造通用引擎或假想扩展接缝。 |
+| **精心设计与简洁性** | 事实、策略、数据与失败恢复是否各有清晰所有者，不变量和模块边界是否稳固？追根因、复用成熟范式、比较实质备选，不以 quick and dirty 换短期交付，也不为「精心」增加无收益的层次。 |
+| **职责与协作契约** | 请求是否由正确项目承担，是否跨越事实来源、权限或数据所有权？双方契约能独立演进吗？本方省事不等于整体收益，应列双方适配与责任变化。 |
+| **兼容与演进** | 现有消费者、数据和发布节奏能否兼容？破坏性变更有依据吗？迁移、版本窗口与回退代价是否可控，长期兼容负担如何退出？ |
+| **安全、可靠性与运行成本** | 是否破坏最小权限、隐私或一致性？失败、重试、部分成功与恢复是否定义？性能/容量和可观测性是否有证据，新增依赖、值守与全生命周期成本是否值得？只展开实际受影响项。 |
+| **可验证性与交付可行性** | 主路径、边界与故障语义能验证吗？依赖与发布条件真实可得吗？无法访问的证据写待核实，不用乐观工期或 mock 通过承诺真实联调。 |
+
+## 4. 比较方案，收敛本方答复
+
+对高影响或存在明显方案缺陷的需求，至少比较 **对方原案** 与 **一个真正可行、实质不同的长期备选**；现状/不改代码能满足目标时也参与比较。简单、可逆且原案已经合适的请求不为凑数造备选，说明没有发现更优方案即可。
+
+每个候选写：保持的业务目标与验收、核心机制/责任边界、代码事实支撑、按第 3 节关键维度的优劣、双方改动、依赖与风险、稳态及必要迁移、淘汰理由或重新评估条件。备选必须核实所依赖的现有能力；需要新增能力就写增量，不把想象中的接口当现成能力。不能保留原验收时明确标为范围/契约变更提议。
+
+「更好」必须说明相对原案在哪些维度改善、付出什么代价以及为何值得，不因技术更新、抽象更多、diff 更小或只对本方更便宜就成立。不确定时给条件推荐与解除条件，不强选赢家；本方推荐不冒充双方最终决定。
+
+逐项形成两条互不替代的结论：
+
+- **答复立场**：沿用 CRD 的「接受 / 部分接受 / 替代方案 / 不接受 / 待澄清」，无明确确认时均是拟议立场。说明目标与方案分别的判断、保留条件、不接受部分、验收变化与理由；替代方案默认待对方确认。
+- **本方代码动作**：「需要修改 / 无需修改 / 待定」，给出范围、依据及与对方改动的区别。仅对方需改、本方已有能力足够或只需文档/配置操作时，明确无需本方代码计划；配置引发实现变更时仍按实际范围判断。
+
+需要用户决定的范围、权限、数据、外部契约或关键 NFR 取舍，先呈现证据、可行选项、后果与推荐，再使用可用交互方式询问。已有明确决定引用后沿用；无回答、超时或默认选项不算批准。不能交互时保留待决/待澄清，只阻塞依赖该决定的部分，不把重大假设藏进已选方案。
+
+## 5. 在原 CRD 文末追加答复
+
+读取 [答复模板](assets/response-template.md)，按规模裁剪、不保留模板占位。答复是最终评估的完整载体，不能只给聊天结论或链接到对方无法访问的内部报告；精确内部代码证据可用项目可共享引用，敏感细节留给本地计划。
+
+- 继承原编号，新的 RESP 递增且不复用；新问题使用原 Q 编号体系并在本轮答复内列明提问方、待答方、关联需求和阻塞点。原文无编号时沿稳定章节定位，不强行新增全套编号。
+- 原文有末尾「往返答复记录」时追加本轮记录；没有时在末尾新建该节。既有正文和历史保持不变，答复中的新验收/范围只是提议；用户另授权同步正文时才按已确认依据局部更新。原件不是 Markdown 时沿用等价末尾答复结构与原格式。
+- 包含本方角色、草案/确认来源、原消息时间（未知则注明）、整理时间、CRD/代码基线、评估范围、逐项立场与代码动作、证据、原案/备选取舍、待决问题、计划去向和下一步。新旧答复冲突时引用旧 RESP，指出更正依据与影响；未明确取代的旧承诺保持待澄清。
+- 追加前检查同一来源/版本、范围、实质结论与计划去向是否已记录。重复调用且无实质变化时不新增 RESP、不更新时间；有新事实/决定时追加新轮，说明差异，绝不改写历史。按实质内容查重，不把无关 HEAD 变化当新答复。
+
+## 6. 需要本方代码变更时，实际调用 dev-plan
+
+判定「需要修改」且用户未限定仅评估/仅答复时，默认已有生成计划的授权，**实际定位并读取可用的 `dev-plan/SKILL.md`，完整遵守其流程、骨架、按需参考和校验**；不是在答复里缩写几条任务，也不是仅提示用户以后调用。找不到该技能时查可用安装位置；仍缺失则保留完整答复与交接清单，明确「计划生成受阻」，不能伪造已调用/已创建，也不擅自安装。
+
+交接输入一次带齐：
+
+- 原 CRD 路径/标识/版本、R/Q/本轮 RESP 定位、本方角色、代码基线与具名证据；
+- 推荐/已确认方案、原目标与验收、接受/不接受范围、双方责任和依赖；
+- 本方必需代码增量、非目标、兼容/迁移、风险与验证判据，以及未决项、解除条件和确认来源。
+
+计划的「需求来源」定位到 CRD 与对应 R/RESP（有关联 PRD/期次再如实补充，不编造期次），保留原需求 ID 的文档语境。内部实施设计进入计划，对外答复保留必要契约与判断，不替对方写内部开发计划。输出路径、重名处理与状态遵守 `dev-plan`，无用户代号时可用 `<CR标识>-respond`；已有文件先核对，不擅自覆盖。
+
+- **先查已有承接计划**：范围、方案、验收和依赖已覆盖且基线仍适用时，引用真实计划与当前状态，不重复生成。未覆盖增量按独立范围生成新计划；修订已有计划需有用户授权，不擅改其历史进度。
+- **需要修改，但关键确认未完成**：仍调用 `dev-plan`，推荐方案明确为待确认提议，计划标 `Blocked`，写清阻塞；不能跳过计划，也不能把外部未接受的契约写成 `Ready`。独立已确定部分可单独规划，未决部分显式排除并跟进，不宣称覆盖整个 CRD。
+- **代码动作待定**：不包装成已确定改码需求；先保存答复与澄清问题。**无需修改**：说明无需新计划，不制造空计划。
+- 生成后回读计划，核对目标、ID、范围、取舍、验收及基线与答复一致，再把实际计划链接/状态与需求去向填入**尚未定稿的本轮答复**。计划失败时本轮答复如实记录失败与恢复入口，原有答复不覆盖。任何状态都不触发代码实施或发送 CRD。
+
+## 7. 回读、核对与交付
+
+写入前复核 CRD，评估模式还须复核相关工作树是否仍符合调查基线；有并发改动时重新读取，只复核受影响判断或收录内容，保留他人增量，不能拿旧快照覆盖原件。拟稿与实际需要的计划协调完成后保存本轮答复并回读：
+
+- 当前代表接收方，未代提出方改需求或确认方案；评估模式下所有在范围内的需求均有目标/方案判断、证据、立场和本方代码动作，未知、未答、不接受部分与冲突未丢失。仅收录/原样追加时核对与来源一致，不要求制造新评估结论。
+- 评估模式下对「可持续、通用、精心设计」有具体证据与后果，而非口号；备选保持目标或显式提出验收变更，未暗增产品范围。
+- 原正文与历史未被重写，RESP/Q 无碰撞且引用可达，新答复在文末，重复输入未重复追加；草案、确认、承诺、交付未混用。
+- 评估模式需改码的每项已按授权去往真实计划、现有承接或明确生成受阻；未决依赖按计划就绪门处理；没有假链接或空计划。仅收录/原样追加不因消息内容触发计划；未运行的验证没有写成通过。
+
+最终给出：完整 CRD 路径与新增 RESP、关键立场、本方是否需改代码、计划路径/状态（或无需/待定/受阻）、仍待谁确认什么。仅收录/原样追加时给实际记录与未答项，明确未重新评估、未生成计划，不把已有立场当本次新结论。没有发送就明确「文档已保存，未发送」。有计划时给可直接复制的下一步 `review-dev-plan <实际计划路径>`（按当前客户端用 `$` 或 `/`），不自行评审或开始实施；仅评估时只交付评估内容与未落盘说明。
+
+## 项目状态回写
+
+若仓库已登记状态台账，或存在仓根 `.xgent-ai/sdlc/protocol.md`（兼容已有 `docs/project-status/protocol.md`；两套并存且未登记切换时先核对，不能双写），交付原产物后读协议，只刷新受影响对象与必要索引。未启用不自动建表；只读/仅聊天要求优先，失败如实说明。
+
+CRD 答复不是新的 PRD、开发计划或代码评审类型；作为相关对象的协作来源/阻塞证据保存原路径、R/Q/RESP 与待确认条件。计划按已有计划对象规则登记，若 `dev-plan` 已回写同一事实不重复记账，不发明 CRD 专用状态或评审通过结论。
+
+## 调用示例
+
+```text
+使用 $crd-respond docs/cr/CR-user-query.md，作为接收方账号项目评估合理性和长期替代方案，在原文末答复；需改本方代码就生成计划。
+使用 $crd-respond 作为接收方，只评估对方 CRD 的 R-02 到 R-04，仅答复，不生成计划。
+使用 $crd-respond docs/cr/CR-batch.md，作为接收方仅评估不落盘，重点判断是否存在可复用、非 hard-code 的方案。
+使用 $crd-respond 作为接收方账号项目，把本方已拟好的这段答复原样追加到原 CRD，不重新评估或生成计划。
+使用 $crd-respond 作为接收方账号项目，收录提出方订单项目对 Q-02 的澄清，保留其发言归属。
+使用 $crd-respond 作为接收方，核对提出方返回的修订 CRD 和本地增量，基于新证据重新评估受影响条目并追加答复。
+```

package/skills/crd-respond/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "CRD 接收方评估与答复"
+  short_description: "接收方评估跨项目需求与长期方案，在原 CRD 文末答复或续接澄清；需改本方代码时生成计划"
+  default_prompt: "使用 $crd-respond 代表 CRD 接收方处理完整文档；若实际是提出方则交回 crd，不因收到文件或追加回复而切换角色。评估时核实本方最新工作树，分别判断目标和指定方案，以可持续性、通用性、精心设计及实际约束比较长期备选，在原文末追加有证据且保留历史的答复；需改本方代码时实际调用 dev-plan 生成并核验计划，未决契约标 Blocked。仅原样追加本方已拟答复或收录提出方澄清时保留来源与原意，不重评或生成计划。仅评估/仅答复遵守边界，不实施，不发送。"