القائمة
Hit 项目代码审查专用 skill。按 TODO.md 阶段对完成代码做结构化审查， 覆盖 Rust 代码质量、安全审计，按标准报告格式输出审查报告。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Hit 项目实测流程专用 skill。按 TEST_FLOW.md 执行完整命令测试，生成 REPORT.md 测试报告，并更新 BUGS.md 记录新发现的问题。
Hit 项目发布 skill。构建 release 资产， 根据用户提示生成草稿内容，等待用户审核后执行发布命令 （git tag / push / gh release create / git cnb release create）。
阅读代码审查报告，逐项核实问题，决定是否需要修改， 并在报告末尾追加「报告回执」章节。 当用户说"写回执"、"回复审查"、"处理 review"时触发。
Review Hit 项目 docs/ 下全部文档的跨文档一致性——检查文件存在性、交叉引用、表格格式、编号连贯性、内容冲突
创建 Hit 项目的新 workspace crate 子模块。用于用户需要添加新 crate 时自动搭建 Cargo.toml 和 src/lib.rs 骨架并注册到 workspace。
验证 Hit 项目代码完整性——运行编译检查、静态分析和全部测试。在用户要求"验证改动"、"跑一遍检查"、或完成任务准备收尾时使用。
| name | code-review |
| description | Hit 项目代码审查专用 skill。按 TODO.md 阶段对完成代码做结构化审查， 覆盖 Rust 代码质量、安全审计，按标准报告格式输出审查报告。 |
| license | MIT |
| compatibility | Hit 项目 |
| metadata | {"version":"2.0.0"} |
| allowed-tools | Bash(cargo:*) Bash(git:*) Read Write Edit Glob Grep |
| user_invocable | true |
| disable_model_invocation | false |
按 TODO.md 中指定的 Phase/模块进行结构化代码审查。
⚠️ 重要前提：Hit 是 Windows 专用工具，不跨平台。审查时不要提出"非 Windows 平台无法编译/运行"之类的跨平台问题——这不是项目目标。
thiserror 定义错误类型，CLI 代码使用 anyhow 传播错误Result<T, AppError>，避免 unwrap()/expect().context() / .with_context()（来自 anyhow）snake_case，类型/trait/枚举用 PascalCasehit_xxx::submodule::functionDebug + Clone + PartialEq///）pub(crate) 而非 pubrayon::par_iter()clone()，优先用引用Cow<'_, str>#[cfg(test)] mod tests { ... } 内tests/ 目录fn test_<函数名>_<场景>()canonicalize() 防止路径穿越HKCU 范围，避免 HKLM（需提权）tempfile crate 而非手动构造路径https://，防止 protocol confusion在正式开始之前，先加载 security-reviewer skill 获取安全审查清单：
use_skill name: security-reviewer
读取 docs/TODO.md 中对应的 Phase/模块章节（如 ### 1.2 hit-core/manifest），
确定：
只审查标注 ✅ 的任务，不审查未完成的任务。
# 编译检查
cargo check --workspace
# 静态分析（视情况加 -D warnings）
cargo clippy --workspace
# 运行对应 crate 的测试
cargo test -p <crate-name>
记录基线结果用于报告开头：
**基线**：`cargo check` ✅ | `cargo test` ✅ (N/N) | `cargo clippy` ⚠️ N warning(s)
按 TODO.md 任务清单找到对应源文件，通读代码。重点关注：
在阅读代码过程中，逐条对照上方的审查清单：
按以下标准格式输出审查报告。注意：
## 📋 用户意见 章节，内容先留空，等待用户填写docs/notes/review/REVIEW_YYYY-MM-DD[-<phase>].md⚠️ 免责声明：以下"逐项审查"、"问题汇总"、"评分总结"等章节仅代表代码审查者的分析意见， 仅供参考，你可以自行评估决定是否接受意见进行修改或进行其他操作。 但是「用户意见」章节的内容是项目所有者明确的决策，必须遵从。
# 代码审查报告 — Phase <N> <模块名>
**审查者**：AtomCode code-review
**时间**：<日期>
**范围**：仅 TODO.md §<章节>（任务 <编号>）
**文件**：<涉及的文件列表>
**基线**：`cargo check` ✅ | `cargo test` ✅ (N/N) | `cargo clippy` ✅
---
## 📋 用户意见（必须遵从）
> 此章节在审查时由项目所有者填写。审查者先留空，等待用户提出具体决策意见。
> 一旦填写，其内容具有最高优先级，必须遵从。
---
## 任务完成清单
| 序号 | 任务 | 状态 | 代码位置 |
|------|------|:----:|----------|
| N.N.N | 任务描述 | ✅ | `src/.../file.rs` |
| ...用表格列出所有该阶段的任务，标注完成状态... |
**结论：N/N 项任务全部完成，可标记 ✅。**
---
## 模块结构总览
\`\`\`
src/<module>/
├── mod.rs # 模块入口
├── xxx.rs # 子模块说明
└── ...
tests/
├── test_xxx.rs
└── ...
\`\`\`
---
## 逐模块审查
### <module>.<file> — 模块名 ⭐⭐⭐⭐⭐
**关键设计**：用文字或表格说明设计亮点。
| 评价 | 说明 |
|------|------|
| ✅ 亮点 | 具体说明 |
| ⚠️ 待改进 | 具体问题 |
### <module>.<file> — 模块名 ⭐⭐⭐⭐
...
---
## 测试覆盖分析
| 测试文件 | 数量 | 覆盖重点 |
|---------|:----:|----------|
| `tests/xxx.rs` | N | 覆盖内容 |
| **总计** | **N** | |
---
## 问题汇总
| # | 任务 | 问题 | 严重度 | 建议 |
|---|------|------|--------|------|
| 1 | N.N.N | 问题描述 | 🔴🟡🟢 | 修复建议 |
严重度定义：
- 🔴 阻塞 —— 必须修复才能继续
- 🟡 中等 —— 建议修复
- 🟢 微小 —— 可忽略或后续优化
---
## 评分总结
| 维度 | 评分 | 说明 |
|------|:----:|------|
| **完成度** | ⭐⭐⭐⭐⭐ | N/N 任务完成 |
| **数据建模** | ⭐⭐⭐⭐⭐ | 视情况 |
| **测试覆盖** | ⭐⭐⭐⭐⭐ | 视情况 |
| **代码质量** | ⭐⭐⭐⭐⭐ | 视情况 |
| **架构设计** | ⭐⭐⭐⭐⭐ | 视情况 |
### 整体结论
**Phase <N>（<模块名>）通过审查，可以关闭。**
一段总结性结论。
| 分值 | 含义 |
|---|---|
| ⭐⭐⭐⭐⭐ | 无可挑剔，生产就绪 |
| ⭐⭐⭐⭐ | 良好，有个别轻微问题 |
| ⭐⭐⭐ | 可用，但有多处待改进 |
| ⭐⭐ | 有严重问题需修复 |
| ⭐ | 不可接受，需重写 |
| 标记 | 含义 |
|---|---|
| 🔴 | 阻塞 —— 必须修复才能继续 |
| 🟡 | 中等 —— 建议在本阶段修复 |
| 🟢 | 微小 —— 可忽略或后续优化 |
## 📋 用户意见 章节先留空，仅保留说明文本，等待用户提出