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/thixpin/pitway/debuggingnpx skills add thixpin/pitway --skill debugginggit clone --depth 1 https://github.com/thixpin/pitwayWhat 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 | $0.00086 | $0.01014 |
| Opus 5 | $0.00043 | $0.00507 |
| Sonnet 5 | $0.00017 | $0.00203 |
| Haiku 4.5 | $0.00009 | $0.00101 |
Grade A, and why
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 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.
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 — 53 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging
Locate the cause by narrowing the search space, not by guessing at fixes. A hypothesis you cannot disprove is not a diagnosis.
Scope
Use for investigation where the cause is unknown: irreproducible or intermittent failures, unexplained stack traces, environment-dependent behavior, regressions with no known trigger, any symptom you would otherwise "try a fix" against.
Do not use for:
- A defect you can already reproduce and explain —
bug-fixowns everything from the named cause onward. Hand off as soon as this skill names it. - Flaky test infrastructure over sound production code — isolation, execution order, shared fixtures, and nondeterministic assertions belong to
testing. - Code with no failure report — use
code-quality-review.
On flaky behavior, the line is which code is unreliable. Production code misbehaving intermittently is a mystery — debug it here. A test failing at random over sound code is a test-design problem — testing owns it. If you cannot yet determine whether the production code or the test is at fault, start here.
Method
- Pin the observable. Verbatim error, actual versus expected, failing input, environment — written down before theorizing. "It's broken" is not an observable.
- Find the last known-good state. A commit, release, config, machine. The delta between known-good and known-bad is the search space.
- Make it reproducible before explaining it. A reliable trigger is far easier to investigate, so build one first — a loop, fixed seed, captured payload, restored dataset. If it stays intermittent, treat reproduction rate as a number to raise (1 in 100 → 1 in 3), not a yes/no gate.
- Shrink the case. Cut to the minimum that still fails. Every element removed while the failure survives is a ruled-out suspect.
- Bisect, don't browse. Halve each step —
git bisectover history, layer by layer through the stack, or by disabling half the config or data. Prefer halving the search space over reading code sequentially or relying on intuition. - One falsifiable hypothesis at a time. State the suspected cause and the observation that would disprove it, then go get that observation. Two changes at once make the result uninterpretable.
- Observe, do not infer. Full stack trace, actual values, real request and response, timestamps — via debugger, logs, or temporary instrumentation. Assuming what the code "does" is why bugs survive an hour of reading.
- Trust the evidence over the story. When a measurement contradicts your model, update the model. Re-check you are running the code you think you are: right branch, rebuilt binary, cleared cache, no stale container, the environment you are actually hitting.
- State the cause in one sentence, with its evidence. A cause you cannot state plainly has not been found. Then hand off to
bug-fix: confirmed cause, supporting evidence, reproduction steps, affected components.
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 · 53 lines · 86 tokens per session scan A 894b757d7bb7
debugging is a skill published in the GitHub repository thixpin/pitway (19 stars, last pushed 3d ago), licensed MIT. It adds 86 tokens to every session and 1,014 once invoked, about $0.0004 per session on Opus 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-30.
Other skills, from other repositories
concord-relay
Keep this Grok session reachable by other Concord agents while idle.
pace-workflow
Use for PACEflow-managed coding work: create, approve, resume, verify, close, or archive CHG/HOTFIX before project file edits.
artifact-management
Use for PACEflow artifact fields and formats: task indexes, CHG/HOTFIX lifecycle operations, artifact-writer prompts, approvals, verification, and archive.
work-loop
Use when implementing or resuming a non-trivial repository change: a feature, behavior-changing fix, refactor, migration, framework or dependency upgrade, schema or API change, performance work, infrastructure or build-system change, reversion, or an existing build spec under docs/specs/. Also use for bare…
audit
Use for PACEflow internal full audit: run five independent review agents, verify evidence from code/tests/logs, de-duplicate findings, and produce a severity-ranked report for release gates or comprehensive code review.
pace-bridge
Use to bridge a confirmed Superpowers/native plan into PACEflow CHG/HOTFIX artifacts, create artifact-writer prompts, and mark the specific plan as synced.