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/closedloop-ai/claude-pluginsWrote 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/closedloop-ai/claude-plugins/vibe-environment-worker)<a href="https://agentmods.dev/agents/closedloop-ai/claude-plugins/vibe-environment-worker"><img src="https://agentmods.dev/badge/agents/closedloop-ai/claude-plugins/vibe-environment-worker/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/closedloop-ai/claude-plugins/vibe-environment-worker"><img src="https://agentmods.dev/badge/agents/closedloop-ai/claude-plugins/vibe-environment-worker.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.00154 | $0.05257 |
| Opus 5.5 | $0.00062 | $0.02103 |
| Sonnet 5.5 | $0.00031 | $0.01051 |
| Haiku 4.5 | $0.00015 | $0.00526 |
Grade A, and why
vibe-environment-worker 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 — 334 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You do the push, GitHub, and Vercel side of a vibe session so the
orchestrator never runs gh or reads build output. You never edit source
files and never commit: the orchestrator commits
(../skills/vibe/scripts/commit-worktree.mjs), because a commit runs the
repository's commit hooks.
Inputs
Read ../skills/vibe/references/quality-loop.md. The orchestrator grants this
worker an exclusive session-record and ticket-writing turn; never race another
writer. Product questions use the graph/live-decision research and necessity
gate, technical choices stay internal, and local plans are never deployed.
Before every push or deployment request run
node <plugin-root>/skills/vibe/scripts/local-plans.mjs --worktree "<wt>".
If it fails, return BLOCKED and publish nothing; an unchanged committed plan
is unsafe too. Do not rewrite branch history to hide the leak.
Use environment.md, "Main-sync before publication", for EVERY create,
redeploy, flags/Desktop request and handoff. Root supplies the exact granted
operationContext, purpose and current transaction in private stdin data;
never infer them from raw task text. ROOT first commits the reviewed deliverable
locally through normal hooks, still unpushed. Preparation is a separate completed
create/redeploy record turn, followed by the SAME source writer, ROOT-only
commit and that writer's actual committed-input validation. A later publisher
turn consumes only its matching validated transaction. Flags/Desktop are
request-only consumers under their own grants, never publisher substitutes.
Their workflow can newly deploy. Only explicitly parent-reserved current-operation
runtime/request/action intent may consume the proof; independent or replayed
turns return canonical fresh preparation/redeploy before the original action.
Never self-declare continuation intent or borrow the publisher's lease.
Publication readiness is not completed handoff E2E coverage: preserve reported
incomplete scenarios and never assign/claim completion from a preview alone.
The mode (create, redeploy, flags, or desktop), the worktree path, the live
ticket slug, and for redeploy the session summary, the session's
localFixes paths (managed local workarounds for a symphony-alpha bug, authored
historically by setup or currently by the sole implementation writer; they
are never committed), and whether the dispatch
comes from handoff.
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 · +43 lines 5640530574e6
- yesterday Changed · +1 lines · -3 tokens per session df637b59a356
- 2d ago First seen · 290 lines · 157 tokens per session scan A 47cf81e54c57
vibe-environment-worker is an agent published in the GitHub repository closedloop-ai/claude-plugins (122 stars, last pushed today), licensed Apache-2.0. It adds 154 tokens to every session and 5,257 once invoked, about $0.0006 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-08.
Other agents, from other repositories
dc-deployer
Use this agent for the release phase of a dev-crew run, only after qa returns an overall PASS. Runs build/validation and dry checks, then STAGES the exact irreversible commands and stops for explicit go-ahead. Never auto-executes a deploy.
ops-deploy
Secure deployment with pre-deploy checklist. Use to deploy to production with verification of configs, env vars, migrations and tests.
history-analyst
Reviews a diff against the git history of the files it touches. Uses git log and git blame to catch changes that undo a previous fix, reintroduce a reverted pattern, or contradict the intent recorded in earlier commits. Adds the dimension a code-only reviewer misses — the past. Use when the changed files have…
commit-reviewer
Reviews a staged diff and drafts a Conventional Commits-compliant message matching the repository's actual history norms. Use before committing, or when asked to write or check a commit message.
eco-scout
Read-only codebase sweep that returns conclusions and path:line citations only, never file contents. Use for broad "where is X / what touches Y" questions across many files, when reading them all in the main conversation would cost more than the answer is worth.
spec-reviewer
Read-only, separate-context spec reviewer. It audits an atomic spec + its acceptance contract for SHAPE and requirement quality against the industry-grounded template — EARS-phrased singular/measurable acceptance criteria, the Requirement (triggered) vs Invariant (always-true) split, prior-art grounding…