关于 code-polish
Code Polish 是用于简化和审查 Git 仓库变更的技能。它在固定范围内处理有证据支持的问题,随后验证最终状态并报告发现与检查结果。
主要功能
- 01简化与审查模式
- 02固定且明确的变更范围
- 03按风险排序审查缺陷
- 04基于配置档案的审查指引
- 05针对性验证与报告
适用场景
- 01简化一组明确范围内的变更文件
- 02审查差异并修复有依据的问题
- 03通过针对性检查验证变更
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ paulrberg/ agent-skills --skill code-polish安装后在 Claude Code 中输入/code-polish确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
agents/openai.yamlreferences/profiles/configuration.mddata-formats.mdgo.mdnaming.mdpython.mdrust.mdsecurity.mdshell.mdtypescript.md详细介绍
代码润色
一次性确定范围。只进行高度确定的简化。根据缺陷风险和证据修复问题。验证最终状态。
模式
--simplify:仅简化。--review:仅审查和修复。- 两者都不指定或同时指定:先简化,再审查简化后的结果。
--with-profile <name>/--skip-profile <name>:添加或跳过审查配置。跳过优先。
固定范围
- 必须位于 Git 仓库中。
- 如果提供了显式路径、模式、范围、自然语言目标或
resolved-scope区块,则使用它们。否则,仅使用本次会话中修改的文件。如果无法获取会话历史,则使用所有未提交的已跟踪和未跟踪文件。 - 除非明确要求,否则手动审查时排除锁文件、生成的输出、供应商代码、压缩包和大型数据快照。通过其生成器、架构或不变量验证相关的排除输出。
- 确定并保留唯一权威的执行范围集及可选排除项。之后不得扩大或重新计算范围。如果范围为空,则停止。
简化
保留公共契约、输入、输出、副作用、错误行为、性能敏感特征、遥测和运行防护措施。只进行能明确改善可理解性或降低缺陷风险的更改:
- 扁平化可避免的控制流嵌套。
- 澄清容易误导的名称或过于密集的转换逻辑。
- 仅在抽象能降低整体复杂度时消除真正的重复。
- 收紧局部类型和契约,避免大范围改动。
- 仅移除由本次会话的编辑导致的死代码。
不要按行数拆分,不要进行架构清理,不要转换同步/异步 API,不要添加推测性的可配置项,也不要用只使用一次的抽象替换可读的重复代码。不作更改也是有效结果。
审查和修复
根据用户请求评估差异。按 CRITICAL → HIGH → MEDIUM → LOW 优先处理:
- CRITICAL:可利用的安全问题、数据丢失或关键服务中断路径。
- HIGH:影响核心行为的行为、错误路径、边界或性能缺陷。
- MEDIUM:资源泄漏、复杂度热点、测试缺口、范围过大的更改、推测性复杂度,或可能导致缺陷的薄弱成功标准。
- LOW:会造成实际维护成本的局部清晰度或风格问题。
每项发现都必须引用已验证的位置、触发输入/状态、失败模式、影响范围,以及更改代码中的证据。合并重复项,并应用有依据的最小修复。先根据请求和仓库消除意图歧义。说明常规假设。仅在答案会改变行为或范围时提问。在等待答复期间,继续处理范围内彼此独立的修复。
选择所有适用的配置,并各读取一次。在同一轮并行读取所有已选配置:
| 涉及领域 | 配置 |
|---|---|
| 身份验证、密钥、加密、外部输入/网络、不安全解析 | security |
| 环境、配置、超时、重试、连接池、限制 | configuration |
| Go 行为、并发、上下文、错误 | go |
| Rust、Cargo/工作区、异步/并发、不安全代码/FFI | rust |
| TypeScript 类型、模块、包、异步行为 | typescript |
| Python 服务、脚本、异步、打包、数据 I/O | python |
| 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、命令、位置、复现输入和安全证据须保持原样,不作修饰。
如果无法确认行为一致性或完成必要的高风险验证,或者修复需要未经请求的公共契约变更或更大规模的重新设计,则停止。