菜单
Use when asked to simplify code, clean up tech debt, improve readability, reduce complexity, or make a codebase easier to maintain.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/spencer-thompson/dotfiles --skill simplify命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | simplify |
| description | Use when asked to simplify code, clean up tech debt, improve readability, reduce complexity, or make a codebase easier to maintain. |
Improve the codebase by making it simpler, clearer, more maintainable, and easier to reason about.
The goal is not to make the code look more architected. The goal is to make future changes safer and easier.
Optimize for:
Before creating a new abstraction, look for code that can be deleted, inlined, merged, or simplified.
Good cleanup often means removing:
Do not add abstractions just because two things look similar. Abstract only when the abstraction makes the code easier to understand and change.
The best cleanup often has a negative diff.
Challenge repeated validation, impossible-state branches, error-hiding fallbacks, and extension points built for hypothetical needs. Keep a defense only when it protects a reachable failure mode or real boundary, such as untrusted input, external systems, security, stored data, concurrency, or resource cleanup. Confirm that need from call sites, types, invariants, tests, or documented behavior.
Private functions should earn their existence.
Inline private functions when they are:
Keep private helpers when they:
Do not "clean up" by adding layers.
Do not count as cleanup:
Consolidate duplicated logic only when the shared version is clearer.
Small obvious duplication is better than confusing reuse.
Do not create awkward abstractions for code that merely looks similar.
Use names that explain intent, not mechanics.
Avoid vague names like handle, process, run, execute, data, item, manager, helper, utils, result,
and config unless the scope makes them obvious.
Use straightforward code.
Prefer early returns, explicit conditionals, clear local variables, and nearby related logic.
Avoid clever chains, deep nesting, vague service layers, generic utility modules, and premature extension points.
Do not change behavior unless asked.
Before and after changes, run relevant tests, type checks, and linters when available.
Use subagents only when broad, separable, read-heavy discovery would materially improve speed or coverage. Handle focused or tightly coupled cleanup directly.
If using subagents:
Report:
Use concrete numbers when useful:
When in doubt, make the code more boring, direct, and obvious.
