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/onsi/ginkgo/debugging-failuresnpx skills add onsi/ginkgo --skill debugging-failuresgit clone --depth 1 https://github.com/onsi/ginkgoWhat 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.00122 | $0.01824 |
| Opus 5 | $0.00061 | $0.00912 |
| Sonnet 5 | $0.00024 | $0.00365 |
| Haiku 4.5 | $0.00012 | $0.00182 |
Grade A, and why
debugging-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 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging Ginkgo failures (especially as an agent)
Ginkgo's terminal output is good for a human; for programmatic diagnosis, prefer a hybrid: terminal for the verdict, JSON + jq for the details. This is empirically the most reliable, lowest-token workflow. Docs: https://onsi.github.io/ginkgo/#reporting-and-profiling-suites.
The workflow: one run, JSON-first diagnosis
# One invocation gives you BOTH the human verdict on the terminal AND a structured report.
# --json-report does NOT suppress console output, so you don't pay for two runs.
ginkgo -r -p --no-color --json-report=report.json --output-dir=.ginkgo-report
- Read the terminal tail for the one-line verdict:
FAIL! -- 5 Passed | 6 Failed | 1 Pending | 1 Skipped. Cheap, immediate. - If there are failures, query the JSON with
jq(filters below) to get exactly the failing specs — stable, addressable, order-independent. - Clean up the report dir when done.
Why hybrid and not one or the other:
- Terminal-only is brittle to parse (free-form text) and, under
-p, interleaves failures in nondeterministic order. - JSON-only is wasteful if you dump it: the full
report.jsonis ~9× the tokens of the terminal output. Ajqfailures-only extraction is a fraction of either. The discipline is filter, don't dump.
Where the JSON lands (use --output-dir deliberately)
--json-report=report.jsonalone writesreport.jsonto the current directory — which scatters into package dirs under-rand risks getting committed.- Prefer
--output-dir=DIRto collect everything in one known place (auto-created). With-r, all suites merge into oneDIR/report.json— ideal: one file, one set ofjqfilters. - Use a gitignored or temp location: a repo-local
.ginkgo-report/(add it to.gitignore) or an absolute temp path (--output-dir=/tmp/ginkgo-report). Don't leavereport.jsonin the working tree. --keep-separate-reports(with-r) writes onePACKAGE_report.jsonper package instead of merging — only reach for it when you must attribute failures per package.
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 · 97 lines · 122 tokens per session scan A 22d20c055d43
debugging-failures is a skill published in the GitHub repository onsi/ginkgo (9,046 stars, last pushed 22d ago), licensed MIT. It adds 122 tokens to every session and 1,824 once invoked, about $0.0006 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
nunit-testing
Use when writing or modifying tests in NUnit's own test projects, or when making a behavioral change to production code that needs test coverage. Covers test structure, attribute choice, helper visibility, platform guards, and which test projects are real.
nunit-threading-and-async
Use when writing or modifying async code in NUnit — async test lifecycle (setup/teardown), TestExecutionContext, AsyncLocal, Task/ValueTask continuations, blocking vs non-blocking waits, or conditional Thread.Abort code. Covers the threading/async conventions the NUnit runtime depends on.
nunit-build-infra
Use when editing .csproj, .nuspec, Directory.Build.props, Directory.Build.targets, Directory.Packages.props, the Cake build (build.cake, build.ps1, build.sh), or GitHub Actions workflows. Covers central package management, MinVer-driven versioning, the props-vs-targets split, and nuspec/csproj consistency.
nunit-code-style
Use when writing or modifying C# method bodies, type declarations, or non-trivial logic in NUnit source. Covers NUnit's taste-and-judgment conventions — exception construction, simplification, naming intent, StringComparison, non-null check form, and var usage — that aren't already caught at build time.
nunit-api-design
Use when adding or modifying public API surface in NUnit — new or changed constraints, attributes, assertions, helpers, or any type/member visibility change. Covers the conventions NUnit maintainers enforce for types that ship to consumers of the framework.
write-fixture
Write Java/Kotlin tests with Fixture Monkey — enumerate the cases a method can produce, pick the ones worth testing, and build each fixture pinning only the properties that force the expected outcome.