@xgent-ai/skills 0.5.0 → 0.7.0

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/archify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: archify
-description: Create polished, validated architecture, workflow, sequence, data-flow, and lifecycle/state diagrams as explorable standalone HTML with inline SVG, dark/light themes, optional trace motion, and PNG/JPEG/WebP/SVG/WebM export. Accept plain-language requirements or pasted Mermaid flowchart, sequenceDiagram, and stateDiagram input; inspect repository evidence when the diagram must reflect real code. Use when the user asks to visualize system architecture, infrastructure, cloud/security/network topology, technical workflows, API call sequences, request lifecycles, data pipelines, ETL/ELT, data lineage, state machines, or to convert/beautify Mermaid.
+description: Use when diagramming architecture, workflow, sequence, data-flow, lifecycle, or converting Mermaid. Create validated, interactive diagrams as standalone HTML with image and video export.
 license: MIT
 metadata:
   version: "2.17"

package/skills/architect/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: architect
-description: "Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape."
+description: "Use for /architect or complex design work needing structure before code. Sketch types, signatures and module boundaries, then guide implementation."
 disable-model-invocation: true
 ---
 

package/skills/arena/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: arena
-description: "Compatibility entry for agi-mode Arena: generate independent candidates, compare them, select a base and verify a synthesis. Use for /arena, 'arena this', or an explicit request for competing designs."
+description: "Use for /arena or explicit requests for competing designs. Routes to agi-mode Arena to compare independent candidates and verify the synthesis."
 disable-model-invocation: true
 ---
 

package/skills/automate-me/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: automate-me
-description: "Use for \"automate me\", \"create/update/refresh my -mode skill\", \"turn/capture my preferences or working style into a skill\", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via create-skill + unslop, optionally pulling fresh evidence from recent transcripts."
+description: "Use for creating or updating a personal -mode skill from user preferences and working habits, including requests to automate me."
 disable-model-invocation: true
 ---
 

package/skills/autoresearch/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: autoresearch
-description: 'Compatibility entry for agi-mode hillclimbing: autonomous, measured improvement of code, skills, prompts or agent workflows. Use for autoresearch, continuous optimization and iterative experiments; not one-shot edits or review-only tasks.'
+description: 'Use for measured, iterative optimization; skip one-shot edits and review-only tasks. Routes to agi-mode Hillclimb for experiments on code, skills, prompts or agent workflows.'
 license: MIT
 compatibility: Requires agi-mode to be installed alongside this entry and a runnable measurement path.
 ---

package/skills/crd/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: crd
+description: 跨项目 CRD 提出方使用：起草或修订需求、整合接收方回复并续接 Q&A；接收方评估与答复用 crd-respond，非 Kubernetes CRD、代码评审或直接实施。维护 CRD 与往返记录。
+---
+
+# crd · 提出方的跨项目协作需求文档
+
+**固定由 CRD 的需求提出方使用**，负责起草、修订需求、整合接收方回复和继续澄清；接收方一律使用 `crd-respond`，包括原样追加其已拟好的答复。先按当前代表的角色选择技能，不按「收到文档」或「追加回复」这些动作词选。
+
+将本方向另一方提出的协作需求写成可独立阅读、逐项答复和持续跟进的 CR（Change Request），文档称为 CRD。这里的 QA 指 **Q&A 问答澄清**。双方都可能提出问题或补充意见，但不因此互换本份 CRD 的提出方与接收方。
+
+**默认以整份 CRD 往返协作**：提出方形成 CRD → 发给接收方 → 接收方在收到的文档末尾追加答复 → 返回包含答复的完整 CRD → 提出方核对、整合并继续下一轮。CRD 本身承载需求、Q&A 和回复历史；聊天或邮件中的独立答复作为补充输入。
+
+CR 讲清「谁需要另一方提供什么、为什么、怎样算满足、哪些问题尚未达成一致」。只展开协作边界所需的契约，不替对方编写内部实施方案，也不把写文档当作发送请求、接受需求或启动开发的授权。
+
+## 1. 定位本次动作与事实来源
+
+- **发起或修订需求**：读取需求简报、相关代码/接口文档及已有 CR，形成可答复的需求条目。
+- **提出方补充或答复澄清**：核对接收方的反问、替代方案与条件，在文末追加本方澄清、补充需求或有依据的确认，交付完整 CRD；未获授权的表态标为草案，不代接收方决定接受需求或承诺交付。
+- **整合对方返回的 CRD**：读取返回文档、上次发出版本和本地当前版本，识别本轮新增答复与其他改动，按第 4 节整合并同步当前摘要，不要求用户另行摘抄已有回复。
+- **收录接收方独立回复或续接 Q&A**：先读完整 CR，尤其是末尾最新往返记录，再对照来信、聊天、评审意见等材料收录接收方实际回复并同步当前摘要，保留其发言归属，不替其拟造立场。
+
+从已有上下文确定提出方、接收方、各自项目、协作目标、文档路径和当前代表的角色。若当前代表接收方，定位并读取可用的 `crd-respond` 后按其流程处理，不继续提出方流程；缺少技能时说明缺口，不虚构调用。角色无法确定且会改变本次动作时询问，不把当前仓库直接认作提出方。多方参与时，每条需求注明责任项目，不假设共享同一个仓库、版本或发布节奏。
+
+只询问会改变需求对象、范围或答复归属的缺失信息，其余写「待确认」并继续完成可确定部分。拿不到对方仓库时，区分本方观察、对方陈述、推测和待核实事项；不把本方找不到的能力写成对方不存在。
+
+每项事实保留可定位来源，如文件路径与段落、接口文档链接、消息日期与发言方。未知人员、日期、排期不补造；整理日期与原消息日期分别记录。拟稿不得冒称对方已回复。
+
+## 2. 写出对方能逐项处理的需求
+
+新建时读取 [CR 模板](assets/cr-template.md)，按实际规模删去不适用内容；更新既有 CR 时沿用其结构与编号，不强制重排。路径优先使用用户指定或仓库已有约定；没有约定时用 `docs/cr/CR-<主题短名>.md`。先查同主题文档，避免续谈时另建一份。
+
+需求使用文档内稳定编号 `R-01`，问题使用 `Q-01`，往返记录使用 `RESP-01`；继承已有编号，新条目递增，撤销的编号不复用。它们是本地追踪号，不冒充外部系统 ID。
+
+每条需求应包含：
+
+- **场景与动机**：谁在什么条件下需要什么；当前阻碍和不解决的影响。
+- **请求与边界**：希望接收方提供的可观察行为或交付物，以及提出方配合事项、非目标和前置依赖。
+- **协作契约**：仅写相关部分，如输入/输出、字段语义、权限、错误与重试、兼容版本、交接方式。已有契约标来源；尚未确定的设计明确标「提议」。
+- **验收条件**：给定前提和动作后应观察到的结果、必要的失败行为，由谁在什么环境或交付节点验证。可用具体示例，不用「正常工作」「支持对接」代替判据。
+- **优先级与时间**：说明影响与理由；区分提出方期望时间、接收方估计和明确承诺，不因写 CR 而编造截止日。
+
+一条需求应能被独立答复和验收。小型协作请求不扩写为完整 PRD；不要求对方必须采用尚未达成一致的内部技术方案。
+
+## 3. 维护 Q&A 与当前结论
+
+Q&A 是双方待澄清事项的当前视图。每条记录问题、关联需求、提问方、待答方、是否阻塞及阻塞哪一步、当前回答/待确认点、状态和答复记录链接。
+
+- 未知答案保持空缺含义明确；建议答案标为建议，不生成虚构问答。
+- 回答部分问题时，仅更新对应条目；未答项继续待答。问题已回答不等于需求已接受，需求已接受不等于已交付。
+- 单方提出的新范围、替代方案或时间安排，仍属待确认提议；达成一致的结论必须能指向有权限一方的明确确认，需双方确认的协作约定保留双方依据。
+- 新答复与旧答复冲突时，在当前视图指出冲突及影响；只有明确撤回或替代旧意见时才采用新结论，否则保持待澄清，不能仅凭时间较新覆盖旧承诺。
+- 需求、问题和答复互相引用。关闭问题需有实际回答及必要确认；关闭 CR 需有约定范围的验收证据，或明确的拒绝/撤回理由，不能用「已回复」代替闭环。
+
+正文是当前工作视图：已确认内容写入需求与验收条件；未确认变更放在提议或待决项中。历史往返记录保留当时原意。正文与历史不同不等于错误，但须能追到变更依据。
+
+## 4. 整份 CRD 往返与文末答复
+
+### 交付给对方的版本
+
+保持同一 CR 标识，注明当前文档版本及本轮基于的版本；沿用已有版本约定，无约定时可用 `v1`、`v2` 等区分交接版本。交付完整需求、Q&A 和全部往返记录，关键内容不只链接到对方无法访问的本地文件。接收方保留原需求与历史，在文末追加自己的答复；范围或验收的修改先写为建议。
+
+本地保留可定位的发出基线（已有文件或版本控制记录即可），便于下轮核对，不为每次文字编辑制造新副本。尚未实际发出时称「待发送版本」；用户提供了发送事实后才记录为已发出。
+
+### 整合返回文档
+
+- 先核对 CR 标识与版本关系，再比较返回版本相对发出基线的变化，以及本地当前版本相对该基线的变化。文件名变化不代表新 CR，返回文件的时间较新也不代表可以覆盖本地。
+- 对方已在文末写好的答复直接保留或并入一次，不把整份返回文档作为一条新回复再次粘贴。来源可定位到返回文件、版本及答复章节；保留原发言方和时间。
+- 对方直接改了需求、验收、Q&A 结论或历史答复时，显式列出差异及影响；尚未确认的实质变更作为提议或冲突，不能静默成为双方已同意的新基线。保留既有历史，历史更正以追加记录承接。
+- 本地也有新增内容时，合并互不冲突的增量；有冲突则保留双方意见并列入待确认项，不丢弃本地补充。并行副本发生编号碰撞时保留来源版本限定（如 `v2-甲方/RESP-02`），明确映射，不让一个编号指向两份不同内容。
+- 缺少发出基线时仍可整理可识别的答复，但说明无法完整核实正文改动；缺少本地版本时可将返回 CRD 作为当前工作稿，保留来源和未核实范围，不声称完成了版本合并。
+
+### 追加规则
+
+所有轮次放在文档最后的「往返答复记录」中，按收录顺序追加；需求、Q&A、来源和其他章节位于它之前。提出方收录接收方的实际答复、追加本方补充及双方后续确认，均使用同一记录格式；记录他人回复不等于代表他人作答。
+
+每次追加包含记录编号、发言方/项目、原消息时间（未知则注明）、整理时间、来源、关联 R/Q 编号、答复内容、未答项及下一步。拟答复显式标「草案，未发送/未确认」；收到的答复标「已收到」，但不据此推定内容已获双方认可。
+
+- 原文引用必须与已读取材料一致；概括写成「整理摘要」，保留条件、否定、例外及承诺边界。大段原文可链接原件，并在记录内保留关键答复。
+- 只追加新记录，不改写或删除已收录的历史答复。更正通过新记录引用被更正的编号，注明差异与依据；可以同步正文当前视图。
+- 追加前检查来源标识和内容，重复导入同一答复不重复记账。相似但有新增条件的消息是新记录，注明变化。
+- 一轮逐项对应 R/Q；无法可靠归属的答复保留原意并标「关联待确认」，不强行绑定。新的反问建立 Q 编号，链接该轮记录。
+- 用户只要求「原样追加」时只追加与必要标识，不擅自重写需求或采纳方案；用户要求整理、同步或续接时，才按证据更新正文当前视图。
+
+不通过邮件、聊天工具或项目系统发送 CR，除非用户另有明确授权；只负责落盘时无需增加发送审批步骤。生成文件不表示已送达接收方。
+
+## 5. 回读与交付
+
+检查新增/修改内容及关联位置：
+
+- 当前代表提出方；接收方回复均来自实际材料而非代拟。双方角色、需求边界、配合事项和验收判据可理解，未知信息未伪装成事实。
+- R/Q/RESP 编号唯一且引用可达；未答、部分接受、冲突和时间条件未丢失。
+- 当前结论均有来源；草案、提议、已收到、已确认和验收完成没有混用。
+- 历史答复未被覆盖，新记录位于文末；重复输入未造成重复追加。
+- 返回版本的增量已核对，本地补充未丢失；交接版本保留完整上下文，正文改动与未确认分歧有明确归属。
+- 相对链接正确，修改仅涉及本次 CR；不把文档检查报告成业务验收通过。
+
+交付文档链接、这轮新增或变化的结论、仍待谁回答的阻塞问题。没有实际发送就说明「文档已保存，未发送」。
+
+## 调用示例
+
+```text
+使用 $crd，为订单项目向账号项目提出批量查询用户展示名的协作需求。
+使用 $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

@@ -0,0 +1,66 @@
+# CR：<协作主题>
+
+| 项目 | 内容 |
+| --- | --- |
+| CR 标识 | <沿用已有标识；无则使用文档文件名> |
+| 文档版本 / 基于版本 | <当前交接版本 / 本轮收到或上次发出的版本；首版写无，未知则注明> |
+| 提出方 / 接收方 | <项目、团队及已知联系人> |
+| 当前状态 | <草案 / 待答复 / 澄清中 / 已达成一致 / 交付中 / 已关闭，按证据填写> |
+| 创建 / 更新日期 | <日期> |
+| 相关材料 | <PRD、Issue、接口文档或代码依据> |
+| 当前结论与下一步 | <已确认什么；待谁处理什么；依据或答复链接> |
+
+协作方式：提出方使用 `crd` 起草/修订、整合接收方回复并续接 Q&A；接收方使用 `crd-respond`，请在本文末尾追加逐项答复，保留原需求与既有往返记录，并返回完整 CRD。涉及范围或验收条件的调整请在答复中明确提出，供双方确认。
+
+## 1. 背景与目标
+
+<当前协作场景、已核实的现状、阻碍及期望结果。标明事实来源。>
+
+## 2. 范围与分工
+
+<本次包含什么、不包含什么；双方配合事项和前置依赖。>
+
+## 3. 需求与验收
+
+### R-01：<可独立答复的需求>
+
+- 场景与影响：<谁、什么条件、当前问题及优先级理由>
+- 请求接收方：<可观察行为或交付物>
+- 提出方配合：<调用适配、资料、环境等必要事项>
+- 协作契约：<相关输入/输出、语义、权限或失败行为；标明已有约定或提议>
+- 验收条件：<前提 → 动作 → 可观察结果，必要失败场景及验证方/节点>
+- 期望与承诺：<期望日期/节点及理由；对方估计或承诺另列，无则待确认>
+- 当前结论：<待答复 / 接受 / 部分接受 / 替代方案待确认 / 不接受；附依据，注明尚未解决的范围>
+
+## 4. Q&A 问答澄清
+
+| 编号 | 关联需求 | 问题 | 提问方 → 待答方 | 阻塞哪一步 | 当前回答与待确认点 | 状态 / 依据 |
+| --- | --- | --- | --- | --- | --- | --- |
+| Q-01 | R-01 | <一个明确问题> | <项目/人员> | <步骤或非阻塞> | <待答；建议须标为建议> | <待答 / 部分回答 / 待确认 / 已解决；链接答复> |
+
+无待澄清事项时写「暂无」，不编造问题凑表。
+
+## 5. 交付与闭环
+
+<有实际进展时记录约定范围、交付物/版本、验收结果与证据、剩余事项及关闭依据。尚未交付则明确写明，拒绝或撤回单列原因与来源。>
+
+## 6. 往返答复记录
+
+本节始终位于文末，按收录顺序追加。首轮尚无答复时写「暂无答复」，不把以下格式示意当作已收到的消息。
+
+### RESP-01 · <发言方> · <答复主题>
+
+- 类型：<答复草案（未发送/未确认） / 已收到答复 / 补充确认 / 更正>
+- 发言方与项目：<实际来源；未知则注明>
+- 原消息时间：<实际时间；未知则注明>
+- 整理时间：<本次整理日期>
+- 来源：<本轮基于的 CRD 版本、返回文件及章节；独立消息则写标识/链接或本轮用户提供材料>
+- 关联：<R-01、Q-01；更正时注明原 RESP 编号>
+
+**答复原文或整理摘要**（二者明确区分）：
+
+<逐项保留答复、限制条件、未接受部分及理由；草案不得写成对方承诺。>
+
+**未答项与下一步**：<待谁回答/确认什么；有明确时间约定才填写。>
+
+<!-- 后续 RESP-02、RESP-03 等追加于此，保留已有记录。生成实际 CR 时移除模板说明和未使用的示意条目。 -->

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。仅原样追加本方已拟答复或收录提出方澄清时保留来源与原意，不重评或生成计划。仅评估/仅答复遵守边界，不实施，不发送。"