菜单
Routes a vague symptom or complaint to the most relevant Clairvoyance skill via a decision tree. Use when someone describes a problem but doesn't know which skill to reach for. Not for a comprehensive review (use design-review) or a checklist scan (use red-flags).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | diagnose |
| description | Routes a vague symptom or complaint to the most relevant Clairvoyance skill via a decision tree. Use when someone describes a problem but doesn't know which skill to reach for. Not for a comprehensive review (use design-review) or a checklist scan (use red-flags). |
| argument-hint | [description of the symptom or problem] |
| allowed-tools | Read, Grep |
When invoked with $ARGUMENTS, match the described symptom against the decision tree below and route to the appropriate skill. If code paths are referenced, read them first to confirm the match before routing. This skill routes to other skills from Clairvoyance (https://clairvoyance.fyi). It works best when the full collection is installed.
The symptom is a general sense of unease with no concrete complaint.
→ complexity-recognition: Apply the three-symptom framework to locate the source.
Change amplification. Branch by cause:
The interface exposes too much or forces callers to assemble details they shouldn't need.
Naming difficulty signals a design problem, not a vocabulary problem.
→ naming-obviousness: If the name can't be made obvious, the entity's responsibility is likely unclear. → Then design-it-twice: Consider alternative decompositions that yield nameable pieces.
Exception surfaces are large, catch blocks are boilerplate or error paths obscure the normal path.
→ error-design: Apply define-errors-out and exception aggregation.
Pass-through methods, thin adapter classes or layers that exist only for "architecture."
→ abstraction-quality: Evaluate whether each layer provides a meaningful abstraction or just adds indirection.
Comments restate code, are absent where needed or have drifted from the implementation.
→ comments-docs: Apply the four-category framework and contamination checks.
Technical debt from tactical shortcuts. The concern is process, not a specific structural flaw.
→ strategic-mindset: Assess the tactical-vs-strategic balance. → Then code-evolution: Plan incremental improvement alongside current work.
When the description maps to more than one root symptom, prioritize in this order:
Route to the highest-priority match first. Mention the secondary matches so the user can follow up.
If the described symptom does not match any branch above, fall back to red-flags: a systematic scan will surface concrete signals to diagnose from.
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).
