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 skills add AnilBurcu/claude-code-react-native --skill eas-releasegit clone --depth 1 https://github.com/AnilBurcu/claude-code-react-nativeWrote 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/skills/anilburcu/claude-code-react-native/eas-release)<a href="https://agentmods.dev/skills/anilburcu/claude-code-react-native/eas-release"><img src="https://agentmods.dev/badge/skills/anilburcu/claude-code-react-native/eas-release/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/skills/anilburcu/claude-code-react-native/eas-release"><img src="https://agentmods.dev/badge/skills/anilburcu/claude-code-react-native/eas-release.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.00040 | $0.01474 |
| Opus 5.5 | $0.00016 | $0.00590 |
| Sonnet 5.5 | $0.00008 | $0.00295 |
| Haiku 4.5 | $0.00004 | $0.00147 |
Grade A, and why
eas-release 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 — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Shipping: EAS builds, OTA updates and the stores
Build profiles that mean something
Three profiles cover almost every team:
development: dev client, internal distribution, debug-friendly. For daily work.preview: release build, internal distribution. What QA and stakeholders touch. It must match production configuration except for distribution, or QA is testing a different app.production: store distribution,autoIncrementon, credentials on EAS.
Per-profile env vars are for pointing at staging vs production backends. The bug to design against: a preview build silently talking to production data, or the reverse. Print the target backend on the dev/preview build's about screen and this class of incident becomes visible at a glance.
OTA updates and the runtime fence
The runtime version is the safety fence. An update reaches only binaries with a matching runtime version, and every native change (new native dependency, config plugin change, SDK upgrade) changes what the JS can assume about the binary.
"runtimeVersion": { "policy": "appVersion" }ties the fence to the app version. Reasonable default: bump the version for native changes (you will anyway) and the fence moves with it.- The catastrophic misconfiguration: shipping JS that requires a native module older binaries lack, to a channel those binaries still read. Result is a crash-on-launch for existing users, fixable only by another update or a store release. Before any OTA publish, the question is "does this JS run on every binary still reading this channel?" If a native anything changed since the last store build, the answer is no; ship a store build.
- Channels map to environments (production, preview). Keep the mapping boring and documented in the repo.
- Rollback plan: republish the previous known-good update. Practice it once before you need it during an incident.
Versioning discipline
- User-facing version (
version) and store build numbers (versionCode/buildNumber) are different things. Let EAS auto-increment build numbers; bump the version deliberately per release. - Never reuse a build number on iOS; the store rejects the upload and the pipeline halts on a bookkeeping error.
- Tag releases in git with the version AND store build number, and archive source maps per release. Future-you, symbolicating a crash from an old release, depends on this being a habit.
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 Changed · +4 lines · -14 tokens per session f5cf204fb3df
- 1mo ago First seen · 57 lines · 54 tokens per session scan A 28626c5e4774
eas-release is a skill published in the GitHub repository AnilBurcu/claude-code-react-native (3 stars, last pushed 1mo ago), licensed MIT. It adds 40 tokens to every session and 1,474 once invoked, about $0.0002 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 skills, from other repositories
apple-release-ops
The mechanics of shipping Apple apps. Use for ANY code signing error ("no signing certificate", "provisioning profile doesn't include...", "revoked certificate"), provisioning profiles, certificates, entitlements, capabilities, TestFlight (groups, expiry, feedback), App Store Connect, uploading builds, xcodebuild…
expo-56
Authoritative, version-pinned reference for Expo SDK 56 and SDK 57 — both postdate your training, so defer to this skill over memory for anything Expo. SDK 57 is the current release (2026-07-08, React Native 0.86); SDK 56 is the previous, still-supported release (React Native 0.85). Use it whenever the user is…
ios-app-store-submission
Build and submit iOS apps to App Store Connect using fastlane (match/gym/pilot/deliver) or EAS (eas build / eas submit) for native (Swift/SwiftUI/UIKit), React Native, Expo, Flutter, and Capacitor projects. Use when archiving to .xcarchive, validating, uploading to TestFlight, configuring code signing and…
submitting-app-release
Runs pre-flight validation gates and submits the app to App Store Connect and Google Play Console via EAS CLI. Use when the user says "release", "submit to store", "publish", "deploy app", or "submit for review". Always runs release-checklist.js first — never submits past a failing gate without explicit user…
managing-app-versions
Manages semantic versioning for mobile apps across iOS and Android platforms. Use when the user says "bump version", "increment build number", "set version to", "release patch/minor/major", or "sync build numbers". Single source of truth is .msd/versions/{app-id}/version.json. Syncs to app.json (Expo), Info.plist…
axiom-shipping
Use when preparing an app for App Store submission, handling rejections or appeals, managing App Store Connect and Xcode Cloud, or triaging TestFlight/Sentry crash corpora. Covers checklists, metadata, privacy manifests, age ratings, export compliance.