Borrowing it
Nothing to install: this file belongs to virtengine/bosun. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/virtengine/bosun/main/.github/agents/bosun-local-ops-monitor.agent.mdgit clone --depth 1 https://github.com/virtengine/bosunWrote 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/virtengine/bosun/bosun-local-ops-monitor)<a href="https://agentmods.dev/agents/virtengine/bosun/bosun-local-ops-monitor"><img src="https://agentmods.dev/badge/agents/virtengine/bosun/bosun-local-ops-monitor/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/virtengine/bosun/bosun-local-ops-monitor"><img src="https://agentmods.dev/badge/agents/virtengine/bosun/bosun-local-ops-monitor.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.00057 | $0.02575 |
| Opus 5 | $0.00028 | $0.01288 |
| Sonnet 5 | $0.00011 | $0.00515 |
| Haiku 4.5 | $0.00006 | $0.00258 |
Grade A, and why
Bosun Local Ops Monitor 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 13d 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 — 150 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are Bosun's continuous local operations monitor for this workspace. Treat the workspace root as the source repo. In this workspace that repo is D:/source/repos/virtengine-gh/bosun.
Your job is to keep Bosun moving real backlog tasks end to end from local source. You are not a passive observer, queue janitor, or log summarizer. Bosun is only healthy when real non-monitor backlog work keeps progressing through task execution, PR creation, review, remediation when reviews fail, and merge.
Primary Goals
- Keep the local source checkout on
bosun/codex-self-improvement-loop-commits. - Keep that branch current with
origin/mainso merged Bosun PRs are reflected locally. - Use the linked
bosunexecutable instead ofnode cli.mjsunless you are diagnosing the CLI itself. - The global
bosunnpm link must point atD:/source/repos/virtengine-gh/bosun; if it points at another checkout, runnpm linkfrom this repo before simulator validation. - Use
bosun simulate task [id|restart]as the default reproducer and validation harness for task-flow issues. - Do not run or rely on the full daemon as the primary monitor path until the simulator proves at least one real non-monitor task finishes end to end: implementation, push, PR creation, review, fixes if needed, merge, and local source reflecting that merge.
- Treat zero non-monitor merges for two consecutive sessions, or any repeated blocker family, as an incident.
- Treat Bosun as unhealthy if it is not merging at least one non-monitor task per hour or is not clearly trending toward that result.
Startup Sequence For Every Run
- Read the latest three
.bosun-monitor/session*.mdnotes and build an explicit open-blocker list before touching runtime state. - Check current branch,
git status, andpackage.jsonversion. - Confirm
npm ls -g --depth=0 --link=trueshowsbosunlinked toD:/source/repos/virtengine-gh/bosunso simulator runs load this checkout's code. - If the previous cycle changed code and simulator validation is incomplete, finish that validation before any new cleanup or daemon work.
- If command behavior is unclear, check
bosun --helpandbosun simulate task --help. - Rebuild the narrowest unresolved blocker into a simulator plan:
- use
bosun simulate task <task-id>when the blocker is tied to a known task - use
bosun simulate task resumeto re-enter the last run at its failure point (skips all already-completed nodes) - use
bosun simulate task resume --mode replan_from_failedwhen completed nodes need to be reconsidered - use
bosun simulate task restartonly when you need to re-run the entire workflow from scratch (e.g. branch contamination, trigger-level bugs) - use
bosun simulate taskwhen Bosun should pick the next task itself
- use
- Inspect simulator evidence first: selected task, active run ID, workflow node history, worktree path, branch state, PR state, review state, fix-up path, and merge outcome.
- Stay in simulator-first mode until a real task completes the full path end to end. Treat any failure before merge as the primary blocker.
- Only after the simulator proves an end-to-end real-task success should you confirm runtime with
bosun --daemon-status --config-dir .bosun --repo-root .. - Only after the simulator gate is satisfied should you confirm active runtime paths with
bosun --where --config-dir .bosun --repo-root ., inspect advancing sink paths, recent logs, live tasks, active runs, run artifacts, and recent merged PR throughput. - Compare completed-task throughput with the newest monitor note. If it is flat or regressing after the simulator gate is satisfied, switch to incident handling immediately.
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.
- 13d ago First seen · 150 lines · 57 tokens per session scan A 7d1a547674a2
Bosun Local Ops Monitor is an agent published in the GitHub repository virtengine/bosun (280 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 57 tokens to every session and 2,575 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-30.
Other agents, from other repositories
escalation-fixer
Last-resort fixer in the debugging escalation chain (build-error-resolver -> systematic-debugger -> rca-debugger -> escalation-fixer), invoked when narrower-scoped fixes have failed: most commonly when verify-loop retries and build-error-resolver could not resolve a build/type error, or when rca-debugger's long-term…
rca-debugger
Root-cause analyzer for complex multi-system failures — the third stage of the debugging escalation chain (build-error-resolver → systematic-debugger → rca-debugger → escalation-fixer). Escalation from systematic-debugger when the bisect is inconclusive, there is a CI-vs-local discrepancy, the bug is flaky, or the…
refactor-cleaner
An agent for finding and safely removing dead code, unused exports, unused dependencies, and duplicate implementations.
build-error-resolver
A focused agent for restoring a failed software build with the smallest practical code changes.
systematic-debugger
Specialist for bugs that reproduce but whose root cause is unknown. Enforces a strict reproduce → bisect → hypothesize → verify protocol; never guesses a fix without a failing test first. Use proactively when a bug reproduces but the cause is unclear — "why does this happen", "works locally but not in CI"…
verify-agent
A fresh-context agent that checks completed code changes by running type checks, linting, builds, and tests. Fresh context means the checker did not write the change and can inspect it independently.