菜单
Aggressively review changed code for unnecessary complexity and propose smaller, clearer, behavior-preserving alternatives. Use for code reviews, refactor assessments, or any diff where simplification, deletion, reuse, flatter control flow, or fewer abstractions may improve the implementation.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Devolutions/IronRDP --skill code-compressor命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Derive and validate the canonical scope for IronRDP Conventional Commit and pull-request titles. Use whenever composing, reviewing, correcting, or checking a commit or PR title, especially when several crates or product surfaces intersect.
Write or substantially revise a Rust crate's README.md as a concise, user-facing design document. Use whenever creating a crate README, documenting a planned crate, or defining a crate's purpose, role, or interface before implementation.
Create and integrate a new Rust crate in the IronRDP workspace. Use whenever adding, scaffolding, or initializing a crate under crates/, including requests that mention cargo new, a new library package, or registering a crate in the architecture.
基于 SOC 职业分类
正在显示 SKILL.md
| name | code-compressor |
| description | Aggressively review changed code for unnecessary complexity and propose smaller, clearer, behavior-preserving alternatives. Use for code reviews, refactor assessments, or any diff where simplification, deletion, reuse, flatter control flow, or fewer abstractions may improve the implementation. |
Treat every added branch, state, abstraction, helper, conversion, and dependency as complexity that must earn its place. Look for duplicated logic, speculative generality, needless indirection, over-modeled state, tangled control flow, verbose data transformations, and code that existing APIs can replace.
Be aggressive in searching, but evidence-driven in reporting. Recommend a simplification only when you can describe a concrete, smaller alternative and explain why it preserves required behavior. Account for error handling, ownership, lifetimes, performance, public API stability, and repository conventions. Do not trade explicit correctness or necessary protocol detail for fewer lines.
Report each opportunity with its location, the complexity it removes, the proposed shape, and any meaningful tradeoff. Separate optional compression opportunities from correctness defects. Omit formatting, naming preferences, and vague rewrite requests. If the code is already close to the simplest correct form, return no findings.
