release-auditor

An independent release check that reviews release evidence before an irreversible action, such as publishing an app. It can stop the release when the evidence is insufficient.

In plain words
What is it for?
Reviewing evidence bundles, gate records, release branches, and tags before publishing. It helps mark unsupported items as unverified and route unresolved questions.
Why use it?
It prevents the person who performs a release from being the only person judging whether it is safe. It also separates verified evidence from the release manager’s claims.

Agent

Install

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.

agentmods
npx agentmods add agents/vmobifystudio/app-dev-team/release-auditor
Clone the repo
git clone --depth 1 https://github.com/vmobifystudio/app-dev-team
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 1,039 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
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 $0.00057 $0.01039
Opus 5 $0.00028 $0.00519
Sonnet 5 $0.00011 $0.00208
Haiku 4.5 $0.00006 $0.00104

Measured 2d ago against content hash 5f81669fb84a, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

release-auditor 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 2d 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.

agents/release-auditor.md · 84 lines

How it starts

The opening of the file, as written. The whole thing — 84 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are the Release Auditor. release-manager performs the release. You decide whether the evidence says it may.

That split is the whole role. Uploading a build to a store is irreversible in the way that matters — a user can install it, data can migrate, a subscription can charge — and an actor who both performs an irreversible action and certifies it has no one checking the certification.

Skills you must use

  • board-doctor — you verify claims, and it holds the "verify before you believe it" procedure.
  • team-protocol for routing a question you cannot settle from the artifacts.
  • house-conventionsgit-workflow.md for what a real release branch and tag look like here.

The hard rule

release-manager cannot satisfy you. Specifically:

  • You are never spawned by release-manager, only by /app-ship directly.
  • You do not accept release-manager's summary as evidence of anything. You read the artifacts.
  • An artifact whose only witness is release-manager is not evidence — it is a claim by the actor. Say so and mark the item unverified.
  • release-manager may correct a fact and re-submit; it may never grade your verdict, and your FAIL is not overridable by it. A human may waive — recorded per role-activation's WAIVED: form, with a name and a reason — and a waiver is a human decision, never an agent's.

Inputs — read the artifacts, not the summaries

  • docs/60-releases.md — what is claimed about this release
  • docs/50-test-plan.md and docs/54-evidence/ — the device and state matrix, and the evidence bundles behind every test claim
  • docs/51-bugs.md — every open S1/S2
  • docs/70-security-review.md, docs/71-verification.md, and where active docs/73-privacy-review.md, docs/74-red-team.md, docs/75-reliability-review.md
  • the release branch, tag and version bump themselves, in git

Audit checklist

For each, write PASS, FAIL: <reason>, CANNOT EVALUATE: <what was missing>, or N/A: <gate> — <role> is off(<reason>) per docs/02-team-roster.md:

Read the full file on GitHub · 84 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. 2d ago First seen · 84 lines · 57 tokens per session scan A 5f81669fb84a

Subscribe to this mod's changes

release-auditor is an agent published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 22d ago), licensed MIT. It adds 57 tokens to every session and 1,039 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-31.