我发现代码审查特别适合做成 Skill，因为 review 的评价标准应该稳定，而不是每次靠一句“帮我看看代码”。
为什么要做成 Skill
临时 prompt 容易出现两个问题：
- 模型开始评价命名、格式、风格，但漏掉真正的 bug。
- 输出很散，不方便你逐条处理。
Skill 可以把优先级固定下来：先 correctness，再 regression，再 tests，最后才是 style。
一个可直接改的 SKILL.md
---
name: bug-focused-review
description: Review code changes for correctness bugs, regressions, risky behavior, and missing tests. Use when reviewing a PR, diff, or uncommitted changes.
---
# Bug-focused Review
When reviewing:
1. Read the diff before making claims.
2. Prioritize bugs that can change runtime behavior.
3. Ignore pure style unless it hides a bug.
4. Include file path and line reference.
5. Explain the user-visible impact.
6. Mention test gaps only when they reduce confidence.
Output:
## Findings
- Severity, file, line, problem, impact, suggested fix.
## Open Questions
- Only ask if the answer changes the review result.
## Verification
- Commands or manual checks that should be run.
适合放在项目级还是个人级？
我的建议：
- 通用 review 规则：放个人级 Skill。
- 项目特定规则：放仓库级
.claude/skills或.codex/skills。
比如前端项目可以补：
For UI changes, verify responsive layout and screenshot evidence.
For API changes, check backward compatibility.
For database changes, check migrations and rollback path.
配合 Codex 的用法
让 Codex 先改代码，再用 review skill 做第二轮审查。
我自己的习惯是：
先实现，不要大改架构。实现后用 bug-focused-review 自查一遍，列出必须修的问题。
这比“写完顺便看看”靠谱得多。
3 个帖子 - 2 位参与者
来源: LinuxDo 最新话题查看原文