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/reportingnpx skills add onsi/ginkgo --skill reportinggit 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.00124 | $0.01631 |
| Opus 5 | $0.00062 | $0.00816 |
| Sonnet 5 | $0.00025 | $0.00326 |
| Haiku 4.5 | $0.00012 | $0.00163 |
Grade A, and why
reporting 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 3d 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.
Reporting and profiling
How to produce reports and feed data into them. To read a failing report as an agent (the jq failure-diagnosis workflow), see ginkgo:debugging-failures. Docs: https://onsi.github.io/ginkgo/#generating-machine-readable-reports and https://onsi.github.io/ginkgo/#attaching-data-to-reports.
Console output
| Flag | Effect |
|---|---|
--succinct |
Minimal (default when running multiple suites). |
| (none) | Normal — detail only for failed specs (default, single suite). |
-v |
Full timeline for every spec; streams live in series. |
-vv |
-v plus node > Enter/< Exit events and every failure (not just the primary). |
--trace |
Full stack trace on every failure, not just panics. |
--no-color / GINKGO_NO_COLOR=TRUE |
Disable color. |
--github-output |
Format console output for GitHub Actions. |
In parallel (-p), -v/-vv timelines can't stream — the streams would interleave, so Ginkgo emits each spec's full timeline after that spec completes. → CI flags in ginkgo:ci.
Machine-readable reports
ginkgo -r --json-report=report.json --output-dir=./.reports
--json-reportis native and richest — an array oftypes.Report, each withSpecReports[]oftypes.SpecReport(godoc); build tooling against thetypespackage.--junit-report=x.xml,--teamcity-report=x,--gojson-report=x.go.jsonexist for external CI but lose Ginkgo metadata — use them to feed a system, not to diagnose. (JUnit maps aLabel("owner:XYZ")to theOwnerattribute.)--output-dir=DIRcollects all files in one place; under-rall suites merge into one report file.--keep-separate-reportswrites onePACKAGE_report.jsonper package instead.- Every machine-readable report embeds the full
-vvtimeline regardless of console verbosity. Run the suite quiet and mine the file — you don't need-vvon the console to get rich detail in the report.
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.
- 3d ago First seen · 97 lines · 124 tokens per session scan A 30b2bfb37251
reporting is a skill published in the GitHub repository onsi/ginkgo (9,046 stars, last pushed 23d ago), licensed MIT. It adds 124 tokens to every session and 1,631 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.