Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add s977043/PlanGate --skill systematic-debugginggit clone --depth 1 https://github.com/s977043/PlanGateWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/s977043/plangate/systematic-debugging)<a href="https://agentmods.dev/skills/s977043/plangate/systematic-debugging"><img src="https://agentmods.dev/badge/skills/s977043/plangate/systematic-debugging/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/s977043/plangate/systematic-debugging"><img src="https://agentmods.dev/badge/skills/s977043/plangate/systematic-debugging.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00100 | $0.01497 |
| Opus 5.5 | $0.00040 | $0.00599 |
| Sonnet 5.5 | $0.00020 | $0.00299 |
| Haiku 4.5 | $0.00010 | $0.00150 |
Grade A, and why
systematic-debugging scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 129 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systematic Debugging
推測ではなくエビデンスに基づいて根本原因を特定する体系的デバッグプロセス。
Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
原因を特定せずに修正を試みることを禁止する。3回修正に失敗したらアーキテクチャの問題として人間にエスカレーションする。
Common Rationalizations
| こう思ったら | 現実 |
|---|---|
| 「原因は多分これだから先に直す」 | 推測で修正するな。まず再現・証拠を取れ |
| 「3回直しても失敗したがもう1回試す」 | 3回失敗はアーキテクチャの問題。人間にエスカレーション |
| 「ログを見れば分かる」 | ログは症状。根本原因は別のレイヤーにある可能性を疑え |
核心原則: 仮説を立てる前に事実を集める。修正する前に原因を理解する。
5ステップ プロセス
Step 1: 症状の正確な記録
まず事実を集める。推測しない。
記録する項目:
□ 何が起きているか（エラーメッセージ、スタックトレース）
□ 何が期待されていたか
□ いつから発生しているか（直近の変更との関連）
□ 再現条件（常に再現？特定条件？間欠的？）
□ 影響範囲（1ファイル？複数？全体？）
調査コマンド例:
# 直近の変更を確認
git log --oneline -10
git diff HEAD~5
# テスト失敗の詳細
# プロジェクト固有のテストコマンドを使用
Step 2: 仮説の列挙（まだ検証しない）
症状から考えられる原因を列挙する。この時点では検証しない。
| # | 仮説 | 確信度 | 検証コスト |
|---|------|--------|----------|
| 1 | {仮説A} | 高/中/低 | 小/中/大 |
| 2 | {仮説B} | 高/中/低 | 小/中/大 |
| 3 | {仮説C} | 高/中/低 | 小/中/大 |
優先順位: 確信度が高く検証コストが低い仮説から検証する。
Step 3: 仮説の検証（1つずつ）
各仮説を1つずつ検証する。複数同時に検証しない。
検証の記録:
□ 検証した仮説: {仮説名}
□ 検証方法: {何をしたか}
□ 結果: 支持 / 棄却 / 不確定
□ 根拠: {具体的なエビデンス}
検証テクニック:
- 二分探索: 問題を半分に分けて切り分ける
- 最小再現: 問題を再現する最小のコードを作る
- 差分分析: 動く状態と動かない状態の差分を特定する
- ログ挿入: 一時的なログでデータフローを追跡する
- git bisect: いつから壊れたかを特定する
Step 4: 根本原因の特定と修正
根本原因が判明したら:
- 原因を文書化: なぜこのバグが発生したかを記録
- 修正案を提示: 複数のアプローチがあれば比較
- 修正の影響範囲を評価: この修正で他が壊れないか
- テストを先に書く: 修正前にバグを再現するテストを作成（Red）
- 修正を実装: テストが通ることを確認（Green）
Step 5: 再発防止
修正だけでなく、同種のバグの再発を防ぐ:
□ テストが追加されたか（同じバグが再発したら検出できるか）
□ 根本原因は構造的か（他の箇所にも同じ問題が潜んでいないか）
□ ドキュメントの更新が必要か
デバッグのアンチパターン
- 推測で修正: 原因を特定せずに「これかも」で修正する
- 複数同時変更: 一度に複数の修正を入れて何が効いたか分からなくなる
- ログの消し忘れ: デバッグ用ログを本番に残す
- 症状の修正: 根本原因ではなく表面的な症状だけを修正する
- テストなし修正: 修正後のテストを書かずにクローズする
重要ルール
- 推測で修正しない: エビデンスに基づいて原因を特定してから修正する
- 1つずつ検証: 複数の仮説を同時に検証しない
- 修正前にテスト: バグを再現するテストを先に書く
- 記録を残す: 調査過程を
status.mdに記録する
関連スキル
- find-bugs: コードレビュー観点でのバグ発見に使用
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 129 lines · 100 tokens per session scan A d509e4eb55af
systematic-debugging is a skill published in the GitHub repository s977043/PlanGate (2 stars, last pushed yesterday), licensed MIT. It adds 100 tokens to every session and 1,497 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
postmortem
Auto-generates a structured postmortem from a completed campaign. Reads the campaign file, telemetry logs, and feature ledger. Produces a documented analysis of what broke, what the safety systems caught, and what patterns emerged. Can also be invoked manually for any incident.
systematic-debugging
4-phase root cause analysis: observe, hypothesize, verify, fix. Enforces investigation before any code changes. Emergency stop after 2 failed fixes. Prevents shotgun debugging and fix cascades.
04-audit
Audit a codebase read-only across seven quality pillars into one ranked report. Use when the user wants to assess, health-check, or audit a codebase or one pillar. Not for fixing findings, reviewing a change, or checking a feature works.
07-refactor
Improve code across four axes (cleanup, performance, security, architecture) by scanning and fixing, or applying a pushed audit report. Use when the user wants to refactor, optimize, harden, or remove code. Not for read-only diagnosis or adding tests.
03-assert
Assert the work behaves by iterating the project's coding assertions until they pass, plus optional architecture and frontend facets. Use to validate an implementation. Not for reviewing or writing tests.
08-debug
Reproduce and fix a known bug, or find an unknown root cause by hypothesis validation. Use when the user wants to fix a bug, find why something breaks, or reopen a stuck investigation. Not for building a feature or reviewing a diff.