perf
Make code faster without making it more complex. Measures before changing anything, looks for a fundamental fix first, and otherwise redesigns around the critical path with special cases moved off it. Use when the user asks to optimise, speed up, or reduce the latency, allocations or memory of code, or to review a change made for performance. Use it even when the user names a specific micro-optimisation, because measuring comes first.
- License 许可
- MIT
- 最近更新
- 2026-10-16
- Stars
- ★ 2
- Forks
- 0
01 前言 Front Matter
- name
- perf
- license
- MIT
- description
- Make code faster without making it more complex. Measures before changing anything, looks for a fundamental fix first, and otherwise redesigns around the critical path with special cases moved off it. Use when the user asks to optimise, speed up, or reduce the latency, allocations or memory of code, or to review a change made for performance. Use it even when the user names a specific micro-optimisation, because measuring comes first.
- allowed-tools
- Read Grep Glob Bash AskUserQuestion mcp__plugin_software-design_software-design__interface
- compatibility
- Claude Code, Codex or pi with the software-design plugin, whose MCP server is built from source with Rust (rustup).
03 SKILL.md 正文
Design for performance
Clean design and speed usually agree: simple code does less redundant work, and deep modules cross fewer layers. Intuition about what is slow is unreliable, so nothing changes before it is measured.
Tools. The plugin's software-design MCP server provides two tools: check returns findings as JSON; interface returns signatures and interface comments without bodies. In Claude Code their full names are mcp__plugin_software-design_software-design__check and mcp__plugin_software-design_software-design__interface. The plugin root is two directories above this skill. Pass directory, the repository's absolute path, on every call: outside Claude Code the server does not run in the project. If neither tool is available, run the global installer at https://github.com/iaserrat/software-design to build the runtime, then start a new session. From an installed plugin directory, sh scripts/software-design install also builds it synchronously (log: ~/.software-design/build.log, needs Rust and a C compiler).
1. Measure
- Find or write a benchmark that reproduces the slow operation. Record the baseline numbers with the command that produced them.
- Measure below the top level until a small number of specific places account for most of the time. If the user cannot share a production profile, ask for one with AskUserQuestion rather than guessing.
2. Look for a fundamental fix
A cache, a different algorithm or data structure, or avoiding work entirely. Prefer the naturally efficient choice that is just as simple: a hash map over an ordered map when order is unused, one allocation instead of many.
3. Otherwise, design around the critical path
- Write down the smallest amount of code the most common case must run, ignoring the current structure: "the ideal".
- Find a clean design that comes as close to the ideal as possible.
- Move special cases off the critical path: ideally one test at the start detects every special case, and the common case runs without further checks.
- Remove shallow layers on the path; each crossing costs time and adds interface.
4. Keep only what helps
Re-run the benchmark with the same command. Keep a change only if it is measurably faster or simpler. Report the before and after numbers.
04 同仓库更多 Skills
review
Reviews code for design red flags, such as shallow modules, pass-through methods, information leakage, repeated code, comments that repeat code, vague names and ignored errors, and tests whether public interfaces can be used without reading their implementation. Ranks findings by how often the code changes and verifies each against the rule's own exemptions. Use when the user asks to review a diff, branch, pull request, file or directory for design quality, complexity or maintainability, asks whether code is well designed, or asks whether an API, class or module is clear or usable without reading its code.
document
Write or improve the interface and implementation comments of a module. Comments carry what the code cannot say (units, boundaries, invariants, errors, reasons) and never repeat the code. A comment that is hard to write is reported as a design problem. Use when the user asks to document, comment or explain a module, class, function or API, to fix poor or outdated comments, or when the software-design hooks report comments that repeat the code. Use it even when the user only asks to add comments or docstrings.
design
Designs the interface of a new class, module, API, service or feature before its code is written. Lists the knowledge the module hides, designs three competing interfaces in parallel, tests each on a reader who has never seen the code, compares the caller code each needs, and writes interface comments first. Use whenever the user asks to design, sketch, shape, structure or plan a class, module, API, interface or service, asks which methods or signatures something should have, wants to compare designs, or says "design it twice", even when they only describe what the code must do. Typical requests include "design the class interface", "what methods should this class have", "how should I structure this module", "sketch an API for", "design X before I write it", or any description of a class, module or API that does not exist yet.
change
Plan a change to existing code strategically. Before editing, works out what the code would look like had it been designed with this change in mind, compares that with the smallest patch, and lets the user choose. After editing, checks the diff for red flags and stale comments. Use when the user asks to add a feature to, fix, or extend existing code and the change adds a parameter, flag, special case or exception, touches a module's interface, or spreads across several files. Use it even when the request sounds like a small patch, because small patches are how complexity accumulates.
audit
Audit a whole repository or a large directory for design complexity. Ranks red flags by how often each file changes, verifies candidates against each rule's exemptions in parallel, has a cold reader judge the interfaces of the most-changed modules, and returns the investments worth making first. Use when the user asks for an audit, a design or complexity review of an entire codebase or package, a hotspot map, or where design work would pay off most. Use it even when the user only asks where the code is worst or what to clean up first.
release
Bump the version in every manifest, update the changelog, tag main and publish a GitHub release marked latest.