agentleFS
PANYUXIN6PANYUXIN6/pyx-skills/code-review/SKILL.md

code-review

Skill8 starsChanged 3 months agoMITView on GitHub

审查代码和供机器使用的实现产物中的缺陷、风险、质量、正确性、需求或标准问题。用户要求实现审查、发现或审查结论(包括聚焦审查)时使用。排除对散文文档的审查,以及仅要求阅读、解释、总结、绘制地图或追踪实现的请求;单独使用“检查”或“查看”等中性动词不构成审查意图。

194 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use close-spec, design-with-images and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • dzhngSkill

    close-spec

    When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).

    Also in 5 projects that use this

  • dzhngSkill

    design-with-images

    Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.

    Also in 5 projects that use this

  • PydanticSkill

    add-new-model

    Add support for a newly-released language or image generation model in pydantic-ai (e.g. openai:gpt-5.6, anthropic:claude-sonnet-5, openai:gpt-image-2). Use when a provider ships a new model id and you need to wire literals, profile flags, adapters, and tests to recognize it. Handles SDK-lag, gateway list conventions, capability probing, and direct image-model geometry.

    Also in 9 projects that use this

  • transitive-bullshitSkill

    compare-screenshots

    Compare screenshots against the intended design, distinguishing approved references from historical baselines. Use for iterative implementation matching, before/after visual review, objective image telemetry, or checking a lone capture for flat, empty, or badly framed content.

    Also in 5 projects that use this

  • Microsoft AzureSkill

    azsdk-common-apiview-feedback-resolution

    Analyze and resolve APIView review feedback on Azure SDK PRs. **UTILITY SKILL**. USE FOR: APIView comments, API review feedback, SDK API surface changes. DO NOT USE FOR: general code review, non-APIView feedback. INVOKES: azure-sdk-mcp:azsdk_apiview_get_comments, azure-sdk-mcp:azsdk_customized_code_update, azure-sdk-mcp:azsdk_typespec_delegate_apiview_feedback, azure-sdk-mcp:azsdk_run_typespec_validation, azure-sdk-mcp:azsdk_package_generate_code.

    Also in 6 projects that use this

  • Microsoft AzureSkill

    azsdk-common-generate-sdk-locally

    Generate and finalize Azure SDKs locally from TypeSpec, including build, checks, tests, changelog, metadata, and version updates by default. WHEN: "generate SDK locally", "build SDK", "run SDK tests", "run CI checks", "validate package", "run checks", "update changelog", "fix SDK build errors", "resolve SDK generation errors", "customize TypeSpec", "rename SDK client", "rename SDK model", "hide operation from SDK", "fix analyzer errors", "resolve customization drift", "create subclient", "update metadata", "update version". INVOKES: azsdk_verify_setup, azsdk_package_generate_code, azsdk_package_build_code, azsdk_package_run_check, azsdk_package_run_tests, azsdk_customized_code_update, azsdk_package_update_changelog_content, azsdk_package_update_metadata, azsdk_package_update_version.

    Also in 6 projects that use this

  • +4 more from dzhng
  • +2 more from Azure

The file

Files
SKILL.md

代码审查

本技能是代码审查的轻量协调层。Codex 负责理解意图、契约、行为和风险;scripts/review.mjs 负责可机械判定的目标成员、快照、证据坐标、声明的处理状态、质疑覆盖、输入新鲜度和结论一致性。Runner 不派发模型,也不能证明代理理解了项目,或质疑结论在语义上真实、独立;命令成功只能证明冻结输入和已记录的流程状态,不能证明语义完整性或正确性。

在用户另行授权修复前,目标代码、规格和 Git 历史保持只读。除非用户明确选择其他位置,运行时和候选产物只能写到目标仓库外。

调用 Runner 或创建审查产物前,同时需要实现目标和明确审查意图。查找缺陷或风险、评估质量、验证正确性或需求符合性、检查编码或实现标准、执行具名审查维度,或产出 Findings,都满足意图门槛。仅阅读、解释、总结、绘制地图,或追踪架构、数据流、实现行为或实现方法的请求不满足。“inspect”“check”“look at”或“检查一下”等中性动词单独出现也不满足。探索性请求不得调用 Runner 或创建 Finding 产物;使用普通仓库探索或其他直接适用技能。

审查目标必须至少包含一个软件实现产物。散文需求和设计文档只能作为评估实现的权威或上下文。用户要求审查文档自身的清晰度、结构、一致性或设计质量时,本技能和 Runner 不适用。

模型与推理配置

主审和发现质疑统一使用 gpt-6.1-sol,推理程度为 xhigh。只有已确认当前会话同时使用这两项设置时,才在当前会话执行语义审查。

技能文本不能切换宿主会话的模型。当前设置不符或无法确认时,使用 Native spawn_agent,明确传入 model: "gpt-6.1-sol"、reasoning_effort: "xhigh" 和 fork_turns: "none",将完整审查交给一个主审子代理。提供用户请求、目标绝对路径、已确认约束与验收来源、本技能绝对路径;由该代理读取技能并执行后续完整流程。主审子代理以 Native 任务的明确派发参数确认设置,不再为模型设置重复委派主审。宿主依据返回的 Runner 产物核对并交付结果,不重复全面审查。Native 委派或指定模型、推理程度不可用时,说明限制并停止,不静默替换设置。

独立质疑子代理也明确传入上述模型、推理程度和隔离参数;是否需要独立质疑仍按 发现质疑协议 的风险路由决定。

1. 确定权威和目标

阅读约束目标的全部仓库规则,如适用的 AGENTS.md、CLAUDE.md、CONTRIBUTING.md 和编码标准。只加载与变更模块、契约或调用路径有关的架构文档和 ADR。仓库规则和已确认需求优先于本通用基线。

解析被请求目标:

  • 当前变更:将 HEAD -> index 已暂存变更、index -> worktree 未暂存变更及未跟踪文件作为独立项目冻结;绝不可合并为一个 HEAD -> worktree 净 diff。
  • 分支、提交、范围或 PR 对比:只解析一次固定比较点;三点比较使用其合并基点。
  • 当前状态功能审查:从入口、调用方、契约、配置和测试中按语义发现完整文件范围,再将其作为显式文件冻结;此模式不需要 Git、diff 或基线。
  • 只有归因变更、回归、遗漏或变更集范围结论需要 Git 基线。仓库证据无法识别所请求目标时才询问。

“已修复,再审查”等后续请求,除非用户要求更广范围,否则默认验证原发现、修复变更及受影响调用路径。把已有报告和质疑记录作为证据线索。重新检查先前反证是否仍适用;只有新证据、契约变更或相关代码变更使其失效时,才重新提出已反驳的主张并解释原因。insufficient_evidence 不是反驳。针对当前后续范围准备全新运行;不得把旧锚点、处理状态、质疑结论或批准当作当前验证。报告原发现的当前状态,并让结论仅覆盖实际复查内容;仅验证修复并不批准整个 PR。

工作区使用 node <skill-directory>/scripts/review.mjs prepare --repo <repository>;固定范围增加 --base <ref> --head <ref>;当前状态范围重复使用 --file <path>。读取返回的 queue_path,而非完整 Manifest:队列只含语义审查所需的项目 ID、路径、变更范围、元数据和排除项。冻结源代码相对于队列目录位于 snapshots/<item_id>.before|after;完整完整性数据由 Runner 保留在模型上下文外。

只有命令失败、输入被排除或失效、运行必须恢复或诊断,或信任边界重要时,才阅读 确定性审查运行时协议。Node.js 或 Runner 不可用,或目标仅远程/粘贴、无法表示时,披露 UNMANAGED_REVIEW;只在有用时继续,绝不输出 APPROVE,也不声称覆盖完整。

diff 超过约 500 行时,按模块或功能总结并分批审查队列。混合问题按逻辑功能而非文件顺序分组,但每个项目仍必须有明确处理状态。

2. 选择一个主流程

完整阅读且只阅读一个主流程:

场景主流程
当前工作区、常规 PR、提交、范围,或没有规格验收的具名功能审查常规审查
验证当前实现或明确变更集是否符合已确认规格、工单或验收标准验收审查
用户明确限制为安全、可靠性、架构、SOLID、性能、正确性、规格符合性或移除候选项聚焦审查

能够解析的一般代码审查请求默认使用常规审查。只有常规与验收审查会实质改变结论时才澄清。

3. 加载有理由的审查模块

加载工作流默认项后,只加载请求或具体信号证明合理的模块:

模块加载条件
正确性与质量常规默认;聚焦正确性、性能、错误处理或边缘情况;承载这些风险的验收变更
安全与可靠性身份验证、授权、输入、支付、机密信息、写入、事务、并发、外部调用或资源消耗
架构与标准验收默认;模块或公开契约边界、继承、新抽象、大型重构、架构或 SOLID
规格符合性验收默认;聚焦规格、工单或验收标准比较
移除计划弃用、被替代、禁用或未使用的路径;明确的清理候选审查

聚焦审查不得超出请求维度。不要用加载检查清单模块替代追踪实际代码路径。

4. 按语义审查并确定性记录

对每个待处理队列项目:

  1. 检查所选模块所需的相关变更或当前状态文件、调用方、使用者、契约和测试。
  2. 提出并质疑具体缺陷假设。区分已验证行为和可能性;没有可复现触发条件或契约违反的主张一律省略。
  3. 只有完成上述工作后才把项目记录为 reviewed。这只是代理声明,不是分析已发生的机械证明。以真实原因记录 skipped 或 failed;绝不利用处理状态夸大语义覆盖。

当前状态功能范围扩大时,丢弃旧运行,以完整显式文件集准备新运行。仅为解释变更项目而读取的仓库上下文无需成为发现目标;任何用作发现位置的文件必须属于 Manifest。

5. 验证候选项、质疑发现并限制结论

创建一个符合 findings.schema.json 的 schema-version-2 候选文档。每个 Finding 绑定到精确 Manifest item_id。使用包含路径、侧别、范围和 existing_code 的行锚点;没有文本块的变更则使用包含精确冻结 Git 元数据变更的文件锚点。还需包含 P0–P3 严重性、触发条件、影响、证据和最小安全修复方向。

先评估契约、触发条件和影响,再确定严重性。可维护性 P2 必须指出受影响的现有使用者、已确认变更场景或适用仓库规则,并解释足以阻断批准的具体成本或风险。假设性的可扩展性担忧或个人设计偏好不充分;仅引用规则不能确立 P2 影响。

所有处理状态更新后运行 validate;从冻结快照修正被拒绝锚点,或省略该 Finding。之后的任何 mark 都会使已验证集合和全部质疑决定失效,因此最终确定前重新验证。绝不可猜测性地移动评论。validate 只是机械准入候选项,并不证明缺陷存在。

至少有一个候选项验证通过时,完整阅读 发现质疑协议。每个验证候选项恰好质疑一次,不再做一次一般审查。协议的风险路由证明协作成本合理且 Native 委派可用时,使用全新只读子代理做独立质疑;否则进行其允许的有限自我质疑。验证者只能确认、反驳或声明给定候选项证据不足;不得修改代码、提出新发现或继承完整实现对话。

创建一个符合 challenges.schema.json 的质疑文档,然后运行 challenge。最终 Findings 章节只能由 Runner 生成的 confirmed_findings_path 填充。被反驳的候选项留在质疑摘要中,不放入缺陷列表。证据不足的 P2/P3 候选项作为明确剩余风险保留。证据不足的 P0/P1 候选项或 scope_status: expanded 会阻断 APPROVE;不得悄然忽略或递归启动完整审查。

使用预期工作流结论运行 finalize,且只采用 Runner 允许的结果。确认的 P0–P2 发现阻断批准。不得将 PARTIAL、INVALIDATED、排除输入、未解决高风险候选项、范围扩大或被阻断结论转化为批准。

根据确认发现和质疑摘要生成所选工作流的面向用户报告。说明冻结范围、工作流和维度、按结论统计的候选数量、质疑方式、已执行与仅观察到的检查、被排除或未完成项目、未审查区域和剩余风险。没有确认发现时可以如实说明,但不得暗示超出冻结目标、声明处理状态和已记录质疑所能证明的内容。

不要把“AI 再也找不到问题”当作完成标准,也不要为了寻求零新发现启动第二次全面审查。冻结队列全部处理、每个候选项都有一个质疑决定、Runner 允许所述结论、必需检查已报告真实状态,且验收审查的每条适用验收标准已有记录结果时,结束本次审查。只有当前输入上的必需测试、类型检查、lint、构建或 CI 通过,或已明确确认不适用,且所有适用验收标准通过时,才选择 APPROVE;必需证据未执行或仍不可用时使用 COMMENT。APPROVE 只限定于该流程状态,并不证明全局语义完整。随后等待单独授权后再修复任何内容。

例外情况

  • 空范围:报告检查内容,保持不批准;存在合理替代范围时询问。
  • 必需基线无效:停止比较审查,不做通过/失败归因。
  • 当前状态验收且无基线:披露未审查历史、回归和变更集归因。
  • 缺少已确认验收来源:询问位置;只有用户确认不存在时才省略该维度。
  • 输入漂移:将运行视为 INVALIDATED,准备新运行,不复用旧锚点或覆盖。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.