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 dork-labs/dorkos --skill debugging-test-failuresgit clone --depth 1 https://github.com/dork-labs/dorkosWrote 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/dork-labs/dorkos/debugging-test-failures)<a href="https://agentmods.dev/skills/dork-labs/dorkos/debugging-test-failures"><img src="https://agentmods.dev/badge/skills/dork-labs/dorkos/debugging-test-failures/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/dork-labs/dorkos/debugging-test-failures"><img src="https://agentmods.dev/badge/skills/dork-labs/dorkos/debugging-test-failures.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.00038 | $0.00719 |
| Opus 5.5 | $0.00015 | $0.00288 |
| Sonnet 5.5 | $0.00008 | $0.00144 |
| Haiku 4.5 | $0.00004 | $0.00072 |
Grade A, and why
debugging-test-failures 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging Test Failures
Overview
This is the shared-skill replacement for the legacy Claude Code /debug:test workflow.
Use it when tests are failing and the goal is to identify the real root cause instead of making blind changes.
Read First
Before acting, read:
.agents/skills/debugging-systematically/SKILL.md.claude/skills/test-driven-development/SKILL.mdwhen the failing test is tied to new feature work or a bugfix
Core Workflow
- Run the relevant test scope
- one file or one pattern when possible
- whole-suite only when needed
- Parse the failure output
- failing test names
- expected vs actual behavior
- error messages and stack traces
- Check load-sensitivity before diving in
- passes in isolation but fails in the full run
- the assertion is about timing, throughput, or sample counts rather than behavior
- the failure text names milliseconds, wall-clock boundaries, or "expected N samples"
- the file is in a known flake family: harness atomic-write AP-10
(sample-throughput guard, MIN_SAMPLES fixed at 200), RoomLiveLane
(wall-clock boundaries), agent-activity (teardown timing),
palette-scope-chips (DOR-1502), and the browser spec
apps/e2e/tests/settings/runtimes-tab.spec.ts"Make default moves the default, and it survives a reload" (DOR-2043:page.waitForResponse/locator.click90s timeouts on merge-queue shard 2, three times on 2026-09-14 on diffs that cannot reach it) - a load-starved guard refusing to conclude is not a defect in your branch — re-run once before spending a cycle, and if it repeats, it belongs to the test's owner, not yours
- Read the failing test first
- understand arrange / act / assert
- explain what the test is trying to prove
- Read the implementation under test
- trace inputs, transformations, and outputs
- Decide where the bug lives
- implementation
- test logic
- mock/setup
- broader shared root cause
- Apply a minimal fix
- fix the real problem, not just the symptom
- Re-run verification
- the failing test
- nearby tests when relevant
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 Changed · +4 lines e423bdf9c9cc
- 1mo ago Changed · +13 lines 9aef44696f54
- 1mo ago First seen · 59 lines · 38 tokens per session scan A 5a1598963fb6
debugging-test-failures is a skill published in the GitHub repository dork-labs/dorkos (12 stars, last pushed yesterday), licensed MIT. It adds 38 tokens to every session and 719 once invoked, about $0.0002 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
fix-bug
Use when a ticket reports defective behaviour — a wrong result, a crash, a regression, "X doesn't work when Y" — and the fix must be proven with a test that fails before and passes after. Invoke for any bug, incident follow-up, or "this used to work" ticket before touching the code.
ralphctl-debugging-and-error-recovery
Systematic root-cause debugging. Use when tests fail, builds break, something that worked before broke, or behaviour does not match expectations — when you need to figure out what broke and why. Follow stop-the-line → reproduce → localize → reduce → root-cause → guard-with-regression-test → verify, not guessing; the…
fix-feature-bug
Fix bugs using structured workflow with error classification and regression tests. Use when user reports bugs, errors, broken features, test failures, or mentions "fix", "broken", "not working", "failing". Can be invoked via /fix-feature-bug.
test-master
Use when writing tests, creating test strategies, or building automation frameworks. Invoke for unit tests, integration tests, E2E, coverage analysis, performance testing, security testing.
java-conventions
Use when a ticket adds or changes Java code and it must follow the repo's Java conventions — Effective Java, modern Java (records, sealed types, pattern matching, switch expressions), Optional discipline, immutability, try-with-resources, thread safety and virtual threads, Spring Boot constructor injection, and JUnit…
python-conventions
Use when a ticket adds or changes Python code and it must follow the repo's Python conventions — PEP 8, full type hints (PEP 484) checked by mypy/pyright, dataclasses, pythonic idioms, explicit error handling, asyncio and thread safety, ruff-clean, and pytest with coverage via the repo's env manager (uv/poetry).…