review

用途

review 是 git-repo-prep 技能集中的一个审计技能，用于在代码仓库公开（开源发布）之前，检查仓库在“开放性”方面是否存在问题。它关注的是让仓库适合公开所需的事项，而不是代码质量本身。技能说明中明确：这是开放性审计，不是代码质量审查，不应评论错误处理、架构、性能、代码风格、测试覆盖质量或设计模式。该技能可重复运行，在任意阶段都可以执行。

主要能力

技能会先建立一份 TodoWrite 检查清单，覆盖全部审计类别，并在每项开始前标记为 in_progress、完成后立即标记为 completed。审计类别包括：

密钥扫描（Secrets scan）
个人信息扫描（Personal info scan）
许可证检查（License check）
文档检查（Documentation check）
.gitignore 检查（Gitignore check）
CI/CD 检查（CI/CD check）
元数据检查（Metadata check）
呈现发现与总结

在开始前，技能会先做生态检测，根据仓库中的文件判断项目生态，并据此调整检查项：

package.json → Node.js
pyproject.toml / setup.py / setup.cfg → Python
Cargo.toml → Rust
go.mod → Go
*.csproj / *.sln → .NET
Gemfile → Ruby
pom.xml / build.gradle → Java/Kotlin

各审计类别的检查内容

1. 密钥（Secrets）

在源码文件中搜索以下模式：sk_live、sk_test、ghp_、AKIA、password\s*=、secret\s*=、token\s*=、api_key、-----BEGIN.PRIVATE KEY、带内嵌凭据的连接字符串。检查仓库任意层级是否存在 .env 文件；检查 .gitignore 是否包含 .env 与 .env. 排除模式；查找 .pem、.key 或凭据文件。

严重级别划分：API key、密码、token、.env 被提交为 Critical；.env 出现在 gitignore 中为 Recommended；git 历史扫描为 Nice-to-have。

2. 个人信息（Personal info）

检查包元数据中的 author 字段（package.json author、pyproject.toml authors、Cargo.toml authors）；在源码文件中搜索邮箱模式（\b\S+@\S+.\S+\b），排除 node_modules、vendor 和 lock 文件；查找配置或源码中硬编码的用户名（DEFAULT_USER、AUTHOR、URL 或路径中的用户名）。

严重级别：源码中的真实姓名/邮箱为 Critical；author 字段审查为 Recommended；用户名清理为 Nice-to-have。

3. 许可证（License）

技能说明这是最常被遗漏的领域，需要检查三个位置并相互比对：LICENSE 文件是否存在、包含哪种许可证；包元数据（package.json / pyproject.toml / Cargo.toml）中的 license 字段；README 中是否有许可证章节且指明同一许可证。三者之间任何不一致都要标记，任一位置缺失也要标记。

严重级别：没有 LICENSE 文件为 Critical；LICENSE 文件与包元数据不一致、README 中没有许可证章节为 Recommended；源码文件中的许可证头为 Nice-to-have。

4. 文档（Documentation）

README 是否存在、是否非空、是否包含项目描述、安装/快速开始、使用说明、许可证章节；CONTRIBUTING.md 是否存在；SECURITY.md 是否存在。

严重级别：没有 README 或 README 为空为 Critical；缺少安装/使用章节为 Recommended；CONTRIBUTING.md、SECURITY.md、CLAUDE.md 为 Nice-to-have。

5. .gitignore

检查 .gitignore 是否存在；对照生态最佳实践：

Node.js：node_modules/、.env、dist/、coverage/
Python：pycache/、.pyc、.env、.egg-info/、dist/、.venv/
Rust：target/、.env
Go：vendor/（若不使用 vendoring）、.env
通用：.env、.env.、.log、.DS_Store、.pem、.key

检查是否有敏感文件已被 git 跟踪（对 .env、凭据、密钥执行 git ls-files）。

严重级别：敏感文件被跟踪/提交为 Critical；缺少生态常见模式为 Recommended；IDE/OS 文件为 Nice-to-have。

6. CI/CD

查找 .github/workflows/、.gitlab-ci.yml、Jenkinsfile、.circleci/ 等；检查是否有 Dependabot 配置（.github/dependabot.yml）或 Renovate（renovate.json）。

严重级别：该类别没有 Critical 项；没有 CI 流水线、完全没有测试（CI 无法运作）为 Recommended；没有 dependabot、没有 hooks、没有覆盖率为 Nice-to-have。

7. 元数据（Metadata）

按生态检查元数据完整性：

Node.js：package.json 中的 repository、engines、keywords、description
Python：pyproject.toml 中的 [project.urls]、classifiers、requires-python、keywords、description
Rust：Cargo.toml 中的 repository、keywords、categories、description
Go：模块路径与仓库 URL 匹配、包文档注释

严重级别：该类别没有 Critical 项；包元数据中没有仓库 URL 为 Recommended；缺少 engine/version、keywords、description 为 Nice-to-have。

使用方式

技能开始时需要声明：“I'm using git-repo-prep:review to audit this repo for openness.” 然后建立 TodoWrite 检查清单，按类别顺序逐项执行。发现结果以对话形式呈现，不写报告文件。结果按严重级别分组，从最紧急的开始：Critical（公开前必须修复）、Recommended（为高质量发布应处理）、Nice-to-have（打磨改进）。每条发现需简要描述问题、用一句话说明它对开放性的影响，并主动提出可以立即修复。最后给出统计：“X critical, Y recommended, Z nice-to-have findings.” 如果存在 Critical 发现，建议在发布前处理；如果没有，则说明仓库看起来已就绪，并建议处理 Recommended 项以进一步打磨。

适用场景

适合在将代码仓库公开（开源发布）之前做发布前自查，也适合在开发过程中任意阶段重复运行，用于持续检查密钥泄露、个人信息、许可证一致性、文档完整性、.gitignore 覆盖、CI/CD 配置和元数据完整性。

限制

技能明确限定为开放性审计，不评估代码质量，不评论错误处理、架构、性能、代码风格、测试覆盖质量或设计模式。严重级别必须严格按技能给出的表格分类，不得自行发明类别，也不得升级或降级严重级别。发现结果以对话形式呈现，不生成报告文件。