菜单
Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or when getters/setters expose internal representation. Not for information leakage across boundaries (use information-hiding) or auditing configuration parameters (use pull-complexity-down).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add boilerplate without depth, or an abstraction feels leaky. Not for a single module's interface-to-implementation ratio (use deep-modules) or information leakage across boundaries (use information-hiding).
Evaluates whether changes to existing code maintain or degrade design quality. Use when reviewing diffs, PRs, or recently modified files to judge whether each change looks designed-in or bolted-on. Not for scanning design smells (use red-flags) or assessing overall design investment (use strategic-mindset).
Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when comments just repeat the code, or when something is hard to describe in a sentence. Not for naming or code obviousness (use naming-obviousness).
Diagnoses whether complexity exists and where it comes from, using the three-symptom, two-root-cause framework. Use when code feels harder to work with than it should but the specific problem is unclear. Not for scanning known design smells (use red-flags) or evaluating a module's depth (use deep-modules).
Measures module depth: whether the interface is simple relative to the implementation behind it. Use when an interface has too many parameters or methods, many small classes each do too little, or methods just forward calls. Not for whether adjacent layers provide different abstractions (use abstraction-quality) or merging/splitting modules (use module-boundaries).
Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design something twice, or before committing to any significant design of classes, modules, APIs, or architecture. Not for judging strategic vs. tactical investment in existing code (use strategic-mindset) or whether a change degrades design (use code-evolution).
基于 SOC 职业分类
| name | general-vs-special |
| description | Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or when getters/setters expose internal representation. Not for information leakage across boundaries (use information-hiding) or auditing configuration parameters (use pull-complexity-down). |
| argument-hint | [file or module path] |
| allowed-tools | Read, Grep |
When invoked with $ARGUMENTS, focus the analysis on the specified file or module. Read the target code first, then apply the checks below.
General-purpose modules are surprisingly simpler, deeper and less effort to build. They produce better information hiding and can even provide these benefits when used in a single context. Because a general-purpose interface doesn't need to know about specific callers, the knowledge always stays where it belongs.
"What is the simplest interface that will cover all my current needs?" — John Ousterhout, A Philosophy of Software Design
Not "the most general interface possible." The target is somewhat general-purpose.
A general-purpose interface is usually simpler than a special-purpose one. Fewer methods means lower cognitive load. Fewer methods per capability is the signal of increasing generality.
Two companion questions:
Special-purpose code mixed into a general-purpose module makes it shallower. Two forms:
Methods or parameters that only serve specific callers. The interface widens, and policy decisions from a higher layer get encoded in a lower one.
Special cases tend to show up as extra if statements. Instead of adding more of them, try to create a design where they disappear. A search function that returns null when nothing is found forces every caller to check for null before using the result. If you return an empty list instead, the check loop runs zero times on its own with no extra check required.
Before writing a getter or setter, ask the gatekeeping question: should callers know about this property at all? A rename() method absorbs related logic and hides the representation; the goal is for the module to do work, not expose data. For the fuller audit of why private plus getter/setter doesn't hide anything, see information-hiding.
Every sensible default is one less decision pushed to callers. If nearly every user of a class needs a behavior, it belongs inside the class by default.
Gatekeeping question: "Will callers be able to determine a better value than we can determine here?" The answer is usually no.
When unsure, err on the side of slightly more general. A slightly-too-general interface has unused capabilities (low cost). A slightly-too-special interface requires a rewrite when the second use case arrives (high cost).
But "slightly more general" means one step, not three. Generality should come from simplifying the interface, not from adding parameters.
if branches that could be eliminated?Red flag signals for generality are cataloged in red-flags (Special-General Mixture, Overexposure).