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 skills add EZotoff/ez-omo-config --skill rollout-watchgit clone --depth 1 https://github.com/EZotoff/ez-omo-configWrote 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/skills/ezotoff/ez-omo-config/rollout-watch)<a href="https://agentmods.dev/skills/ezotoff/ez-omo-config/rollout-watch"><img src="https://agentmods.dev/badge/skills/ezotoff/ez-omo-config/rollout-watch/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/skills/ezotoff/ez-omo-config/rollout-watch"><img src="https://agentmods.dev/badge/skills/ezotoff/ez-omo-config/rollout-watch.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.00092 | $0.01575 |
| Opus 5.5 | $0.00037 | $0.00630 |
| Sonnet 5.5 | $0.00018 | $0.00315 |
| Haiku 4.5 | $0.00009 | $0.00158 |
Grade A, and why
rollout-watch 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 11d 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 — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
rollout-watch — OMO binding for the rollout protocol
Base (harness-agnostic): docs/rollout-protocol.md, scripts/rollout-monitor.py.
This skill adds ONLY the opencode/OMO-specific wiring. The base must stay usable
without anything on this page.
When this fires
Any task that (a) adds a write-path or autonomous behavior to a harness
component, (b) flips an enabled flag that activates previously-shadow
behavior, or (c) deploys a new long-running service. If the change cannot fail
silently, the protocol still applies — it just terminates early.
1. Arming the ladder (durably — never an agent promise)
A turn-based agent has no clock; the ladder's 12h plateau gaps exceed any
subagent's 30-min inactivity window. Therefore the monitor runs as a systemd
transient unit, not a background subagent and not a nohup &:
systemd-run --user --unit="rollout-<feature>" \
-p Restart=on-failure -p RestartSec=15 \
python3 ~/ez-omo-config/scripts/rollout-monitor.py \
--config ~/.local/state/opencode-rollout/<feature>.rollout.json
# daemon mode sleeps ≤600s between due-checks. Restart=on-failure (NOT always):
# the monitor exits 0 on ladder completion/stopped — an always-restart would
# respawn-churn a finished rollout.
Check arming: systemctl --user status rollout-<feature>. State + rounds log
live under ~/.local/state/opencode-rollout/ — killing the unit loses nothing;
relaunching resumes from state (idempotent by design).
The deploying agent's obligation after arming: verify the unit is active AND the state file exists in the same turn. Then end the turn — the wake trigger is the unit itself; findings surface via the rounds log and gate records.
2. Evidence sources (detector → OMO adapter)
| Protocol detector | Adapter on this host |
|---|---|
| Availability probe | systemctl --user is-active <unit>; ps -eo pid,lstart,args start-time check for bare processes |
| Error-class histogram | journalctl --user -u <unit> --since <ts> -p err; for ledger-keeping services: jq -r 'select(.type=="ERROR") | .payload.error' <ledger> | normalize | sort | uniq -c |
| Telemetry motion | status JSON counters (~/.local/state/<svc>/status.json) — any counter that can read 0 must be checked for motion once its path was active |
| Three-way cross-exam | claims ledger vs ~/.local/share/opencode/opencode.db (read-only sqlite: message+part tables) vs published read models (operator-view.json etc.) |
| Timeline correlation | for each produced artifact, grep the consumer's log/ledger for the corresponding event id within tolerance |
| Ground-truth reconstruction | run the feature's real modules over a captured real input (bun/python import from the repo) — never trust the green test suite alone |
| Human review | render outputs to the operator (paste rendered artifact in the final message, or screenshot for UI) — mandatory at presentation rounds |
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.
- 11d ago First seen · 104 lines · 92 tokens per session scan A d962e81485e9
rollout-watch is a skill published in the GitHub repository EZotoff/ez-omo-config (6 stars, last pushed 2d ago), licensed MIT. It adds 92 tokens to every session and 1,575 once invoked, about $0.0004 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-10-05.
Other skills, from other repositories
aws-serverless
AWS serverless architecture principles. Lambda, API Gateway, DynamoDB, S3, SAM/CDK patterns. Use when building serverless applications on AWS.
kubernetes-architect
Kubernetes architecture principles. Cluster design, Helm charts, GitOps, scaling strategies, and production operations. Use when deploying containerized applications at scale.
terraform-specialist
Infrastructure as Code with Terraform. Module design, state management, multi-environment patterns, and best practices. Use when provisioning cloud infrastructure.
vercel-deployment
Vercel deployment patterns. Preview deployments, edge functions, ISR, analytics, and production optimization. Use when deploying Next.js or frontend apps on Vercel.
edge-computing
Edge computing patterns for Cloudflare Workers, Vercel Edge, Deno Deploy, and AWS Lambda@Edge. Use when building globally distributed, low-latency applications.
deployment-procedures
Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.