Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →perminder-klair/subwave-app-ios-release
Cut a NEW iOS build of the SUB/WAVE app (the Expo project in `app/`) and ship it via EAS — to TestFlight, and on to the live App Store. The app is LIVE in production on the App Store, so a release is build+submit (one command) then a manual "promote to production" step in App Store Connect.
Passed 22 of 22 test cases with the skill, and 12 of 22 without it.
and 11 more in the full report
10 fixed12 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
Before starting a release for the SUB/WAVE iOS application, I want to quickly verify my Expo CLI authentication state. What exact command should I run, in which directory, and what account name should I expect to see?
| Checked | Without skill | With skill |
|---|---|---|
| The response specifies navigating into the app directory | Missed | Passed |
| The response specifies running eas whoami to check the logged-in user | Passed | Passed |
| The response expects the username pinku1 | Missed | Passed |
The instructions your model reads when the skill loads.
Build a fresh iOS binary in the cloud and push it to TestFlight. All the
painful one-time setup is already done — signing credentials live on EAS, the
App Store Connect app record exists, and eas.json is wired — so a normal
release is a single command. This skill is about doing it again, reliably, and
knowing what to check.
The first release required interactive setup (creating a distribution
certificate, registering the App Store Connect app). That's finished. EAS stores
the credentials server-side and app/eas.json pins the submit target, so repeat
builds run non-interactively — no Xcode, no Apple login prompts, no TTY.
The app ships expo-updates (OTA). If the change is JS/TS only — components, hooks, styles, copy, logic, Metro-bundled assets — you do not need a TestFlight build at all. Push it over-the-air to the binaries already out there:
cd "$APP"
eas update --channel production --message "fix: …" # testers first: --channel preview
It reaches every installed build whose runtime version (fingerprint) matches —
i.e. any build with the same native code. Testers see it on the next cold
start (it fetches in the background; fallbackToCacheTimeout: 0 keeps launch
instant, so killing + relaunching twice is how you confirm it applied).
A new binary is only required when native inputs changed: a dependency
add/upgrade, anything under app/patches/, a config plugin, or app.json's
ios/infoPlist/plugins sections. The fingerprint policy guarantees an OTA
can't land on a binary with mismatched native code, so you can't break a build
this way. Rule of thumb: ran npx expo install or touched patches/? → build a
binary. Otherwise → OTA. Full decision table + fingerprint debugging:
app/docs/RELEASE.md.
The rest of this skill is the binary path (native change, or a store release).
test cases passed, vs 12 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.