菜单
Structured production-incident investigation. Forces evidence-first hypothesis ranking before any code change. Use when given an error message, Sentry alert, failing log, or 'investigate <X>' request.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "is this over-engineered", or invokes /prune. Complements correctness-focused review; this one only hunts complexity.
Implement code incrementally with quality gates. Use when the user says 'build', 'implement', or when starting the implementation phase of an approved plan.
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Fetch and digest Sentry issue data (issue summary, tags, stack trace, breadcrumbs, latest event) by short ID, numeric issue ID, or sentry.io URL. Org-agnostic - works for any Sentry org the local token can access. Use when the user mentions a Sentry issue or short ID (e.g. MY-PROJECT-4X2), pastes a sentry.io issue URL, or asks to investigate/debug a Sentry error.
Create or update a diagram. Picks mermaid vs drawio per rules/diagrams.md, writes the source file, previews via MCP. Use when the user says 'diagram', '/diagram', or asks for a flowchart/architecture/sequence/state diagram.
Create or refresh technical engineering docs in the current repo's /docs/ tree. Diataxis layout, mermaid diagrams, ADR support, drift audit. Use when the user says 'write docs', 'document this', 'audit the docs', or '/document'.
| name | debug |
| description | Structured production-incident investigation. Forces evidence-first hypothesis ranking before any code change. Use when given an error message, Sentry alert, failing log, or 'investigate <X>' request. |
Investigate the issue: $ARGUMENTS
Hard rule: do NOT write any fix until Phase 3 is reached and the user (or the evidence in Phase 2) has confirmed the root cause.
why-not-mechanizable: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).
Gather, do not theorize. Save findings to .claude/state/research/YYYY-MM-DD-debug-<short-slug>.md.
PROJECT-ABC, numeric ID, or sentry.io URL), fetch the digest first via the sentry-issue skill: ~/.claude/skills/sentry-issue/scripts/sentry-issue.sh <id>. Full payloads land in /tmp/sentry-{issue,event}-<id>.json for deeper jq queries. (review-time: see section note)(review-time: see section note)(review-time: see section note)git log -p --since='2 weeks ago' -- <suspect-paths> to surface recent changes that touched the code path. (review-time: see section note)(review-time: see section note)(review-time: see section note)If the user already supplied a hypothesis, treat it as a candidate but still gather evidence to confirm or reject.
List 2-3 possible root causes ranked by evidence strength. For each:
(review-time: see section note)(review-time: see section note)(review-time: see section note)(review-time: see section note)Pick the top candidate. If two are tied or the user has a strong prior, ask the user to choose. Do not proceed to Phase 3 on a guess.
(review-time: see section note)(review-time: see section note)/verify-done (lint + typecheck + test + build). (review-time: see section note)(review-time: see section note)mr skill. PR body: link to the alert/log, root cause statement with evidence, and why this fix is correct. (review-time: see section note)(review-time: see section note)(review-time: see section note)(review-time: see section note)(review-time: see section note)(review-time: see section note)