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/cinpx skills add onsi/ginkgo --skill cigit 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.00132 | $0.01390 |
| Opus 5 | $0.00066 | $0.00695 |
| Sonnet 5 | $0.00026 | $0.00278 |
| Haiku 4.5 | $0.00013 | $0.00139 |
Grade A, and why
ci 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ginkgo in CI
A CI invocation should maximize signal — surface flakes and spec pollution, catch mistakes that pass locally, and emit machine-readable artifacts — while collecting every failure in one run. This builds on the CLI (ginkgo:running) and report formats (ginkgo:reporting). Full rationale: https://onsi.github.io/ginkgo/#recommended-continuous-integration-configuration.
The recommended flag set
Invoke via go run so the CLI version always tracks the github.com/onsi/ginkgo/v2 in your go.mod — no separately-installed binary to drift (→ ginkgo:setup).
go run github.com/onsi/ginkgo/v2/ginkgo \
-r -p --randomize-all --randomize-suites \
--fail-on-pending --fail-on-empty --keep-going \
--cover --coverprofile=cover.profile --race --trace \
--json-report=report.json --output-dir=.ginkgo-report \
--timeout=TIMEOUT --poll-progress-after=Xs --poll-progress-interval=Ys
| Flag | Why |
|---|---|
-r |
recursively find and run every suite |
-p |
run each suite in parallel (→ ginkgo:parallelism; set --procs=N/--compilers=N if CPU detection is wrong) |
--randomize-all / --randomize-suites |
shuffle all specs and the suite order to surface spec pollution (→ ginkgo:running) |
--fail-on-pending |
fail if any Pending specs were committed |
--fail-on-empty |
fail if no specs ran (usually a malformed filter) |
--keep-going |
don't stop at the first failed suite — collect all failures |
--cover --coverprofile=cover.profile |
compute coverage into one merged profile (→ ginkgo:reporting) |
--race |
run with the race detector |
--trace |
full stack traces on failure (worth it without a local feedback loop) |
--json-report=report.json |
structured results for diagnosis and downstream tools (→ ginkgo:debugging-failures) |
--timeout=TIMEOUT |
cap the whole run (default 1h — often not enough) |
--poll-progress-after/--poll-progress-interval |
emit progress reports for stuck specs (→ ginkgo:timeouts-and-async) |
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 · 71 lines · 132 tokens per session scan A 01db01e326ad
ci is a skill published in the GitHub repository onsi/ginkgo (9,046 stars, last pushed 23d ago), licensed MIT. It adds 132 tokens to every session and 1,390 once invoked, about $0.0007 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-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.
ci-cd
CI/CD pipelines for GitHub Actions and Docker-based deployments — lint, test, build, push, deploy stages; environment secrets; branch-gated workflows; health-check rollbacks; and PM2/systemd service restarts.
multi-agent-release-manager
Cleans up the workspace, formats code, runs presubmit checks, and uploads CLs to Gerrit.
dsh-web-pre-push-checks
Use before pushing, opening or updating a pull request, or claiming dsh-web checks pass. Selects the required repository gates and diff-specific generation, build, and GUI evidence.
babysit
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitorstart / monitorupdate / autonudgestop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use…
azsdk-common-pipeline-analysis
Analyze Azure SDK CI/CD pipeline failures into a structured diagnosis, and define the required output format. Load this skill before calling azsdkanalyzepipeline, which returns raw failure data that this skill interprets and formats. USE FOR: "pipeline failed", "build failure", "CI check failing", "tests failing in…