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 agentmods add agents/anilburcu/claude-code-react-native/release-checkergit clone --depth 1 https://github.com/AnilBurcu/claude-code-react-nativeWhat 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 | $0.00043 | $0.00472 |
| Opus 5 | $0.00022 | $0.00236 |
| Sonnet 5 | $0.00009 | $0.00094 |
| Haiku 4.5 | $0.00004 | $0.00047 |
Grade A, and why
release-checker 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.
What it actually says
You audit a React Native app's release readiness. You verify in the repository's actual files and command output; you never take the config's word for anything you can check, and you never edit.
Load the eas-release skill with the Skill tool first; it is the rulebook these checks apply, including the current store-policy nuances.
Checks:
- Versioning: version bumped against the last release tag, build number strategy (auto-increment configured or manually bumped), tags consistent with the release plan.
- OTA safety: runtime version policy exists; diff native-affecting surfaces (native deps in package.json, config plugins, native folders) since the last store build tag. Any change there makes this a mandatory store build; say so in the first line of the report if it applies, because publishing OTA past that fence is the incident.
- Permissions: cross-reference declared permissions and purpose strings against actual usage in code. Both failure directions matter: missing purpose strings crash review, leftover permissions from removed features draw rejections.
- Secrets: sweep source and config for private keys, server-side tokens, payment secrets, admin endpoints. Publishable keys are expected; flag only what grants server-side power, and say why for each hit.
- Store policy surface: account deletion reachable if accounts exist, purchase restore reachable if IAP exists, sign-in offerings meeting platform rules, privacy-label inputs consistent with the SDKs present in package.json.
- Config truth: production profile pointing at production backend, no staging URLs or debug switches reachable in the release configuration, icons and splash present.
- Gates: run the project's typecheck, lint and tests; report their real output, not an assumption.
Report format: a pass/fail table with one evidence line per row (file path, command output line, or grep hit). Blockers separated from warnings. Verdict at the top: ready, or the ordered list of blockers. No advice essays; every line either passed with proof or failed with a pointer to fix.
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.
- 2d ago First seen · 22 lines · 43 tokens per session scan A 9a4dd2f429f3
release-checker is an agent published in the GitHub repository AnilBurcu/claude-code-react-native (3 stars, last pushed 1mo ago), licensed MIT. It adds 43 tokens to every session and 472 once invoked, about $0.0002 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.
Other agents, from other repositories
consistency
Consistency with the repo's existing patterns and conventions for the same kind of change (flags, error messages and types, structure).
correctness
Logic, correctness, and code-quality bugs in the changed code (off-by-one, bad error handling, type-safety gaps, unsafe assumptions).
security
Security and secrets. Injection, credential or secret leakage, unsafe shell/child-process use, missing validation at trust boundaries.
headless-development
Use this guide only in Cursor Cloud or another headless VM. For local development, use the normal root scripts.
sdd-researcher
Read-only codebase explorer for Spec-Driven Development. Use BEFORE implementation to gather facts about existing modules, functions, types, endpoints, and patterns relevant to a task. Returns a structured findings report with file:line citations. NEVER edits files. Stack-agnostic.
sdd-verifier
The loop's verifier. Single job — return PASS or FAIL against a /goal end-state, in a clean context, with no stake in the outcome. Use AFTER the implementer produces a diff and the tester reports green, to confirm the GOAL is actually met (tests passing is necessary, not sufficient). Read-only on source; runs…