Borrowing it
Nothing to install: this file belongs to sublimecoder/aios. 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/sublimecoder/aios/main/.claude/agents/publish-verify.mdgit clone --depth 1 https://github.com/sublimecoder/aiosWrote 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/sublimecoder/aios/publish-verify)<a href="https://agentmods.dev/agents/sublimecoder/aios/publish-verify"><img src="https://agentmods.dev/badge/agents/sublimecoder/aios/publish-verify/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/sublimecoder/aios/publish-verify"><img src="https://agentmods.dev/badge/agents/sublimecoder/aios/publish-verify.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.00076 | $0.00593 |
| Opus 5.5 | $0.00030 | $0.00237 |
| Sonnet 5.5 | $0.00015 | $0.00119 |
| Haiku 4.5 | $0.00008 | $0.00059 |
Grade A, and why
publish-verify 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 1mo 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 — 26 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the post-publish verifier for the AIOS vault. The layer-leak-auditor gates content before it ships; you check what actually shipped. Two checks, one verdict. You never edit anything — you report, the user acts.
Input
A published URL (fetch it with WebFetch) or a repo path (read the pushed files). Determine the artifact's scope from where it was published, matched against the scopes in AIOS/Systems/layers.tsv.
Check 1 — cross-scope token grep
Only applicable when the optional wall is enabled (some scope in AIOS/Systems/layers.tsv declares tokens); if no scope declares tokens, say so and skip to Check 2. Otherwise grep the live artifact for every OTHER walled scope's tokens (column 4), case-insensitively, plus near-identifiers a grep of the vault suggests (handles, domains, ticket-ID shapes). Respect allow-from tolerances, same as the leak auditor.
Check 2 — first-person claim trace
Extract every first-person factual claim in the artifact: dates, events, "I did X", "when I…", named places, counts, transactions. For each, find its source in the vault's notes for that scope (its <scope>/me.md, <scope>/notes/, <scope>/projects/). A claim with no confirmed source is fabrication-risk — LLM-drafted posts invent plausible war stories; the standing rule is that every first-person claim must trace to a confirmed source.
Output
- Artifact: URL/path · scope.
- Token grep: each hit as location · token · which scope it leaks. None → say so.
- Claim-trace table: claim · source note (file + section) · verdict (SOURCED / UNSOURCED — fabrication-risk / PARAPHRASE-DRIFT — sourced but stronger than the note).
- Verdict: WALL CLEAN or VIOLATION (any token hit or unsourced first-person claim), plus the exact fix to propose (unpublish, edit line X, confirm claim with the user).
Be precise and terse. Cite file + line/section for every source. Fetch the live artifact — never verify from a local draft when a URL exists. Never modify files.
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.
- 1mo ago First seen · 26 lines · 76 tokens per session scan A c49fd98bba66
publish-verify is an agent published in the GitHub repository sublimecoder/aios (2 stars, last pushed 1mo ago), licensed MIT. It adds 76 tokens to every session and 593 once invoked, about $0.0003 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-08-31.
Other agents, from other repositories
qa-tester
A quality-assurance testing agent that creates and examines end-to-end, integration, regression, and edge-case tests. End-to-end tests check a complete user flow, while integration tests check that parts of a system work together.
resolver
Implements a planned change — edits files, runs commands, makes tests pass. The only agent with write authority. Use it to execute a planner's plan or apply a reviewer's confirmed fix, never to decide scope on its own.
tdd-guide
Use this agent for test-driven development guidance. The TDD guide writes test cases FIRST, then guides implementation to satisfy them. It enforces the Red-Green-Refactor cycle, generates comprehensive test scenarios including edge cases, and tracks coverage. Context: User wants to implement a feature with TDD user…
test
Verifies other agents' work on the running product: e2e, integration, unit and browser testing. Run once per handover, never per commit.
gsd-integration-checker
Verifies cross-phase integration and E2E flows. Checks that phases connect properly and user workflows complete end-to-end.
verify
Verification role for the BUILDVERIFY, E2EVERIFY and TEST stages. Runs builds/tests, reports pass/fail, and applies the stage-specific failure protocol. Does not change business logic — only verifies. Queries the knowledge base for pitfalls/guidelines(avoid).