Menu
Hit 项目代码审查专用 skill。按 TODO.md 阶段对完成代码做结构化审查， 覆盖 Rust 代码质量、安全审计，按标准报告格式输出审查报告。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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>（<模块名>）通过审查，可以关闭。**
一段总结性结论。
| 分值 | 含义 |
|---|---|
| ⭐⭐⭐⭐⭐ | 无可挑剔，生产就绪 |
| ⭐⭐⭐⭐ | 良好，有个别轻微问题 |
| ⭐⭐⭐ | 可用，但有多处待改进 |
| ⭐⭐ | 有严重问题需修复 |
| ⭐ | 不可接受，需重写 |
| 标记 | 含义 |
|---|---|
| 🔴 | 阻塞 —— 必须修复才能继续 |
| 🟡 | 中等 —— 建议在本阶段修复 |
| 🟢 | 微小 —— 可忽略或后续优化 |
## 📋 用户意见 章节先留空，仅保留说明文本，等待用户提出