メニュー
需求与开发准备 skill。把确认后的需求直接写成可执行 task 包，并以 Q0-Q3 risk 驱动统一开发流程。 触发场景：“帮我处理需求”、“梳理需求”、“开个 task”、“新建任务”、“这个功能怎么做”、“帮我拆一下”、`x-req`，以及用户提供需求文档路径或描述预计超过 2 小时的功能。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
开发任务执行 skill。读取 task README 与 dev-checklist，按依赖实现、写 verify 证据，并由 README risk 驱动交付或 Gate ②。 触发：`x-dev <功能名称>` 或现有 task 目录。
软件正确性调查 skill。用于用户说“XX 不太对”“这个功能有 bug”“结果和预期不一致”“帮我查原因”，也用于用户要求 review 某个模块、文件、diff 或 PR 的正确性。遇到已知异常或模块 correctness review 时必须优先使用本 skill。 本 skill 使用贝叶斯根因调查：先列候选原因 H，再按日志、代码路径、测试、diff、spec 等证据 E 更新置信度，最后判断根因属于原始 spec 不一致、实现过程偏移、spec 缺口、环境/数据问题或证据不足。 x-cr 独立于 x-verify / x-qa-gate 自动门禁，产出 `reports/cr/cr-report-*.md`，x-fix 可按该 CR 报告继续修复。
Bug 修复执行 skill。分三种入口： 1. 用户直接报告 Bug → 定位根因 → 修复 → 产出 fix-report-*.md 或 fix-note-*.md（无需 CR 报告） 2. 有 x-cr 的 CR 报告 → 按报告逐条修复 → 回写同一份 `reports/cr/cr-report-*.md` 主档并产出修复记录 3. 有 x-verify / x-qa-gate fail 报告 → 按发现清单一次批量修复，产出逐条处置表，交回 gate 增量复审 触发方式："x-fix"、"修一下这个 bug"、"这个功能坏了"、 "按 CR 报告修复"、"把 CR 问题修了"。
跨子 agent 协议/数据结构/流程对齐 skill。当一个项目的契约（API/事件协议/数据结构/接口/流程）需要由两个子 agent 各自代表实现方立场来回审稿时使用。用户作为人类中间人，在两个子 agent 之间传递文档与反馈。 典型场景：项目 A 的子 agent 写了一份 contract 文档，项目 B 的子 agent 要从实现方角度审稿、提反馈、敲细节，多轮迭代到双方都站得住脚。 触发关键词："和另一个子 agent 对齐协议"、"跨团队 contract review"、"让另一个子 agent 给意见"、"多子 agent 讨论"、"另一个工程师设计的协议你看看"、"我把反馈传过去了，对方改了"、"x-multi-llm-align"、"multi-agent 流程"，或用户描述的场景里同时出现"另一个子 agent/工程师/项目"+"协议/契约/数据结构/接口"+"对齐/review/审稿"等组合。 适用领域：协议对齐、数据结构对齐、流程对齐。不适用：单方面 review、代码 PR 评审（用 x-cr）、写作 peer review。
Gate ② 质量门禁。README risk Q2 走 RC，Q3 串行走 R1、R2、R3；reviewer 一轮列全发现并交 x-fix 批量修复。
系统方案规划 skill。产出 docs/spec/<spec-name>/ 下的独立需求包（目标与 DoD + 组件设计 + 接口/数据结构 + 核心流程时序 + 验证策略 + task 映射）。 当用户给的是模糊想法而非具体功能需求时使用。触发场景： "这个东西怎么设计"、"帮我梳理整体方案"、"先别写代码把方案理清"、 "这个系统该怎么拆"、"x-spec"、架构级改造、 一个系统切面会派生多个 task 需要先建 spec 需求包。上下文不足时先进入头脑风暴模式，收敛后再保存 spec 文档。 入口选择：小功能小修复由 x-req 定级 Q0/Q1；已有明确需求走 x-req。
| name | x-req |
| description | 需求与开发准备 skill。把确认后的需求直接写成可执行 task 包，并以 Q0-Q3 risk 驱动统一开发流程。 触发场景：“帮我处理需求”、“梳理需求”、“开个 task”、“新建任务”、“这个功能怎么做”、“帮我拆一下”、`x-req`，以及用户提供需求文档路径或描述预计超过 2 小时的功能。 |
新 task 需要 README.md 与 dev-checklist.md；涉及至少三个模块或用户要求图时加入 diagram.md。README 的 risk: Q0|Q1|Q2|Q3 是风险唯一真源，验收 Requirement/Scenario 是 DoD 真源，dev-report 保存 verify 证据。
| 等级 | 判据 | 流程 |
|---|---|---|
| Q0 | 单文件且没有行为分支变化 | lite task → x-dev → verify → 交付 |
| Q1 | 局部功能或修复，没有跨模块契约变化 | lite task → x-dev → verify → 交付 |
| Q2 | 新功能、多文件、契约或状态变化 | 一次确认 → x-dev → verify → RC |
| Q3 | 鉴权、权限、加密、不可逆写入或迁移、公开 API/协议/schema、并发、状态机、缓存一致性 | 一次确认 → x-dev → verify → R1→R2→R3 |
用户显式定级优先。Q0/Q1 直接编写 task 并在完成汇报中说明定级依据；用户可随时指定“按 Q2 走”。架构归属、状态模型或跨模块边界未闭合时转 x-spec。
dev-pipeline/tasks/<name>/；更新先读现有 README、checklist 与 dev-report，保留无关内容并写 updated: YYYY-MM-DD <summary>。templates/confirmation.md 一次展示确认；用户修改后更新并再次确认；取消则结束。python3 tools/xdev.py scaffold <task-dir>；涉及图时加 --with-diagram。instructions readme、instructions dev-checklist、按需 instructions diagram；填写模板，删除 HTML 注释。验证: auto|manual；自动场景由后续 dev-report verify 块回指。python3 tools/xdev.py validate <task-dir>，修复 finding 直到零 finding；检查需求覆盖、验收可判定性、架构归属和 checklist 追溯。x-dev <task-name>。# | 任务 | 涉及文件 | 依赖 | 状态 | fix 表头与 token+emoji 状态。