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 agentmods add skills/perniemann/pncore/pn-systematic-debuggingnpx skills add perniemann/pnCore --skill pn-systematic-debugginggit clone --depth 1 https://github.com/perniemann/pnCoreWrote 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/perniemann/pncore/pn-systematic-debugging)<a href="https://agentmods.dev/skills/perniemann/pncore/pn-systematic-debugging"><img src="https://agentmods.dev/badge/skills/perniemann/pncore/pn-systematic-debugging.svg" alt="Measured on agentmods" 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.00063 | $0.01303 |
| Opus 5 | $0.00032 | $0.00651 |
| Sonnet 5 | $0.00013 | $0.00261 |
| Haiku 4.5 | $0.00006 | $0.00130 |
Grade A, and why
pn-systematic-debugging scanned grade A with 1 finding 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 2d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
2. **Scripted HTTP** (`curl` / small script) against a dev server for API regressions. How it starts
The opening of the file, as written. The whole thing — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systematic debugging
When to use
- A test, build, or runtime failure with unclear cause
- User reports "this is broken" or "why does this fail?"
- Intermittent or hard-to-reproduce bugs
Triage mode (default when bug is reported)
When the user reports a bug or failure, enter triage mode:
- One question maximum. Ask ONE question at most to clarify the problem, then immediately investigate the codebase. Do not ask follow-up questions — explore first.
- Investigate deeply before asking anything else:
- Trace the relevant code path using Octocode
lspCallHierarchy,lspGotoDefinition, andlspFindReferenceswhen available. - Look at related source files, existing tests, and recent changes (
git logon relevant files). - Find where the bug manifests, what code path is involved, and why it fails (root cause, not symptom).
- Trace the relevant code path using Octocode
- Identify the fix approach based on investigation: minimal change, modules affected, behaviors to verify.
- Output structured root cause analysis — see Output section below.
Phase 0 — Feedback loop (before hypotheses)
Spend disproportionate effort here. Without a fast pass/fail signal, bisection and hypothesis testing cannot land.
Construct one deterministic feedback loop before Phase 1 (Reproduce), trying roughly this order until one works:
- Failing automated test at the seam that reaches the bug (unit or integration).
- Scripted HTTP (
curl/ small script) against a dev server for API regressions. - CLI invocation with fixture input; diff stdout/stderr against a snapshot.
- Replay artifact — captured request, payload, or event log replayed through the code path.
- Throwaway harness — minimal subset of the system exercising one path with one call.
- Property or fuzz loop when output is nondeterministic — narrow until failure mode appears.
git bisect runwhen regression window is bounded by known-good and known-bad commits.
Iterate on the loop until it is fast (seconds, not minutes) and sharp (asserts the symptom, not “did not crash”). For flaky bugs, raise reproduction rate before debugging logic.
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.
- 2d ago First seen · 98 lines · 63 tokens per session scan A 2437c5b387cf
pn-systematic-debugging is a skill published in the GitHub repository perniemann/pnCore (0 stars, last pushed 2d ago), licensed MIT. It adds 63 tokens to every session and 1,303 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
t-800-fix-pack
Структура fix-pack и constraints factory PATCH для /t800-fix. Use when правка существующего артефакта, fix-packs/ .md, audit→fixpack, или mode PATCH. Do NOT use when полный CREATE /t800-start, Loop report-only (/t800-loop), или doctor/plugin-audit без PATCH.
diagnose-hard-problem
Disciplined diagnosis loop for hard problems, diagnosing bugs and regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test.
cocoreview
CocoReview — structured code review with six-severity findings vocabulary, progressive disclosure architecture, and universal anti-pattern baseline. Invoked via $review [file] [--complexity] [--security] [--architecture] [--language ].
firebase-crashlytics
Use when implementing crash reporting, capturing fatal/non-fatal errors, recording isolate/async exceptions, customizing reports, or uploading obfuscated symbols.
flutter-errors
Use when hitting layout errors (RenderFlex overflow, unbounded constraints, RenderBox not laid out), scroll errors, or setState-during-build errors.
identify-key-failures
Synthesize the common stuck points across failed decomposition plans. Use when the current batch of decomposition plans has failed — whether they failed already at direct proving or only after further attempts.