Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/rjwalters/kicad-toolsnpx agentmods add commands/rjwalters/kicad-tools/judge-ci-redWrote 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/rjwalters/kicad-tools/judge-ci-red)<a href="https://agentmods.dev/commands/rjwalters/kicad-tools/judge-ci-red"><img src="https://agentmods.dev/badge/commands/rjwalters/kicad-tools/judge-ci-red/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/commands/rjwalters/kicad-tools/judge-ci-red"><img src="https://agentmods.dev/badge/commands/rjwalters/kicad-tools/judge-ci-red.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.00000 | $0.01840 |
| Opus 5.5 | $0.00000 | $0.00736 |
| Sonnet 5.5 | $0.00000 | $0.00368 |
| Haiku 4.5 | $0.00000 | $0.00184 |
Grade A, and why
judge-ci-red 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 today.
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 — 121 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Judge: CI Is Red — Finished Run, Named Test, Recorded Flake Rerun (#12011)
Load when: loom-daemon forge wait-checks printed LOOM-CHECKS-RED, or
post-verdict.sh … approved exited 6, and a CI-failing verdict is next.
Why this exists
On PR #11974 (YAML and docs only) a Judge posted changes-requested +
loom:ci-failure because one leg, Rust Unit Tests (2/3), was red while other
jobs still ran. wait-checks reports RED as soon as one check fails, and
gh run view --log-failed cannot read a log until the whole run completes, so
the verdict named no test. The test was a tracked flake (#11073); attempt 2 was
green minutes later. This file prevents three things: a CI verdict on a
partial run, a CI verdict that names no test, and a changes-requested for a
known flake.
1. The run must be finished
err="$(mktemp)"; first="$(loom-daemon forge wait-checks <number> --timeout 20 --settle-red 2>"$err" | head -n1)"
| First line | Action |
|---|---|
LOOM-CHECKS-TIMEOUT* / -HEAD-MOVED* |
The run has not finished. Follow judge.md "When CI is Pending". No CI-failing verdict on a partial run. In single-PR mode you may instead wait in the foreground with --timeout 1800 --settle-red. |
LOOM-CHECKS-GREEN* / -NONE* |
The red was superseded. Continue the review. |
LOOM-CHECKS-RED* |
Finished red. $err holds <name>\t<url>\t<run_id> per failing check. Go to step 2. |
-ERROR* or empty (older binary without --settle-red, or Gitea) |
Run gh pr checks <number> once. If any check is still pending, treat it as TIMEOUT. |
2. Name the failing test or step
For each run_id, read the finished log:
gh run view <run_id> --json attempt,jobs -q '{attempt, failed: [.jobs[] | select(.conclusion=="failure") | {name, url, steps: [.steps[] | select(.conclusion=="failure") | .name]}]}'
gh run view <run_id> --log-failed | grep -E 'FAILED|FAIL |panicked|^failures:|error(\[|:)' | head -40
Write down the failing test (full path, e.g.
observability::sender::tests::a_batch_is_cut_at_the_byte_budget_and_never_below_one_envelope).
If the failure is not a test (clippy, fmt, a check-*.sh gate, a build), name
the step. "A job failed" is not a name. A check with run_id - (not an
Actions run) has no log here: name the check and its URL, then go to step 5.
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.
- today Changed · +10 lines 26fd3d568d3a
- yesterday First seen · 111 lines · 0 tokens per session scan A 26fdef3f3c2c
judge-ci-red is a command published in the GitHub repository rjwalters/kicad-tools (70 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,840 tokens. 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-10-16.
Other commands, from other repositories
write-test-plan
Generate or update change test plan.
test-setup
Scaffold test framework and CI pipeline.
ci-setup
Setup CI pipeline from scratch. Creates GitHub Actions or GitLab CI configuration with lint, test, build, and deploy stages.
harness:cicd-fleet
Autonomous CI/CD-remediation orchestrator — triage the red CI/CD-run and flaky-test backlog by cause, fan out worktree-isolated subagents that run the real deflake/heal pipeline, independently verify each fix by artifact and deterministic all-OS CI, and hand back a batch of remediation PRs for one bulk human review.…
check-fix
Execute quality gates, fix any issues found, and create a single high-quality Conventional Commit summarizing all changes made.
quality-check
Execute a comprehensive quality gate check (lint, test, build, format) before allowing code to merge.