| name | code-review |
| description | 对 Yakit 仓库的代码改动做规范化 code review：按代码逻辑、TS 定义、UI 引用与 Props、CSS 样式、依赖版本、配置项六个维度审查，检查测试用例缺失，强制执行 tsc 类型检查与 vitest 测试验证，输出「结果汇总 / 明细解释 / 合并结论」三块报告，经用户确认后写入文件。当用户要求 review、审查、评审代码改动，或在提交、合并、提 PR 前先检查代码时触发。审查对象可以是 PR 编号、分支 diff（含当前分支相对基线的改动）或工作区未提交改动。 |
code-review
产出规范化三块式 review 报告。只读：不改被审代码，不运行被审代码本体；对被审代码只允许执行 yarn type-check 与 yarn test:vitest ... --run，另允许在临时 worktree 内 yarn cli install 装依赖。tsc / vitest 未实际跑过，报告中不得标 ✅，不得编造结果。发现问题不瞒报、不把功能 bug 降成警告。
触发
- 语义：如「review」「审查这个 PR / 当前分支」「对比 master」「合并前检查」。
/code-review，可带参数（如 /code-review review PR 4198）。- 被其他 skill 调用（如 create-pr）：已指定范围则直接执行，不弹框。三块报告全文返回调用方；落盘仍须用户同意。
1. 确定审查对象
能确定的直接用，不要多问：
| 优先级 | 条件 | 模式 |
|---|
| 1 | 含 PR 编号（「review 4198」「审查 #4198」） | PR |
| 2 | 含分支或基线（「review dev」「对比 feat-x」） | 分支 |
| 3 | 外部 skill 已指定 diff 范围 | 直接采用，不弹框 |
| 4 | 以上都没有 | AskUserQuestion |
弹框选项（question 注明「审查 PR 或其他基线请在 Other 中输入编号 / 分支名」）：当前分支 vs master；工作区未提交改动。
| 模式 | 获取改动 | 报告文件名（仓库根） |
|---|
| PR | gh pr view <编号> --repo yaklang/yakit --json title,headRefName,headRefOid,baseRefName,baseRefOid,files + gh pr diff <编号>。必须记录 baseRefOid / headRefOid 供步骤 4 | PR-<编号>-review.md |
| 分支 | git diff <基线>...HEAD + git log --oneline <基线>..HEAD，基线默认 master | <分支名>-review.md（/ → -） |
| 工作区 | git diff HEAD + git status --short 未跟踪新文件（读内容纳入审查） | working-tree-review.md |
gh 未安装或未登录：PR 模式报错并停止；若本地分支恰好对应该 PR，经用户确认后降级为分支模式。
2. 收集与分类
git diff --stat（或 PR files 列表）列出全部改动。分类：源码（ts/tsx/js/jsx）、测试、样式（less/css/scss）、依赖（package.json / yarn.lock）、配置、文档。diff 为空 → 说明无改动并停止。 文件 > 50：优先审源码/依赖/配置，样式与文案抽检，报告开头说明覆盖度。
PR 模式只有 diff 没有本地上下文：结合文件清单审；本地有对应分支则读本地补充，否则注明「仅基于 diff 审查」。验证仍须在 OID worktree 双跑，不用当前目录结果。
3. 六维检查
逐维度先读 references/check-dimensions.md 对应节。
| # | 维度 | 触发 | 无涉及时 |
|---|
| 1 | 代码逻辑 | 有源码改动 | 汇总表标 ⏭️ N/A |
| 2 | TS 定义 | 有 ts/tsx 改动 | 同上 |
| 3 | UI 引用与 Props | 有组件 / props 改动 | 同上 |
| 4 | CSS 样式 | 有样式文件或 tsx 内样式改动 | 同上 |
| 5 | 依赖版本影响 | 仅当改动含 package.json | ⏭️ N/A（无依赖改动） |
| 6 | 配置项影响 | 仅当改动含配置文件 | ⏭️ N/A（无配置改动） |
维度 5、6 不可放宽：无 package.json 不审依赖，无配置文件不审配置。N/A 行必须出现在汇总表，不许整行消失。配置文件：tsconfig*.json、vite/vitest、electron-builder、.github/workflows/、scripts/、cli/、.env*、.husky/、.lintstagedrc 等；package.json 的 scripts 段改动同时触发维度 5、6。
4. 强制验证（每次必做）
工作区 / 分支：在当前工作目录跑。
PR 模式禁止在当前工作目录跑（本地可能不是该 PR head）。必须 base / head 双快照：
- 用步骤 1 的
baseRefOid / headRefOid，git fetch origin <OID>（用 OID，不用分支名）。
git worktree add --detach <临时目录> <OID> 建 head、base 两个隔离 worktree，不动用户当前状态。- 两处跑完全相同的 tsc / vitest；依赖未就绪则在对应子项目
yarn cli install，仍无法运行 →「环境异常降级」。
- 结束后
git worktree remove <临时目录>。
归因：head 失败且 base 同项失败 → 基线遗留，不记本 PR 的 P0（注明「base 同样失败，非本 PR 引入」，可作警告）；head 失败且 base 通过 → ❌ P0；head 通过 → ✅。fetch / worktree 失败等无法构造快照 → 环境异常降级，不得标 ✅，也不得用当前目录结果代替。
TS
对改动所在子项目跑整个子项目 type-check（不是单文件）：
| 改动位置 | 命令 |
|---|
app/renderer/src/main/ | cd app/renderer/src/main && yarn type-check |
app/renderer/engine-link-startup/ | cd app/renderer/engine-link-startup && yarn type-check |
仅 app/main/ 或不含 TS 子项目 | 跳过，注明原因（主进程纯 JS 无 tsconfig / 本次无 TS） |
通过 → 1 条 ✅；失败 → 1 条 ❌ P0（附 文件:行号 摘要）；PR 模式 head 失败但 base 同样失败不记 P0。
测试
与 CI（scripts/ci-select-vitest-tests.js）相同的三条规则选相关测试：
- 变更文件本身是
__test__/ 下 *.test.* / *.spec.* → 纳入；
- 业务文件同目录
__test__/<stem>.(test|spec).* 存在 → 纳入；
__test__/ 用例 import 了某个变更模块（grep 路径 / @renderer / @engine 等）→ 纳入。
仓库根执行（PR 模式在 base / head worktree 各跑相同命令）：
yarn test:vitest <测试文件...> --run
全通过 → 1 条 ✅（注明文件数与用例数）；有失败 → 每个失败用例 ❌ P0（用例名 + 断言摘要）；PR 模式 base 同样失败的不记 P0。找不到相关测试 → 汇总表「⏭️ 无相关测试」。
环境异常降级
tsc / vitest 因环境无法运行（依赖未装、node 版本等），而非代码报错：汇总表标 ⚠️「验证环境异常」，提示 yarn cli install。既不得标 ✅，也不得算代码问题。 PR 模式无法构造快照时同样降级。
5. 测试用例缺失
需要用例：新增/修改逻辑分支、纯工具函数、状态转换、复杂组件交互、bug 修复（防回归）。不需要：纯样式、纯文案/i18n、类型声明、构建/CI 配置本身。
需要但同目录无 __test__/<stem>.test.* → ❌ P1「缺失测试用例」，建议路径 <业务目录>/__test__/<stem>.test.ts。
严重程度
| 级别 | 含义 | 典型 | 对结论 |
|---|
| ❌ P0 | 必须修复 | 安全漏洞、明确功能 bug、TS/测试验证失败 | 存在即不通过 |
| ❌ P1 | 需要修复 | 边界缺陷、props 与定义不符、缺失测试 | 存在即需要修复 |
| ⚠️ 警告 | 不阻塞 | 风格偏离、冗余、命名、依赖升级缺动机 | 不影响结论 |
6. 输出三块报告
先在对话完整输出，再 AskUserQuestion 是否写入本地文件（文件名见步骤 1）；同意才写，不同意仅留在对话。布局：
# Code Review 报告：<PR 标题 / 分支名 / 工作区改动>
## 一、Review 结果汇总
| 检查项 | 结果 |
| --- | --- |
| 代码逻辑检查 | ✅ / ❌ / ⏭️ N/A |
| TS 定义检查 | ✅ / ❌ / ⏭️ N/A |
| UI 引用与 Props 检查 | ✅ / ❌ / ⏭️ N/A |
| CSS 样式检查 | ✅ / ❌ / ⏭️ N/A |
| 依赖版本影响检查 | ✅ / ❌ / ⏭️ N/A（无 package.json 改动） |
| 配置项影响检查 | ✅ / ❌ / ⏭️ N/A（无配置文件改动） |
| TS 验证（tsc） | ✅ 通过 / ❌ 失败 / ⚠️ 环境异常 / ⏭️ 跳过（原因） |
| 测试验证（vitest） | ✅ N 个文件全通过 / ❌ 失败 / ⏭️ 无相关测试 |
| 测试用例缺失检查 | ✅ 齐全 / ❌ 缺失 N 处 |
**统计：正确 X 项 / 问题 Y 项（P0 a 项 / P1 b 项）/ 警告 Z 项**
## 二、明细解释
> 每项固定两行：第一行定位，第二行缩进两格写原因。第一行末尾两个空格（markdown hard break；下方 `··` 表示这两个空格，不要真写点号）。不得并成一行，也不得超过两行；细节压缩进第二行。
### ✅ 正确项
- 内容描述（确认了什么）··
原因结果（为什么正确 / 验证依据）
### ❌ 问题项
行号必须写（函数定义行等）；缺测试用关键函数行号。不允许只写路径。
- [P0] `文件:行号`··
原因结果：<问题是什么> → <修复建议>
- [P1] `文件:行号`··
原因结果：<问题是什么> → <修复建议>
### ⚠️ 警告项
- `文件:行号` 或 <一句话标题>··
原因结果：<说明与建议>
## 三、合并结论
**结论：不通过 / 需要修复 / 可以合并**
<只允许这三种，不得出现「修复后可合并」等中间态>
统计：维度整体通过计 1 条正确项；每个问题/警告各 1 条；tsc / vitest 通过各 1 条正确项。⏭️ N/A 与 ⚠️ 环境异常不计入三项统计。
| 情况 | 结论 |
|---|
| 任一 P0 | 不通过 |
| 无 P0，有 P1 | 需要修复 |
| 仅警告或全部正确 | 可以合并 |
