Claude Skills by KtKID

独立性能巡检 skill。不在 x-dev → x-verify → x-qa-gate 主流程内，由用户手动触发或在大里程碑后调用。 调 opus 子 agent 做全项目视角的性能审查：N² 嵌套、不必要循环、大对象拷贝、同步阻塞、数据库 N+1、缓存失效、不必要的 await。 触发：用户说"性能巡检"、"audit perf"、"看看有没有性能问题"、"perf review"，或大版本发布前。

独立代码规范巡检 skill。不在 x-dev → x-verify → x-qa-gate 主流程内，由用户手动触发或周期性调用。 调 opus 子 agent 做全项目视角的规范审查：命名一致性、复用机会、magic number、函数长度、文件大小、注释合理性、死代码。 触发：用户说"规范巡检"、"audit style"、"代码规范检查"、"style review"。

⚠️ 已废弃：本 skill 已被 x-qa-gate 取代。请改用 x-qa-gate。 保留触发关键词以兼容老调用：review、code review、代码审查、检查一下、看看有没有问题、帮我 review、PR 前检查、合并前检查、提交前检查、代码审计。 当前调用会被自动重定向到 x-qa-gate。

开发任务执行 skill。基于现有功能计划目录执行开发任务， 读取 dev-pipeline/tasks/<功能名称>/README.md、dev-checklist.md、changelog.md， 按开发清单中的未完成任务进行实现、修复、测试，并回写任务状态与变更记录。 当开发清单中存在多个无依赖关系的待处理任务时，自动创建子 agent 并行开发以提升效率。 触发方式：用户输入 "x-dev <功能名称>" 或提供现有功能目录路径。

Bug 修复执行 skill。分两种模式： 1. 用户直接报告 Bug → 定位根因 → 修复 → 产出 fix-report-*.md 或 fix-note-*.md（无需 CR 报告） 2. 有 x-cr 的 CR 报告 → 按报告逐条修复 → 回写同一份 `reports/cr/cr-report-*.md` 主档并产出修复记录 触发方式："x-fix"、"修一下这个 bug"、"这个功能坏了"、"按 CR 报告修复"、 "把 CR 问题修了"。两种模式互斥：有 CR 报告走模式 2，无报告走模式 1。

跨 LLM 协议/数据结构/流程对齐 skill。当一个项目的契约（API/事件协议/数据结构/接口/流程）需要由两个或多个 LLM 各自代表实现方立场来回审稿时使用。用户作为人类中间人，在两个 LLM 之间传递文档与反馈。 典型场景：项目 A 的 LLM 写了一份 contract 文档，项目 B 的 LLM 要从实现方角度审稿、提反馈、敲细节，多轮迭代到双方都站得住脚。 触发关键词："和另一个 LLM 对齐协议"、"跨团队 contract review"、"让另一个 LLM 给意见"、"多 LLM 讨论"、"另一个工程师设计的协议你看看"、"我把反馈传过去了，对方改了"、"x-multi-llm-align"、"multi-llm 流程"，或用户描述的场景里同时出现"另一个 LLM/工程师/项目"+"协议/契约/数据结构/接口"+"对齐/review/审稿"等组合。 适用领域：协议对齐、数据结构对齐、流程对齐。不适用：单方面 review、代码 PR 评审（用 x-cr）、写作 peer review。

⚠️ 已废弃：本 skill 已合并到 x-req。x-req 现在一步产出 README.md + dev-checklist.md + diagram.html。 保留触发关键词兼容：x:plan、计划、制定计划、开发计划、plan。 调用时自动重定向到 x-req。

Gate ② 质量评审 skill（取代 x-cr）。串行 dispatch 3 个 opus 子 agent reviewer：R1 spec 符合性 → R2 边界完整性 → R3 测试真实性。任一 reviewer 失败即触发 x-fix 并回到该 reviewer 重审；全部通过任务才算完成。 自动触发：x-verify 通过后立即触发。 手动触发：用户要求"质量门禁"、"qa-gate"、"代码评审"、"review"。 本 skill **取代老 x-cr**——老的 x-cr 入口仍能调用，但会重定向到本 skill。 reviewer 子 agent **必须用 model=opus**（写入 dispatch 模板）。

轻量级快速开发 skill。自包含，一步到位，适合 1-2 小时内能完成的改动。 触发场景：“x-qdev”、“快速开发”、“小功能”、“小改动”、“修个 bug”、“加个小功能”、 “这个简单直接做吧”、用户描述的任务明显是小改动（单文件/单模块/1-5 个 checklist 项）。 与 x-req 的区别：x-req 适合中等以上任务（需要 DoD + 技术设计 + 清单 + 确认）； x-qdev 省去确认步骤直接开发，但仍产出任务记录（README.md + changelog.md）。

需求+开发准备 skill（合并原 x-plan）。一次确认，产出 README.md + dev-checklist.md + diagram.html。 触发场景："帮我处理需求"、"梳理需求"、"开个 task"、"新建任务"、"这个功能怎么做"、 "帮我拆一下"、"x-req"、"x-plan"（重定向）、用户提供需求文档路径、描述一个预计超过 2 小时的功能。 与 x-qdev 的区别：x-qdev 适合小改动（1-2 小时内，不需要技术设计）；x-req 适合中等以上任务（需要 DoD + 技术设计 + 清单）。 与 x-spec 的区别：x-spec 是系统/模块级文档（docs/），x-req 是具体 task 级（dev-pipeline/tasks/）。

系统方案规划 skill。产出 docs/<模块>/<spec>/ 下的文档包（架构图 + 组件设计 + 接口/数据结构 + task 映射），多个 spec 组合成完整模块。 当用户给的是模糊想法而非具体功能需求时使用。触发场景： "这个东西怎么设计"、"帮我整理模块"、"画个架构图"、"帮我梳理整体方案"、"先别写代码把方案理清"、 "给人讲解这个系统需要什么文档"、"这个系统该怎么拆"、"x-spec"、新建多模块系统、架构级改造、 一个模块下会派生多个 task 需要先建模块文档。不适用：小功能小修复（用 x-qdev）、已有明确需求（用 x-req）。

Gate ① 事实验证 skill。读取 dev-report.md 中的命令清单，逐条复跑，对比实际 exit code 与关键输出片段。任一不一致即拦下，调 x-fix 修复。 本 skill 只做客观事实判断，不做主观代码质量判断。 自动触发场景：x-dev / x-qdev 完成任务后立即触发。 手动触发场景：用户要求"验证 dev-report"、"复跑验证命令"、"verify"、"check exit codes"。 **不信任自我报告**：dev-report 里的"自检结论"不算数，必须自己跑一遍。

独立架构巡检 skill。不在 x-dev → x-verify → x-qa-gate 主流程内，由用户手动触发或大里程碑后调用。 调子 agent 做全项目视角的架构审查，核心两条主线：架构一致性（模块归属、边界类复用、分层、循环依赖、命名语义、错误处理一致性）与单一事实源（字段/枚举/默认值/prompt 规则/schema/文档是否多处重复维护并已漂移），辅以抽象合理性（奥卡姆，防过度设计）、模块契约清晰度、依赖方向健康。 触发：用户说"架构巡检"、"audit arch"、"架构一致性检查"、"看看有没有重复的事实源"、"单一事实源检查"、"arch review"、"这块架构合不合理"，或大版本/重构里程碑后。

精简的系统方案建模 skill。把模糊或跨模块需求收敛成可交给 x-req 的 V2 spec 包，固定产出 spec.md、modules.md，并在跨模块数据流、状态、时序、资源生命周期或故障恢复出现时按需产出 design.md。用户提到 x-spec2、新版 x-spec、系统方案、架构级改造、多个模块或多个后续 task 时优先使用；现有架构归属、状态模型或模块边界尚未闭合时也应使用。