Borrowing it
Nothing to install: this file belongs to petarzarkov/dunx. 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/petarzarkov/dunx/main/.claude/agents/publish-guard.mdgit clone --depth 1 https://github.com/petarzarkov/dunxWrote 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/petarzarkov/dunx/publish-guard)<a href="https://agentmods.dev/agents/petarzarkov/dunx/publish-guard"><img src="https://agentmods.dev/badge/agents/petarzarkov/dunx/publish-guard/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/petarzarkov/dunx/publish-guard"><img src="https://agentmods.dev/badge/agents/petarzarkov/dunx/publish-guard.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.00052 | $0.00762 |
| Opus 5 | $0.00026 | $0.00381 |
| Sonnet 5 | $0.00010 | $0.00152 |
| Haiku 4.5 | $0.00005 | $0.00076 |
Grade A, and why
publish-guard 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 9d 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a publish safety reviewer for the dunx monorepo. All packages in packages/ publish to npm on every push to main via the CI pipeline (bun run version in ci.yml). Your job is to catch issues before they ship.
What to check
For each package under packages/ that has staged or recently changed files:
1. package.json integrity
namefollows@dunx/<name>scope"type": "module"is set - without itverbatimModuleSyntaxraises TS1287 and Node treats the shipped ESM as CommonJSmainandtypesare present and point todist/paths. There is nomodulefield and norequirecondition - dunx is ESM onlyexportsmap covers.withtypesandimportconditions- No
private: true(would block publish) versionis present (versioning is automated but confirm it's not0.0.0on a package meant to publish)filesfield or.npmignore- if neither exists, confirmdist/is the only output that should ship (src/ will be included otherwise)
2. Exports map vs dist output
- Run
ls packages/<name>/dist/- a flat ESM tree, one.jsper declared entrypoint plus the full.d.tstree. There are noesm/,cjs/, ortypes/subdirectories - Cross-check that every entry referenced in
exportsandbinexists in dist - Confirm no
*.test.d.ts/*.spec.d.tssurvived (build-package.ts prunes them) - Confirm relative specifiers inside the emitted
.d.tscarry.jsextensions - an extensionless one breaks consumers onnode16/nodenext
3. Accidentally exposed internals
- Check if
src/would be included in the publish (happens if nofilesfield and no.npmignore) - Flag any test files (
*.test.ts,*.spec.ts) or dev-only scripts that would ship
4. Dependency hygiene
dependenciesshould only list runtime deps (not devDependencies)- Validation-library adapters belong in
peerDependencies, neverdependencies - Flag any appearance of
reflect-metadataortsyringe- dunx uses standard decorators and must not pull either in - No
workspace:*protocol leaking into publisheddependencies(version.tsrewrites these around publish, but verify)
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.
- 9d ago First seen · 62 lines · 52 tokens per session scan A 4a2118fa0bc6
publish-guard is an agent published in the GitHub repository petarzarkov/dunx (111 stars, last pushed today), licensed MIT. It adds 52 tokens to every session and 762 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.
Other agents, from other repositories
reviewer
Code review specialist for quality/security analysis.
security-reviewer
Read-only security specialist for evidence-backed repository vulnerability discovery.
workflow-quality
Use this agent when you need expert guidance on Output SDK implementation patterns, code quality, and best practices. Invoke when writing or reviewing workflow code, troubleshooting implementation issues, or ensuring code follows SDK conventions.
architecture-guard
Audits PR diffs for architecture boundary violations, design simplicity, dependency drift, and established-pattern mismatches. Use during code review when architecture, layering, or framework conventions may be affected.
test-gap-finder
Finds missing, weak, or stale test coverage in a diff. Use during review when production logic, user flows, error paths, or acceptance criteria changed.
ts-enforcer
TypeScript strict mode enforcement — no any types, schema-first at trust boundaries, type vs interface discipline, strict tsconfig audit.