القائمة
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)