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 commands/sergei-aronsen/claude-code-toolkit/diagnose-cigit clone --depth 1 https://github.com/sergei-aronsen/claude-code-toolkitWrote 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/commands/sergei-aronsen/claude-code-toolkit/diagnose-ci)<a href="https://agentmods.dev/commands/sergei-aronsen/claude-code-toolkit/diagnose-ci"><img src="https://agentmods.dev/badge/commands/sergei-aronsen/claude-code-toolkit/diagnose-ci.svg" alt="Measured on agentmods" 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.00064 | $0.02614 |
| Opus 5 | $0.00032 | $0.01307 |
| Sonnet 5 | $0.00013 | $0.00523 |
| Haiku 4.5 | $0.00006 | $0.00261 |
Grade A, and why
diagnose-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 6d 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 — 231 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/diagnose-ci — CI Failure Diagnosis Loop
Purpose
When a PR's CI is red, you need a structured way to find the root cause without losing time to noise (flaky tests, cache misses, infra blips). This command walks the 7 most common CI failure layers in order of increasing effort to fix, so you stop at the cheapest layer that explains the failure.
The loop is designed to be runnable by a single Claude Code session: each step is a concrete action with concrete output, no "investigate further" hand-waving.
Usage
/diagnose-ci [<run-id> | <pr-number>]
<run-id>— explicit GitHub Actions run ID. Use this when you already have the URL orgh run listoutput.<pr-number>— PR number. Resolves to the latest CI run on that PR's head SHA.- No argument — picks the latest failed run on the current branch.
Examples:
/diagnose-ci— diagnose the latest failure on the current branch./diagnose-ci 25636200176— diagnose run ID 25636200176./diagnose-ci 94— diagnose the latest failure on PR #94.
When to Use
Use this when:
- A PR's CI just turned red and you want a triaged diagnosis before guessing.
- You're rebasing or squashing and want to confirm a specific job is to blame, not noise.
- Multiple jobs failed in one run and you want to know whether they share a root cause.
- You hit a pre-merge gate and need to ship a minimal fix, not refactor the whole pipeline.
Do NOT use this when:
- The CI is green. There is nothing to diagnose; this command will exit with no findings.
- You are designing a new pipeline. Use
/researchor readcomponents/github-actions-guide.md. - The failure is a well-known intermittent flake your team already has a runbook for. Run the runbook directly.
The 7-Step Loop
The loop runs sequentially. Stop at the first step that explains every failed job.
Step 1 — Fetch the failure surface
Goal: a list of {job, step, conclusion, exit_code, log_tail} for every failed job, not just the one that surfaced first.
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.
- 6d ago First seen · 231 lines · 64 tokens per session scan A e041c992970a
diagnose-ci is a command published in the GitHub repository sergei-aronsen/claude-code-toolkit (5 stars, last pushed 20d ago), licensed MIT. It adds 64 tokens to every session and 2,614 once invoked, about $0.0003 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-31.
Other commands, from other repositories
ci-debug
Diagnose a failing CI run against an 11-pattern playbook. Classifies the failure, cites the relevant memory entry, proposes the exact fix command — but NEVER applies without explicit user approval. Use when a specific PR check or GitHub Actions run failed and you want a diagnosis instead of speculation. Don't use for…
metrics
Apply the CLI runtime and safety contract before executing a command. Runtime --help is authoritative.
proxy-logs
Apply the CLI runtime and safety contract before executing a command. Runtime --help is authoritative.
traces
Apply the CLI runtime and safety contract before executing a command. Runtime --help is authoritative.
add-debug-wait
Add a wait step to a CI workflow for debugging test failures.
ci-fix
Fix CI pipeline issues with interactive approval.