菜单
Systematic root-cause debugging that enforces an "Iron Law" (no fix without a confirmed root cause) and walks investigation through five phases -- collect, pattern-match, hypothesize, fix, verify. Use when the user says debug this, fix this bug, why is this broken, root cause, or investigate.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audits and fully configures how a website looks when shared (Open Graph, Twitter/X cards, WhatsApp/Discord/Slack previews) and in the browser (title, favicons, theme-color, web manifest), generating missing assets and verifying the result locally. Use when setting up link previews, og:image, favicons, social sharing metadata, or when a shared link "looks wrong" on a platform.
Iterative React-health loop: inventory every React app in the repo, baseline with the latest react-doctor (pinned for the rest of the run), fix one root cause per iteration, and re-verify until every app scores 100/100 or every remaining finding has a user-approved written justification. Never silences findings with ignores, exclusions, or deleted behavior, and stops itself after two iterations without measurable progress. Use when the user mentions react-doctor, React health score, React anti-patterns cleanup, or driving a React codebase to a clean scan.
Iterative dependency-CVE remediation loop: scan with ecosystem-native advisory tooling, assess whether each high/critical finding is actually reachable (with call-path evidence, not vibes), fix the highest-risk reachable one with the smallest credible change, re-verify, and repeat. Terminates when no exploitable high/critical CVE remains or every remaining finding has an evidence-backed reachability assessment and an approved risk decision. Use when the user mentions CVEs, vulnerability scanning, dependency security, npm/pip/cargo audit, security patching, or wants a recurring dependency-security loop.
Orchestrates a comprehensive frontend UI review by running parallel analysis across typography, layout, accessibility, responsiveness, copy, visual polish, and design critique. Uses browser inspection for visual context. Produces a prioritized plan of small, concrete fixes -- never rewrites. Use when the user mentions UI review, frontend review, page review, design review, visual review, audit my page, or review my UI.
Review open PRs authored by the user for a given repo, showing title, status, review state, open comments, CI checks, and recommended next steps. Use when the user mentions PR review, my PRs, open PRs, PR status, PR dashboard, or wants an overview of their pull requests.
Surfaces the single most important blindspot in a plan, decision, or situation by checking whether the frame is right, generating candidates across 8 lenses (hidden constraints, false assumptions, second-order effects, stakeholders, blast radius, base rates, time horizon, counter-positions), then either committing to one or returning a calibrated "no blindspot" when none is load-bearing -- never a list of risks. Use when the user asks "what am I missing", "what's the most important thing I'm missing about this situation or decision", "what's my blindspot", "what's the biggest risk I'm not seeing", or wants a single sharp second opinion before committing.
| name | investigate |
| description | Systematic root-cause debugging that enforces an "Iron Law" (no fix without a confirmed root cause) and walks investigation through five phases -- collect, pattern-match, hypothesize, fix, verify. Use when the user says debug this, fix this bug, why is this broken, root cause, or investigate. |
Adapted from garrytan/gstack's /investigate skill. Restructured for this repo's
conventions and decoupled from gstack-specific telemetry. Original credit to Garry Tan and contributors.
Debug a bug methodically. Find the root cause before writing a fix. Never patch a symptom you don't understand.
No fix without a confirmed root cause. If you can't explain in one sentence why the bug happens, you are not allowed to edit code. Investigate more.
Before forming any hypothesis, gather:
git log --since="7 days ago" --oneline -- <suspect-area> and git blame on the failing line.Output of this phase: one or two written sentences describing what is happening and where.
Before designing a custom theory, check known bug shapes:
None snuck past a check)If the symptom matches a known pattern, your first hypothesis is that pattern. If nothing matches, search the codebase
for the error string and read prior fixes in git log --all --grep=<error-keyword>.
For each hypothesis, in order:
If confirmed, advance to Phase 4. If refuted, discard and try the next hypothesis. If you've hit 3 strikes, stop and report.
Once the root cause is confirmed:
### Root cause
One sentence.
### Evidence
What confirmed the hypothesis.
### Fix
File(s) touched and what changed.
### Regression test
Path and what it asserts.
### Concerns / open questions
Anything you couldn't verify (e.g. only reproduces in prod, depends on staging data).
End every investigation with one of: