bosun: Agent for Claude Code

.github/agents/bosun-local-ops-monitor.agent.md

Bosun Local Ops Monitor is an agent for Claude Code from virtengine/bosun. It costs 57 tokens per session (2,575 once invoked), scanned A, original, Apache-2.0.

A local operations monitor for Bosun, a system that runs coding tasks through pull requests, reviews, and merges.

In plain words
What is it for?
It helps validate task execution with a simulator, check daemon health, and monitor work through review, fixes, and merging.
Why use it?
It checks whether real tasks are progressing through the full workflow instead of only watching logs or queues.

Agent for Claude Code

Written for Claude Code: argument-hint in frontmatter. Also seen: mentions Codex.

This is virtengine/bosun's own configuration. It tells Claude Code how to work on bosun itself, so it is not a mod to install elsewhere. Copy it as a starting point and replace the rules that are about this project. Everything bosun configures →

Reuse

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.

Copy the file
curl -O https://raw.githubusercontent.com/virtengine/bosun/main/.github/agents/bosun-local-ops-monitor.agent.md
Clone the repo
git clone --depth 1 https://github.com/virtengine/bosun

Made for: Claude Code.

Wrote 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.

agentmods badge for Bosun Local Ops Monitor

README.md
[![agentmods](https://agentmods.dev/badge/agents/virtengine/bosun/bosun-local-ops-monitor/github.svg)](https://agentmods.dev/agents/virtengine/bosun/bosun-local-ops-monitor)
Your own site
<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.

agentmods 80×15 button for Bosun Local Ops Monitor

Your own site · 80×15
<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>
Per session 57 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,575 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 13d ago against content hash 7d1a547674a2, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-12, from the pricing page.

Security

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.

.github/agents/bosun-local-ops-monitor.agent.md · 150 lines

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/main so merged Bosun PRs are reflected locally.
  • Use the linked bosun executable instead of node cli.mjs unless you are diagnosing the CLI itself.
  • The global bosun npm link must point at D:/source/repos/virtengine-gh/bosun; if it points at another checkout, run npm link from 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

  1. Read the latest three .bosun-monitor/session*.md notes and build an explicit open-blocker list before touching runtime state.
  2. Check current branch, git status, and package.json version.
  3. Confirm npm ls -g --depth=0 --link=true shows bosun linked to D:/source/repos/virtengine-gh/bosun so simulator runs load this checkout's code.
  4. If the previous cycle changed code and simulator validation is incomplete, finish that validation before any new cleanup or daemon work.
  5. If command behavior is unclear, check bosun --help and bosun simulate task --help.
  6. 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 resume to re-enter the last run at its failure point (skips all already-completed nodes)
    • use bosun simulate task resume --mode replan_from_failed when completed nodes need to be reconsidered
    • use bosun simulate task restart only when you need to re-run the entire workflow from scratch (e.g. branch contamination, trigger-level bugs)
    • use bosun simulate task when Bosun should pick the next task itself
  7. 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.
  8. 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.
  9. 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 ..
  10. 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.
  11. 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.

Read the full file on GitHub · 150 lines

Changes

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.

  1. 13d ago First seen · 150 lines · 57 tokens per session scan A 7d1a547674a2

Subscribe to this mod's changes

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.

Related

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…

sangrokjung/claude-forge · 118 tokens

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…

sangrokjung/claude-forge · 118 tokens

refactor-cleaner

An agent for finding and safely removing dead code, unused exports, unused dependencies, and duplicate implementations.

sangrokjung/claude-forge · 109 tokens

build-error-resolver

A focused agent for restoring a failed software build with the smallest practical code changes.

sangrokjung/claude-forge · 106 tokens

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"…

sangrokjung/claude-forge · 170 tokens

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.

sangrokjung/claude-forge · 134 tokens