code-review

스타10

포크4

업데이트2026년 6월 25일 05:43

审查代码、diff、提交或当前 git 改动，重点发现 bug、行为回归、边界条件遗漏、安全风险、性能问题和缺失测试。当用户提到 code review、review 这段代码、帮我看看改动有没有问题、审查 PR/提交时使用；不要用于单纯解释代码或直接实现需求。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

Tokfinity

Tokfinity/InfCodeX

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Code Review Skill

对 $ARGUMENTS 进行代码审查，并优先输出真正会影响正确性、稳定性或可维护性的发现。

范围判定

如果提供了 $ARGUMENTS，审查对应文件、目录、diff 或提交范围。
如果没有提供参数，优先审查当前 git 改动；如果不在 git 仓库中，就明确说明缺少范围并请求更具体的目标。
在下结论前，尽量查看相邻实现、调用方、测试和相关配置，避免脱离上下文的误报。

审查重点

正确性与回归风险：逻辑错误、边界条件、状态同步、类型假设、兼容性变化。
稳定性与安全性：异常处理、输入校验、资源泄漏、敏感信息暴露、权限或注入风险。
性能与可维护性：明显的复杂度问题、重复逻辑、难以验证的实现、缺失测试保护。
只报告有行动价值的问题。纯风格偏好或可选优化，不要包装成高优先级 finding。

严重级别

Critical: 会导致数据丢失、严重安全问题、崩溃或明显错误结果。
High: 很可能引发实际 bug、行为回归或线上风险。
Medium: 不是立刻出错，但会留下明显缺陷、维护风险或测试空洞。
Low: 小范围问题或局部改进点，仅在确实值得用户处理时报告。

输出要求

先给 ## Findings，并按严重级别从高到低排列。
每条 finding 都要包含：
- 严重级别和简短标题
- 具体文件和行号
- 为什么这是问题，可能造成什么影响
- 建议的修复方向
如果没有发现值得报告的问题，明确写 No findings.，然后补充剩余风险或测试空白。
需要时再追加 ## Open Questions 或 ## Change Summary，但不要用总体打分或“亮点”冲淡问题。

输出模板

## Findings
- [High] Title — `path/to/file.ts:42`
  Why it matters and what to change.

## Open Questions
- Optional clarification or assumption.

## Change Summary
- Optional short summary only after findings.

使用示例

/code-review src/auth.ts - 审查单个文件
/code-review packages/coding/src/ - 审查目录
/code-review - 审查当前 git 变更

Lean Review Lens

When the user asks for lean review, minimal diff, YAGNI, over-engineering, or native/stdlib replacement opportunities, add this lens after correctness and security findings:

Look for code, files, abstractions, dependencies, configuration, or workflow changes that can be deleted without losing requested behavior.
Prefer existing repository code, stdlib/native platform features, or an already-installed dependency when that is verifiably simpler than new custom code.
Do not recommend cutting trust-boundary validation, security checks, data-loss protection, accessibility basics, observability needed for safety, or explicitly requested behavior.
Do not present optional cleanup as a high-severity finding. Put non-blocking deletion/replacement ideas under ## Lean Suggestions.
For each lean suggestion, explain what can be skipped or removed and when it should be added back.

이 저장소의 다른 Skills

같은 저장소

skill-creator

Tokfinity/InfCodeX

创建、重写、迁移和优化 KodaX/Agent Skills。当用户想新建 skill、把外部 skill 迁移到 KodaX、改进触发描述、整理 supporting files、设计评测用例、补齐 grading/benchmark/review/comparison 流程或验证 skill 结构时使用。即使用户没有明确说“skill”，只要目标是在沉淀可复用的代理工作流、提示词或脚本能力，也应该使用这个 skill。

2026-06-2310

git-workflow

Tokfinity/InfCodeX

执行明确的 Git 操作，例如查看状态、提交、建分支、push、stash 或创建 PR。只有在用户明确要求实际执行这些 Git 操作时才使用；不要用于单纯解释 Git 概念或讨论策略。

2026-05-2410

tdd

Tokfinity/InfCodeX

用测试驱动开发方式实现或修复功能：先写失败测试，再做最小实现，最后重构。只在用户明确要求 TDD、先写测试、补回归测试或按 Red-Green-Refactor 工作时使用；不要用于单纯解释测试报错或泛泛讨论测试概念。

2026-05-2410

name	code-review
description	审查代码、diff、提交或当前 git 改动，重点发现 bug、行为回归、边界条件遗漏、安全风险、性能问题和缺失测试。当用户提到 code review、review 这段代码、帮我看看改动有没有问题、审查 PR/提交时使用；不要用于单纯解释代码或直接实现需求。
user-invocable	true
allowed-tools	Read, Grep, Glob, Bash(npm:, node:, npx:*)
argument-hint	[file-or-directory]
compatibility	Works best in a git repository or when the review target is provided explicitly.

Code Review Skill

对 $ARGUMENTS 进行代码审查，并优先输出真正会影响正确性、稳定性或可维护性的发现。

范围判定

如果提供了 $ARGUMENTS，审查对应文件、目录、diff 或提交范围。
如果没有提供参数，优先审查当前 git 改动；如果不在 git 仓库中，就明确说明缺少范围并请求更具体的目标。
在下结论前，尽量查看相邻实现、调用方、测试和相关配置，避免脱离上下文的误报。

审查重点

正确性与回归风险：逻辑错误、边界条件、状态同步、类型假设、兼容性变化。
稳定性与安全性：异常处理、输入校验、资源泄漏、敏感信息暴露、权限或注入风险。
性能与可维护性：明显的复杂度问题、重复逻辑、难以验证的实现、缺失测试保护。
只报告有行动价值的问题。纯风格偏好或可选优化，不要包装成高优先级 finding。

严重级别

Critical: 会导致数据丢失、严重安全问题、崩溃或明显错误结果。
High: 很可能引发实际 bug、行为回归或线上风险。
Medium: 不是立刻出错，但会留下明显缺陷、维护风险或测试空洞。
Low: 小范围问题或局部改进点，仅在确实值得用户处理时报告。

输出要求

先给 ## Findings，并按严重级别从高到低排列。
每条 finding 都要包含：
- 严重级别和简短标题
- 具体文件和行号
- 为什么这是问题，可能造成什么影响
- 建议的修复方向
如果没有发现值得报告的问题，明确写 No findings.，然后补充剩余风险或测试空白。
需要时再追加 ## Open Questions 或 ## Change Summary，但不要用总体打分或“亮点”冲淡问题。

输出模板

## Findings
- [High] Title — `path/to/file.ts:42`
  Why it matters and what to change.

## Open Questions
- Optional clarification or assumption.

## Change Summary
- Optional short summary only after findings.

使用示例

/code-review src/auth.ts - 审查单个文件
/code-review packages/coding/src/ - 审查目录
/code-review - 审查当前 git 变更

Lean Review Lens

When the user asks for lean review, minimal diff, YAGNI, over-engineering, or native/stdlib replacement opportunities, add this lens after correctness and security findings:

Look for code, files, abstractions, dependencies, configuration, or workflow changes that can be deleted without losing requested behavior.
Prefer existing repository code, stdlib/native platform features, or an already-installed dependency when that is verifiably simpler than new custom code.
Do not recommend cutting trust-boundary validation, security checks, data-loss protection, accessibility basics, observability needed for safety, or explicitly requested behavior.
Do not present optional cleanup as a high-severity finding. Put non-blocking deletion/replacement ideas under ## Lean Suggestions.
For each lean suggestion, explain what can be skipped or removed and when it should be added back.