开发任务执行 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。把确认后的需求直接写成可执行 task 包，并以 Q0-Q3 risk 驱动统一开发流程。 触发场景：“帮我处理需求”、“梳理需求”、“开个 task”、“新建任务”、“这个功能怎么做”、“帮我拆一下”、`x-req`，以及用户提供需求文档路径或描述预计超过 2 小时的功能。
系统方案规划 skill。产出 docs/spec/<spec-name>/ 下的独立需求包（目标与 DoD + 组件设计 + 接口/数据结构 + 核心流程时序 + 验证策略 + task 映射）。 当用户给的是模糊想法而非具体功能需求时使用。触发场景： "这个东西怎么设计"、"帮我梳理整体方案"、"先别写代码把方案理清"、 "这个系统该怎么拆"、"x-spec"、架构级改造、 一个系统切面会派生多个 task 需要先建 spec 需求包。上下文不足时先进入头脑风暴模式，收敛后再保存 spec 文档。 入口选择：小功能小修复由 x-req 定级 Q0/Q1；已有明确需求走 x-req。
Gate ① 事实验证 skill。运行 xdev verify 引擎；全过给回执，失败诊断事实并交 x-fix。 触发：x-dev 收尾、用户要求 verify 或复跑 task 证据。