菜单
Diagnose failures by root cause, not symptom. Use for crashes, stack traces, intermittent bugs, memory growth, race conditions, and "works locally, fails in prod" cases where you need a reproducible cause before a fix. Runs isolated and read-only, reports the root cause and fix.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Accessibility and screen-reader support, built in from the start rather than bolted on. Claude treats a11y as an afterthought and reaches for clickable divs, skips alt text and labels, and removes focus rings. Use when building or editing any UI, page, or interactive component. Covers semantic HTML before ARIA, real buttons and links, accessible names, keyboard operability and focus management, headings and landmarks, contrast and motion, and how to actually test it. Most of it is free if you use the right element.
Service structure conventions for this codebase: routing, layering, and where code lives. Use whenever writing or modifying a service's server entry, route definitions, handlers, or adapters. Loads inline so it shapes structure as code is written.
Review changed code for correctness, security, and maintainability with cited, severity-ranked findings. Use when asked to review a diff, a PR, a commit, or named files, to audit code, or to check before merge. Runs isolated and read-only, reports findings, does not edit.
Scaffold a new microservice that follows the project's server/handlers/adapters architecture. Use when asked to create, scaffold, or add a new service or package. Writes files and may create a git branch, so it runs only when invoked explicitly.
Where CSS should live. Claude defaults to dumping a giant <style> block or scattering style="..." attributes instead of putting styles in a .css file and linking it. Use when building or editing a web page or component, or whenever about to write a style attribute or an embedded style block. Covers defaulting to an external stylesheet, why inline style attributes are a trap, and the few cases where inline is actually correct (dynamic values via custom properties, critical CSS, single-file artifacts, email).
Common pitfalls that are slow to troubleshoot and that tend to get "fixed" by going in circles, because the error message points nowhere near the actual cause. Use before and during git, project, and WSL work, checking a repo is initialized and node_modules is ignored, putting WSL projects on the right filesystem, opening a browser from WSL for auth, normalizing line endings, and matching import case. Check the layer here first instead of debugging the wrong one.
| name | debugger |
| description | Diagnose failures by root cause, not symptom. Use for crashes, stack traces, intermittent bugs, memory growth, race conditions, and "works locally, fails in prod" cases where you need a reproducible cause before a fix. Runs isolated and read-only, reports the root cause and fix. |
| when_to_use | - User reports a crash, exception, stack trace, or failing behavior and wants the cause - A bug is intermittent, environment-specific, or not reproducing locally - Memory or resource growth needs tracing to a source |
| context | fork |
| allowed-tools | Read, Grep, Bash |
You find root causes. You do not patch symptoms, and you do not guess.
Work these in order. Do not skip ahead.
For anything live, do these three before opening a source file. Most incidents resolve here.
git log --since, deploy history, flag state. A correlated change usually is the answer.grep, jq, awk.