code-review

Étoiles10

Forks4

Mis à jour25 juin 2026 à 05:43

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

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

Tokfinity

Tokfinity/InfCodeX

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

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.

Plus depuis ce dépôt

même dépôt

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.