ワンクリックでManusで任意のスキルを実行

systematic-debugging

スター37

フォーク5

更新日2026年6月24日 08:10

Find the root cause before changing code. Use when encountering any bug, test failure, crash, flaky test, performance regression, or unexpected behavior, before proposing or applying a fix.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

clubpay

clubpay/ronykit

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Systematic Debugging

Guessing creates new bugs and hides old ones. Find the root cause first.

The iron rule

No fix without a root-cause hypothesis you have confirmed with evidence.

If you cannot explain why the bug happens, you are not ready to fix it.

When to use

Any test failure, crash, wrong output, flaky test, performance regression, build failure, or integration issue — especially when under time pressure or when a previous fix didn't hold.

Phase 1 — Understand

Read the full error and stack trace; note file, line, and exact message.
Reproduce it reliably. A bug you can't reproduce, you can't verify fixed.
Establish the smallest reproduction and the expected vs actual behavior.

Phase 2 — Investigate

Form a hypothesis about the cause and predict what you'd observe if true.
Gather evidence: targeted logging, a debugger, git bisect, binary search by commenting/disabling, or diffing a working vs broken state.
Follow the data flow backward from the symptom to its origin. Question assumptions ("this can't be nil" — prove it).

Phase 3 — Fix the cause

Change the root cause, not the symptom. Patching where it crashed instead of where the bad value originated just moves the bug.
Make the smallest change that addresses the cause.

Phase 4 — Verify & prevent

Write a test that fails before the fix and passes after.
Re-run the full relevant suite to check for regressions.
Ask whether the same class of bug exists elsewhere.

Tactics

git bisect to locate the introducing commit.
Binary search the input/code path to isolate the trigger.
Add structured logging at decision points; remove it before committing.
For flakiness: suspect time, ordering, concurrency, and shared state; run with -race / repeated runs.

Anti-patterns

Trying random changes to see what sticks.
Adding defensive if x == nil guards without knowing why x is nil.
Declaring it fixed because the symptom disappeared once.

このリポジトリの他の Skills

同じリポジトリ

react-performance

clubpay/ronykit

Optimize React/Next.js runtime performance — eliminate waterfalls, shrink bundles, cut unnecessary re-renders, and speed up rendering. Use when writing, reviewing, or refactoring components for speed, or chasing slow renders, large bundles, janky interactions, or high TTFB/LCP/INP.

2026-07-0437

webmcp

clubpay/ronykit

Build agent-friendly web apps with the W3C Web Model Context API (WebMCP). Use when exposing frontend features as structured tools for in-browser AI agents, adding document.modelContext tools to React/Next.js apps, designing tool schemas for dashboards or admin UIs, or making existing UI automatable without DOM scraping.

2026-07-0437

go-testing

clubpay/ronykit

Write clear, fast, deterministic Go tests including mandatory repo integration tests (x/testkit) and app unit tests. Use when adding or fixing Go tests, implementing internal/repo or internal/app, designing table-driven tests, writing benchmarks, using testify, or improving coverage in this workspace.

2026-06-2537

frontend-design

clubpay/ronykit

Design distinctive, production-grade frontend interfaces that don't read as templated AI defaults. Use when bootstrapping a frontend app, building or restyling a landing page, marketing site, hero, brand-forward product surface, or any UI where visual identity matters — choosing palette, typography, layout, motion, and copy. Required before running create-next-app or writing UI.

2026-06-2537

code-review

clubpay/ronykit

Review code (your own or others') for correctness, design, and risk before it merges. Use when reviewing a diff or pull request, doing a self-review before opening a PR, or giving structured, prioritized feedback.

2026-06-2437

design-tokens

clubpay/ronykit

Architect a scalable, themeable design-token system — primitive → semantic → component layers, CSS variables, a 4px spacing/type scale, and dark mode. Use when setting up or refactoring a project's tokens, naming color/spacing/radius values, wiring tokens into Tailwind/shadcn, enabling theme switching, or killing hard-coded hex/px scattered through components.

2026-06-2437

Systematic Debugging

Guessing creates new bugs and hides old ones. Find the root cause first.

The iron rule

No fix without a root-cause hypothesis you have confirmed with evidence.

If you cannot explain why the bug happens, you are not ready to fix it.

When to use

Any test failure, crash, wrong output, flaky test, performance regression, build failure, or integration issue — especially when under time pressure or when a previous fix didn't hold.

Phase 1 — Understand

Read the full error and stack trace; note file, line, and exact message.

Reproduce it reliably. A bug you can't reproduce, you can't verify fixed.

Establish the smallest reproduction and the expected vs actual behavior.

Phase 2 — Investigate

Form a hypothesis about the cause and predict what you'd observe if true.

Gather evidence: targeted logging, a debugger, git bisect, binary search by commenting/disabling, or diffing a working vs broken state.

Follow the data flow backward from the symptom to its origin. Question assumptions ("this can't be nil" — prove it).

Phase 3 — Fix the cause

Change the root cause, not the symptom. Patching where it crashed instead of where the bad value originated just moves the bug.

Make the smallest change that addresses the cause.

Phase 4 — Verify & prevent

Write a test that fails before the fix and passes after.

Re-run the full relevant suite to check for regressions.

Ask whether the same class of bug exists elsewhere.

Tactics

git bisect to locate the introducing commit.

Binary search the input/code path to isolate the trigger.

Add structured logging at decision points; remove it before committing.

For flakiness: suspect time, ordering, concurrency, and shared state; run with -race / repeated runs.

Anti-patterns

Trying random changes to see what sticks.

Adding defensive if x == nil guards without knowing why x is nil.

Declaring it fixed because the symptom disappeared once.

name	systematic-debugging
description	Find the root cause before changing code. Use when encountering any bug, test failure, crash, flaky test, performance regression, or unexpected behavior, before proposing or applying a fix.