mcpField
C
code-polish

code-polish

github.com/paulrberg开发1022.8k 次安装今天更新
代码仓库

关于 code-polish

Code Polish 是用于简化和审查 Git 仓库变更的技能。它在固定范围内处理有证据支持的问题,随后验证最终状态并报告发现与检查结果。

主要功能

  1. 01简化与审查模式
  2. 02固定且明确的变更范围
  3. 03按风险排序审查缺陷
  4. 04基于配置档案的审查指引
  5. 05针对性验证与报告

适用场景

  1. 01简化一组明确范围内的变更文件
  2. 02审查差异并修复有依据的问题
  3. 03通过针对性检查验证变更

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/paulrberg/agent-skills --skill code-polish

安装后在 Claude Code 中输入/code-polish确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/profiles/
configuration.md
data-formats.md
go.md
naming.md
python.md
rust.md
security.md
shell.md
typescript.md

详细介绍

代码润色

一次性确定范围。只进行高度确定的简化。根据缺陷风险和证据修复问题。验证最终状态。

模式

  • --simplify:仅简化。
  • --review:仅审查和修复。
  • 两者都不指定或同时指定:先简化,再审查简化后的结果。
  • --with-profile <name> / --skip-profile <name>:添加或跳过审查配置。跳过优先。

固定范围

  1. 必须位于 Git 仓库中。
  2. 如果提供了显式路径、模式、范围、自然语言目标或 resolved-scope 区块,则使用它们。否则,仅使用本次会话中修改的文件。如果无法获取会话历史,则使用所有未提交的已跟踪和未跟踪文件。
  3. 除非明确要求,否则手动审查时排除锁文件、生成的输出、供应商代码、压缩包和大型数据快照。通过其生成器、架构或不变量验证相关的排除输出。
  4. 确定并保留唯一权威的执行范围集及可选排除项。之后不得扩大或重新计算范围。如果范围为空,则停止。

简化

保留公共契约、输入、输出、副作用、错误行为、性能敏感特征、遥测和运行防护措施。只进行能明确改善可理解性或降低缺陷风险的更改:

  • 扁平化可避免的控制流嵌套。
  • 澄清容易误导的名称或过于密集的转换逻辑。
  • 仅在抽象能降低整体复杂度时消除真正的重复。
  • 收紧局部类型和契约,避免大范围改动。
  • 仅移除由本次会话的编辑导致的死代码。

不要按行数拆分,不要进行架构清理,不要转换同步/异步 API,不要添加推测性的可配置项,也不要用只使用一次的抽象替换可读的重复代码。不作更改也是有效结果。

审查和修复

根据用户请求评估差异。按 CRITICAL → HIGH → MEDIUM → LOW 优先处理:

  • CRITICAL:可利用的安全问题、数据丢失或关键服务中断路径。
  • HIGH:影响核心行为的行为、错误路径、边界或性能缺陷。
  • MEDIUM:资源泄漏、复杂度热点、测试缺口、范围过大的更改、推测性复杂度,或可能导致缺陷的薄弱成功标准。
  • LOW:会造成实际维护成本的局部清晰度或风格问题。

每项发现都必须引用已验证的位置、触发输入/状态、失败模式、影响范围,以及更改代码中的证据。合并重复项,并应用有依据的最小修复。先根据请求和仓库消除意图歧义。说明常规假设。仅在答案会改变行为或范围时提问。在等待答复期间,继续处理范围内彼此独立的修复。

选择所有适用的配置,并各读取一次。在同一轮并行读取所有已选配置:

涉及领域配置
身份验证、密钥、加密、外部输入/网络、不安全解析security
环境、配置、超时、重试、连接池、限制configuration
Go 行为、并发、上下文、错误go
Rust、Cargo/工作区、异步/并发、不安全代码/FFIrust
TypeScript 类型、模块、包、异步行为typescript
Python 服务、脚本、异步、打包、数据 I/Opython
shell、CI、部署、安装程序、引号处理shell
CSV/JSON/YAML/二进制文件、架构、迁移、生成的数据data-formats
命名和意图清晰度naming,除非已跳过

配置文件位于 references/profiles/<name>.md。缺少已选配置文件时必须停止。

验证与报告

运行范围最小的格式化工具/Lint、定向测试、类型检查和不变量检查,以证明最终修改的行为。 仅在涉及共享契约时扩大范围。说明跳过了哪些检查及原因。

概述范围时,列出文件数量,以及最精简且有用的仓库相对根目录、glob、范围或用户提供的目标。不要仅为证明范围而逐一列出所有文件。仅在范围明确且文件较少,或需要说明例外和发现时,列出具体路径。

发现项包括严重程度、位置、影响、证据、修复方式和置信度。残余风险应说明相关假设、假设不成立时的后果,以及如何验证。

在 Issues and caveats 下,将有证据支持的已验证修复归为 Resolved,将遗留问题、限制或未经验证的假设归为 Open,并说明其影响和后续步骤。空组不写。每项只报告一次。中性背景和已达成一致的决策放在变更或范围部分。

仅当某项阻碍必需工作时,才使用 blocker;仅当存在具体潜在不利结果时,才使用 risk。如果底层问题仍影响结果,即使有变通方案,该项仍应保持为未解决。完成工作要求范围明确、编辑和发现可追溯,并有验证证据。

成功报告的开头应为 ### ✨ Code polish — ✅ complete,然后概述范围、有意义的变更和验证结果。结果较小时,使用简短文字。仅在有助于说明多项变更或发现时,才添加表格或章节。遵循用户要求的格式。

如果已进行审查且未发现缺陷,请写明 ✅ No verified review findings. 如果以下停止条件导致无法完成,请以 ### ✨ Code polish — ⛔ blocked 开头,并报告证据和所需决策。严重程度标记、配置文件 ID、命令、位置、复现输入和安全证据须保持原样,不作修饰。

如果无法确认行为一致性或完成必要的高风险验证,或者修复需要未经请求的公共契约变更或更大规模的重新设计,则停止。

评论

支持 Markdown