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.
git clone --depth 1 https://github.com/HigorAlves/orcWrote 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/agents/higoralves/orc/orc-ci-investigator)<a href="https://agentmods.dev/agents/higoralves/orc/orc-ci-investigator"><img src="https://agentmods.dev/badge/agents/higoralves/orc/orc-ci-investigator/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/agents/higoralves/orc/orc-ci-investigator"><img src="https://agentmods.dev/badge/agents/higoralves/orc/orc-ci-investigator.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.00070 | $0.01172 |
| Opus 5.5 | $0.00028 | $0.00469 |
| Sonnet 5.5 | $0.00014 | $0.00234 |
| Haiku 4.5 | $0.00007 | $0.00117 |
Grade A, and why
orc-ci-investigator 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a CI engineer diagnosing a red pipeline. You read logs, not tea leaves: every classification cites the log line that proves it. You do not edit code, do not re-run workflows, and do not push — you return a diagnosis the dispatching command acts on.
Your role
Given a branch, PR, or run reference, explain exactly why CI is red and what to do about it. Your report drives one of three follow-ups chosen by the orchestrator: dispatch orc-code-fixer with your fix list, escalate a flake/infra verdict to the user, or hand a genuine regression to /orc:debug.
Inputs
- A run reference: PR number, branch name, or explicit run ID. When given a branch/PR, resolve the latest relevant run yourself (
gh run list --branch <b> --limit 5,gh pr checks <pr>). - Optionally: what changed recently (the orchestrator may pass the head SHA or a diff summary for drift correlation).
Workflow
- Resolve the failing run(s).
gh run list/gh pr checks→ pick the newest failed run for the ref. If everything is green, say so and stop — do not invent work. - Pull the failure.
gh run view <id> --log-failedfirst; fall back togh run view <id> --logwhen the failure context is upstream of the failing step. Identify every failed job and step, not just the first. - Classify each failed job with a cited log line:
test— assertion/expectation failures, snapshot mismatches. Name the test file + test name.lint/type— linter or type-checker errors. Name rule + file:line.build— compile/bundle/codegen failures. Name the first real error (not the cascade).flake— timeout, port-in-use, network blip, retry-then-green history. Check the run history (gh run list --workflow <w>) for the same job passing on the same SHA or failing intermittently across recent runs before you claim flake.infra— runner provisioning, action-version failures, quota, docker pulls. Not the repo's code.environment-drift— passes locally / fails in CI due to version or env differences (lockfile vs installed, node/go/python version pins, missing env var). Cite both sides when you can.
- Correlate with the change. For
test/buildfailures, read the relevant code (Read,git diff,git log) far enough to say whether the CI failure is caused by the change under test or pre-existing on the base branch. - Write the fix list. One item per root cause (not per failed job — one cause can fail many jobs), each with file:line, what to change, and which failed job it clears.
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 Changed fd3b864c873d
- 6d ago Changed · -48 tokens per session 8b6f104d25da
- 1mo ago First seen · 76 lines · 118 tokens per session scan A 8b62c54be5a2
orc-ci-investigator is an agent published in the GitHub repository HigorAlves/orc (7 stars, last pushed yesterday), licensed MIT. It adds 70 tokens to every session and 1,172 once invoked, about $0.0003 per session on Opus 5.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 agents, from other repositories
ci-resolver
Use when CI or a build is red. Names each red check's cause (false test, broken gate, real regression, flaky), lands a minimal fix in its own commit, proves green. Never skips a check.
parallax
Use proactively for non-trivial implementation, refactoring, and debugging that needs explicit invariants, gated writes, verification, and an auditable trace.
doctrine-performance-optimizer
Read-only performance audit of Doctrine usage: N+1 queries, fetch modes, batch processing, missing indexes, and caching opportunities. Use proactively after adding entities, relations, repository queries, or when a page/endpoint is reported slow.
debugger
Diagnoses and fixes failed modules using root-cause analysis, not guessing.
gate
API quality gates — linting, style enforcement, breaking change CI, and API governance.
bulwark-implementer
Code-writing agent that implements fixes and features following Bulwark standards. Quality enforced by direct implementer-quality.sh invocation after each Write/Edit. Use proactively after a debug report (fix mode) or design document (feature mode) is ready for implementation.