メニュー
Four-phase debugging methodology with root cause analysis. Use when investigating bugs, fixing test failures, or troubleshooting unexpected behavior. Emphasizes NO FIXES WITHOUT ROOT CAUSE FIRST.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Generate professional Chinese software development contracts (软件开发合同). Use when creating, modifying, or reviewing software development contracts for freelance/agency work. Covers IP, milestones, payment, maintenance, liability, and third-party service cost evaluation.
Summarize English speaking lesson from recording/transcript. Extract vocabulary, categorize topics, highlight common phrases and pronunciation issues, generate practice exercises. Use when processing English lesson recordings, transcripts, or creating lesson summaries.
Supabase Auth, Database, and SSR patterns. Use when working with Supabase client setup, authentication, Row Level Security, database queries, storage, realtime, or @supabase/ssr middleware.
System design interview note creation from Hello Interview or similar sources. Use when studying system design, creating system design notes, or summarizing system design problem breakdowns. Covers requirements, entities, API, architecture, and deep dives.
Jest testing patterns, factory functions, mocking strategies, and TDD workflow. Use when writing unit tests, creating test factories, or following TDD red-green-refactor cycle.
| name | systematic-debugging |
| description | Four-phase debugging methodology with root cause analysis. Use when investigating bugs, fixing test failures, or troubleshooting unexpected behavior. Emphasizes NO FIXES WITHOUT ROOT CAUSE FIRST. |
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
Never apply symptom-focused patches that mask underlying problems. Understand WHY something fails before attempting to fix it.
Before touching any code:
Root Cause Tracing Technique:
1. Observe the symptom - Where does the error manifest?
2. Find immediate cause - Which code directly produces the error?
3. Ask "What called this?" - Map the call chain upward
4. Keep tracing up - Follow invalid data backward through the stack
5. Find original trigger - Where did the problem actually start?
Key principle: Never fix problems solely where errors appear—always trace to the original trigger.
Apply the scientific method:
Critical rule: If THREE or more fixes fail consecutively, STOP. This signals architectural problems requiring discussion, not more patches.
Stop immediately if you catch yourself thinking:
Consecutive fixes revealing new problems in different areas indicates architectural issues:
1. Read the FULL error message and stack trace
2. Identify which assertion failed and why
3. Check test setup - is the test environment correct?
4. Check test data - are mocks/fixtures correct?
5. Trace to the source of unexpected value
1. Capture the full stack trace
2. Identify the line that throws
3. Check what values are undefined/null
4. Trace backward to find where bad value originated
5. Add validation at the source
1. Use git bisect to find the breaking commit
2. Compare the change with previous working version
3. Identify what assumption changed
4. Fix at the source of the assumption violation
1. Look for race conditions
2. Check for shared mutable state
3. Examine async operation ordering
4. Look for timing dependencies
5. Add deterministic waits or proper synchronization
Before claiming a bug is fixed:
Systematic debugging achieves ~95% first-time fix rate vs ~40% with ad-hoc approaches.
Signs you're doing it right: