review-crate

只有实际读取整个 crate 后，本技能才有效。

不可妥协的规则：

1. 枚举并读取目标 crate 中的每个文件。
2. 运行 crate 的测试，除非存在具体阻碍。
3. 每项发现都必须以准确的 file:line 证据为依据。
4. 新增发现前，检查当前仓库的规范问题文件。
5. 仅将发现写入本仓库中的 .ulpi/issues/<crate-name>.md。

review-crate

输入

• $crate_path：crate 目录的路径

目标

对 crate 进行完整审计，要求：

• 读取整个 crate
• 运行测试
• 报告真实 Bug 和覆盖率缺口
• 更新规范的本地问题文件，同时避免重复已有发现

步骤 0：确定 crate 身份

确定：

• crate 路径
• 从 Cargo.toml 中读取的 crate 名称
• 规范的问题文件路径：.ulpi/issues/<crate-name>.md

如果 crate 路径无效，请停止并明确说明。

成功标准：开始审查前，明确 crate 和问题文件的目标路径。

步骤 1：枚举并读取整个 crate

读取 crate 中的每个文件，包括：

• Cargo.toml
• 源文件
• 测试文件
• crate 内文档，例如 CLAUDE.md
• crate 目录中的辅助文档

不要抽样，也不要只读取“主要文件”后就停止。

成功标准：可以如实说明已读取整个 crate。

步骤 2：运行 crate 测试

运行最精简且完整的 crate 验证，通常为：

• cargo test -p <crate-name> -- --nocapture

如果无法运行测试，请报告确切的阻碍。

成功标准：审查包含实际的 crate 测试结果，或说明测试无法运行的具体原因。

步骤 3：检查现有问题文件

如果 .ulpi/issues/<crate-name>.md 已存在：

• 先读取该文件
• 避免重复已有发现
• 仅追加真正的新问题

如果该文件不存在：

• 有值得记录的发现时，创建该文件

成功标准：问题文件保持规范且不含重复内容。

步骤 4：分析并记录发现

检查以下方面：

• 正确性 Bug
• panic 或崩溃风险
• 验证缺口
• 竞态或状态问题
• 数据损坏风险
• 明确存在的性能陷阱
• 高风险行为的覆盖率缺口

每项发现都须包含：

• 严重程度
• 类别
• 准确的 file:line
• 问题确实存在的原因
• 建议的修复方向

对于不确定的判断，标注为 INFERENCE 并说明不确定的原因。

成功标准：发现有证据支撑且可采取行动。

步骤 5：结束时说明剩余风险

报告：

• 已读取的文件
• 测试结果
• 已写入或追加的发现
• 剩余的不确定性或覆盖率缺口

如果没有实质性发现，请明确说明。

成功标准：用户了解审查范围，以及仍然存在的风险。

防护规则

• 不要将发现写入本仓库之外的绝对路径。
• 不要在跳过文件的情况下声称完成了全面审查。
• 不要仅凭直觉编造问题。
• 不要添加 disable-model-invocation；这是一种有效的深度审计工作流。
• 不要将此任务扩大为多个 crate 的全面检查。

输出约定

报告：

1. 已审查的 crate
2. 文件数量，并说明是否已读取整个 crate
3. 测试结果
4. 按严重程度分类的发现
5. 已写入或追加的问题文件
6. 剩余风险或无问题的结论