函数级代码审查 · 勾选文件校验 · 敏感信息扫描 · 中英文 Commit Message
code-commit-review 是一个面向提交前质量门禁的 Codex Skill，优势是把“勾选文件确认、函数级代码审查、敏感信息扫描、安全缺陷扫描、公共远程风险判断、规范 Commit Message 生成”串成一套完整流程。它会逐个阅读用户准备提交的函数、接口、配置和 SQL 变更，重点检查密钥、token、密码、私钥、内部地址、PII、日志泄露、权限绕过、注入、XSS、SSRF、路径穿越、事务边界、数据丢失和测试缺口，最后按完善的提交规范生成中英文双语 commit message。
它适合这些场景：
- 用户截图 IDE 的 Changes / Staged 区域，让 Codex 审查勾选文件。
- 用户准备 commit / push 前，希望确认是否误勾了不该提交的文件。
- 用户希望检查改动中是否包含密钥、凭据、敏感字段、日志、构建产物或本地配置。
- 用户希望 Codex 对前端、后端、SQL、配置和脚本变更进行函数级/语句级审查。
- 用户希望发现安全缺陷、功能缺陷、数据风险、公共远程泄露风险和缺失测试。
- 用户希望根据统一规则生成结构完整的中文和英文 commit message。
将整个目录放到 Codex 的 skills 目录中：
cp -R /Users/heidanr/IdeaProjects/code-commit-review /Users/heidanr/.codex/skills/code-commit-review安装后可用以下命令校验：
python3 /Users/heidanr/.codex/skills/.system/skill-creator/scripts/quick_validate.py \
/Users/heidanr/.codex/skills/code-commit-review看到以下输出即表示 Skill 可被 Codex 正常识别：
Skill is valid!
在 Codex 中可以这样触发：
用 $code-commit-review 帮我审查这次勾选的 changes，并生成中英文 commit message
也可以用自然语言触发：
帮我审查勾选文件并生成 commit message
我准备提交这些文件，帮我检查有没有误勾、敏感信息和代码问题
根据这张 Changes 区域截图，审查选中文件并生成 commit massage
说明：commit massage 是常见误拼，Skill 会按 commit message 理解。
推荐用户提供：
- IDE Changes / Staged 区域截图，能看到被勾选文件。
- 当前仓库路径，或让 Codex 在当前工作区执行 Git 命令。
- 如只想审查 staged 文件，需要明确说明“只审查暂存区”。
- 如截图中包含新建但未跟踪文件，需要允许扫描 untracked 文件。
Skill 会同时检查 Git 状态：
git status --short
git diff --stat
git diff --name-status
git diff --cached --stat
git diff --cached --name-status如果截图中的勾选文件与 Git 实际变更不一致，Skill 应先报告不一致，不应直接生成 commit message。
Codex 首先从截图或用户描述中识别被勾选文件，并列出每个路径。
随后与 Git 状态对比：
git diff --name-only: 未暂存变更。git diff --cached --name-only: 已暂存变更。git ls-files --others --exclude-standard: 需要时检查未跟踪文件。
需要重点检查：
- 是否误勾了无关文件。
- 是否漏勾了和本次变更强相关的文件。
- 是否混入个人 IDE 配置，如
.idea/、.vscode/。 - 是否混入构建产物，如
dist/、build/、coverage/。 - 是否混入日志、dump、数据库文件、备份文件。
- 是否混入
.env、私钥、证书、token、密码、内部地址等敏感内容。
Skill 只审查用户意图提交的文件，不主动扩大范围。
对每个被选中文件：
- 使用
git diff -- <file>查看未暂存差异。 - 使用
git diff --cached -- <file>查看暂存差异。 - 打开变更函数、类、组件、接口、配置块周边代码。
- 必要时沿调用关系阅读相邻文件，但不审查无关改动。
审查粒度要求达到函数级：
- 修改了哪个函数。
- 函数输入输出是否变化。
- 边界条件是否完整。
- 错误路径是否处理。
- 调用方是否仍兼容。
- 是否需要测试覆盖。
在 Git 仓库中运行：
python3 scripts/scan_commit_risks.py --repo <repo>只扫描暂存区：
python3 scripts/scan_commit_risks.py --repo <repo> --staged包含未跟踪文件：
python3 scripts/scan_commit_risks.py --repo <repo> --include-untracked输出 JSON：
python3 scripts/scan_commit_risks.py --repo <repo> --json扫描脚本会初筛：
- 私钥块，如
-----BEGIN PRIVATE KEY-----。 - AWS Access Key。
secret、token、api_key、password等赋值。- Bearer Token。
- 带密码的数据库连接串。
- JWT 形态 token。
.env、.pem、.key、.p12、.pfx等敏感文件名。.idea/、.vscode/、node_modules/、dist/、build/、coverage/等本地或生成目录。.log、.dump、.sql、.sqlite、.db、.bak等日志、备份或数据文件。- 大文件和二进制文件。
注意：扫描脚本只提供候选风险，不等于最终结论。所有高风险命中都必须人工阅读确认。
审查应优先报告真实风险，而不是泛泛建议。
正确性检查：
- 空值、未定义、类型转换。
- 边界条件、越界、分页、排序、过滤。
- 异步竞态、重复请求、取消和超时。
- 错误处理、重试、回滚、幂等。
- 数据丢失、事务边界、迁移兼容。
- API 入参、返回值、状态码和错误码。
安全和隐私检查：
- 硬编码密钥、token、密码、证书。
- 内部域名、数据库地址、云资源地址。
- PII、手机号、身份证、邮箱等敏感信息。
- 权限绕过、认证缺失、越权访问。
- SQL/NoSQL/命令注入。
- XSS、SSRF、路径穿越。
- 不安全反序列化。
- 弱加密或自定义加密。
- 日志输出敏感数据。
- 不该推送到公共远程库的文件或字段。
可维护性检查：
- 重复逻辑。
- 命名不清。
- 死代码。
- 调试代码。
- 大段注释掉的代码。
- 脆弱耦合。
- 过度抽象或缺少必要抽象。
集成风险检查：
- API 合约变化。
- 数据库 schema 兼容性。
- 生成客户端是否同步。
- feature flag 默认值。
- i18n 文案是否完整。
- 配置项是否有安全默认值。
- 部署环境是否具备新增依赖。
Codex 应尽量运行与改动范围匹配的验证：
- 单元测试。
- 集成测试。
- 类型检查。
- lint。
- build。
- 相关脚本自测。
如果没有运行，需要说明原因，例如：
- 仓库没有测试命令。
- 依赖未安装。
- 测试耗时过长。
- 需要外部服务或凭据。
- 用户只要求静态审查。
输出应先给结论，后给 commit message。
推荐格式：
**审查结果**
- [P1] src/example.ts:42 - 这里说明问题和影响
**勾选文件检查**
- 确认应提交文件:
- 疑似误勾/不建议提交:
- 未勾选但相关修改:
**敏感信息与公共远程风险**
- 结论:
- 证据:
**验证**
- 已运行:
- 未运行:
**Commit Message 中文**
```text
...
```
**Commit Message English**
```text
...
```优先级定义：
P0: 必须阻止提交的问题，如真实密钥泄露、数据破坏、严重安全漏洞。P1: 应在提交前修复的问题，如明显功能缺陷、权限缺失、重要边界错误。P2: 建议修复的问题，如可维护性问题、测试缺口、较低风险边界问题。
如果没有发现问题，需要明确写：
未发现阻止提交的问题。
如果存在 P0/P1 或疑似敏感信息未确认，不应直接给出可提交的 commit message，应提示“建议暂缓提交”。可在必要时给出“修复后可使用的 commit message 草案”。
本 Skill 默认生成两版 commit message：
Commit Message 中文: Header 保持英文规范，subject 和 body 使用中文。Commit Message English: Header、subject 和 body 使用英文。
两版应使用相同的 type 和 scope，除非项目已有明确不同规范。
提交消息应服务于清晰的分支管理。审查时需要结合当前分支判断本次提交是否符合分支职责。
| 分支 | 功能定位 | 对应环境 | 是否可访问 | 命名规则 |
|---|---|---|---|---|
master |
主分支，稳定版本，用于生产部署 | PRO |
是 | 固定分支名 master |
develop |
开发环境分支，保持最新完成代码和 bug 修复代码 | DEV |
是 | 固定分支名 develop |
feature |
新功能开发分支，从 develop 创建 |
无固定环境 | 否 | feature/<module>，如 feature/user_module |
test |
测试环境分支，供测试人员进行功能测试 | FAT |
是 | 固定分支名 test 或按团队规范扩展 |
release |
预上线分支，用于 UAT 和发布准备 | UAT |
是 | release/<version> |
hotfix |
线上紧急修复分支，从 master 创建，修复后合并回 master 和 develop |
无固定环境 | 否 | hotfix/<issue-or-module> |
分支使用规则：
master必须保持稳定，只能通过release或hotfix合并，不建议直接修改代码。develop是日常开发基础分支，新功能分支应从develop创建。feature用于开发新功能，命名应体现模块，例如feature/cart_module。test用于功能测试，版本相对稳定，不应混入无关开发改动。release用于预发布和 UAT，通常由test或hotfix合并，不建议直接修改代码。hotfix用于线上紧急修复，修复后必须同步回master和develop。
- 单次提交的问题必须属于同一类别。
- 单次提交的问题不要超过 3 个。
- 如果提交后发现 commit message 不符合规范，优先使用
git commit --amend -m "新的提交信息"修正。 - 如果提交内容本身需要拆分，可重新整理后再提交；不要把前端、后端、SQL、配置、文档等无关改动混在同一次提交里。
<type>(<scope>): <subject>
<body>
<footer>
说明：
Header必填。Body可省略，但本 Skill 推荐提供，用于说明动机和行为变化。Footer仅在存在破坏性变更或关闭 issue 时填写。
Header 由三部分组成：
<type>(<scope>): <subject>
示例：
feat(Auth): add login session refresh
fix(Validation): 修复表单边界校验
type 用于说明提交类别，必须从以下值中选择：
| Type | 含义 | 使用场景 |
|---|---|---|
feat |
新增功能 | 新增功能、能力、接口或用户可见行为 |
fix |
修复 bug | 完整修复一个 bug 或缺陷 |
docs |
仅文档更改 | README、注释、接口文档、使用说明等 |
style |
不影响代码含义的更改 | 空白、格式设置、缺失分号等 |
refactor |
代码重构 | 既不修复 bug，也不添加特性的代码更改 |
perf |
性能改进 | 改进性能、响应速度、资源使用或体验 |
test |
测试变更 | 添加缺少的测试或更正现有测试 |
chore |
构建或辅助工具变更 | 构建过程、工具、依赖、脚本、库配置等 |
选择建议：
- 新增业务能力、页面、接口或用户可见行为，用
feat。 - 修复已知 bug、异常流程或错误结果，用
fix。 - 只修改 README、注释、接口文档或使用说明，用
docs。 - 只修改格式且不影响代码含义，用
style。 - 不改变外部行为，只调整结构或实现方式，用
refactor。 - 明确改善性能、响应速度或资源使用，用
perf。 - 添加缺少测试或更正现有测试，用
test。 - 修改构建、依赖、脚本、工具链或辅助库配置，用
chore。
scope 用于说明影响范围，可选但推荐填写。
常见 scope：
AuthUserValidationDataAccessControllerAPIUIConfigBuildDocsSkill
规则：
- 只影响一个清晰模块时，使用模块名。
- 影响多个模块且无法准确概括时，可使用
*。 - 不要为了填写而填写过宽的 scope。
- scope 命名应贴近项目已有目录、模块或层级名称。
示例：
feat(UserProfile): 添加用户资料编辑入口
fix(DataAccess): correct query pagination
chore(*): update repository skill metadata
subject 是本次提交目的的简短描述。
规则：
- 尽量不超过 50 个字符。
- 使用动词开头。
- 不以句号结尾。
- 英文版使用小写动词开头，使用现在时。
- 中文版使用清晰动作开头，如“新增”“修复”“调整”“优化”“补充”“移除”。
- 不要写成“修改代码”“更新文件”这类无信息量描述。
英文示例：
fix(Validation): correct input boundary checks
中文示例：
fix(Validation): 修复输入边界校验
Body 用于说明本次提交做了什么、为什么做，以及行为前后的差异。
推荐包含：
- 变更动机。
- 主要改动点。
- 之前行为。
- 现在行为。
- 影响范围。
- 安全或兼容性说明。
- 测试或验证情况，必要时可简短提及。
当一次提交涉及多个技术层面时，Body 应按内容分区描述，避免把所有改动揉成一段。
推荐分区：
前端: 页面、组件、交互、状态管理、路由、样式、i18n、表单校验。后端: Controller、Service、DAO、权限、接口、任务、缓存、事务、错误处理。SQL: 表结构、索引、迁移脚本、初始化数据、查询语句、回滚方案。配置: 环境变量、构建配置、部署配置、feature flag、第三方服务配置。测试: 单元测试、集成测试、端到端测试、测试数据、mock 调整。文档: README、接口说明、变更说明、使用说明。
中文 Body 分区模板：
前端：
- 调整用户资料页编辑入口，补充提交前表单校验。
后端：
- 新增资料保存接口的权限校验和错误处理。
SQL：
- 新增 user_profile.nickname 索引，提升资料查询性能。
验证：
- 已运行用户资料模块单元测试和接口测试。
English Body section template:
Frontend:
- Update the profile edit entry point and add submit-time form validation.
Backend:
- Add permission checks and error handling for the profile save API.
SQL:
- Add an index on user_profile.nickname to improve profile lookup performance.
Verification:
- Run unit and API tests for the user profile module.
写作规则：
- 英文版使用现在时。
- 中文版保持简洁明确。
- 不要只重复 Header。
- 不要编造不存在的 issue、测试结果或破坏性变更。
- 每行尽量不要过长，便于终端阅读。
中文 Body 示例：
本次提交补充提交前代码审查 Skill 的完整说明，明确勾选文件校验、
敏感信息扫描、函数级审查和双语提交消息生成流程。
这样可以让使用者在提交前按统一步骤确认风险，并减少误提交本地配置、
凭据或无关文件的概率。
英文 Body 示例：
This commit documents the complete pre-commit review workflow for the
code-commit-review skill, including selected file checks, sensitive content
scanning, function-level review, and bilingual commit message generation.
The documentation helps users follow a consistent review process before
committing and reduces the chance of pushing local config, credentials, or
unrelated files.
Footer 只用于两类信息。
如果当前提交引入不兼容变化，使用：
BREAKING CHANGE: <description>
需要说明：
- 破坏了什么。
- 为什么必须这样改。
- 使用方如何迁移。
示例：
BREAKING CHANGE: rename the review output field from message to messages.
Consumers must read messages.zh and messages.en instead.
如果本次提交明确解决某个 issue，可使用：
Closes #234
多个 issue：
Closes #123, #245, #992
规则：
- 只有用户明确提供 issue 编号，或代码/分支信息中有可靠证据时才写。
- 不要凭空编造 issue。
中文：
feat(UserProfile): 新增用户资料编辑功能
前端：
- 新增用户资料页编辑入口和保存交互，用户可以直接在资料页更新个人信息。
后端：
- 补充资料保存接口处理逻辑，在提交路径中执行必要校验。
SQL：
- 本次提交不涉及数据库结构变更。
Closes #234
English:
feat(UserProfile): add user profile editing
Frontend:
- Add the profile editing entry point and save interaction so users can update
personal information directly from the profile page.
Backend:
- Add profile update handling and keep validation in the submit path.
SQL:
- This commit does not change the database schema.
Closes #234
中文：
fix(Validation): 修复输入边界校验
本次提交修复表单输入在边界值下校验不完整的问题。此前部分极限长度
或空白输入可能绕过校验，导致后续流程出现异常。
调整后，提交前会统一处理空值、长度和格式校验，并返回更明确的错误信息。
English:
fix(Validation): correct input boundary checks
This commit fixes incomplete validation for boundary input values. Previously,
some maximum-length or blank values could bypass validation and cause
unexpected behavior later in the flow.
The updated validation now handles empty values, length limits, and format
checks consistently before submit and returns clearer error messages.
中文：
docs(Skill): 补充代码审查 Skill 使用说明
文档：
- 补充 code-commit-review Skill 的完整 README，说明安装方式、触发方式、
审查流程、风险扫描脚本和双语提交消息规范。
验证：
- 已运行 Skill 校验和风险扫描脚本帮助命令。
English:
docs(Skill): document commit review skill usage
Docs:
- Expand the README for the code-commit-review skill with installation steps,
trigger examples, the review workflow, risk scanner usage, and bilingual
commit message rules.
Verification:
- Run skill validation and the risk scanner help command.
code-commit-review/
├── README.md
├── SKILL.md
├── agents/
│ └── openai.yaml
└── scripts/
└── scan_commit_risks.py
SKILL.md: Codex Skill 主体说明，定义触发条件、审查流程和输出格式。agents/openai.yaml: Codex UI 元数据，包括展示名称、简短描述和默认提示词。scripts/scan_commit_risks.py: 辅助风险扫描脚本，用于初筛疑似敏感文件、密钥、日志、dump、构建产物等。
出现以下情况时，应先阻止提交或要求用户确认：
- 发现真实密钥、token、密码、证书、私钥。
- 发现
.env或生产配置被选中。 - 发现数据库 dump、日志、备份文件包含敏感信息。
- 截图勾选文件和 Git 暂存/变更状态明显不一致。
- 选中了明显无关的大文件、构建产物或 IDE 私有配置。
- 存在 P0/P1 级代码缺陷，提交后会造成严重问题。
- 审查范围不清，无法确认用户真正想提交哪些文件。
这类情况下输出应类似：
建议暂缓提交。当前存在疑似敏感信息或高风险问题，需先确认并修复。
code-commit-review is a Codex Skill that turns pre-commit review into a complete quality gate: selected-file verification, function-level frontend/backend/SQL review, sensitive information scanning, security defect scanning, public-remote risk checks, and structured bilingual Conventional Commit generation.
It works as a pre-commit review gate:
- Identify selected files from IDE Changes / Staged screenshots.
- Compare selected files with
git diffandgit diff --cached. - Detect mistakenly selected, unrelated, generated, local-only, or sensitive files.
- Scan for secrets, credentials, tokens, private keys, internal hosts, PII, logs, dumps, and public-remote exposure risks.
- Review changed frontend, backend, SQL, config, and script code at function or statement level for correctness, security, maintainability, and integration risks.
- Run focused verification when feasible.
- Generate both Chinese and English commit messages only after the review is safe.
Quick trigger:
Use $code-commit-review to review the selected changed files and draft Chinese and English commit messages.
Risk scanner:
python3 scripts/scan_commit_risks.py --repo <repo>
python3 scripts/scan_commit_risks.py --repo <repo> --staged
python3 scripts/scan_commit_risks.py --repo <repo> --include-untracked
python3 scripts/scan_commit_risks.py --repo <repo> --jsonCommit message format:
<type>(<scope>): <subject>
<body>
<footer>
Allowed types:
feat, fix, docs, style, refactor, perf, test, chore
The Chinese and English versions should use the same type and scope. The Chinese version keeps the Header keywords in English and writes the subject/body in Chinese. The English version uses present tense, starts the subject with a lower-case verb, and omits the final period.
When the change touches multiple layers, split the body into clear sections such as Frontend, Backend, SQL, Config, Tests, and Docs.
Do not produce a ready-to-commit message when P0/P1 findings or unresolved secret risks remain. Ask the user to pause the commit and fix or confirm the risk first.
- 更新
SKILL.md后，重新运行quick_validate.py。 - 更新风险规则后，运行
python3 scripts/scan_commit_risks.py --help确认脚本可执行。 - 不要让扫描脚本自动判断“安全”，它只应输出候选风险。
- 不要让 Skill 自动执行
git add、git commit、git push，除非用户明确要求。 - 对公共远程库场景始终更保守，敏感信息风险优先级高于 commit message 生成。