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 skills/anilburcu/claude-code-react-native/supabase-mobile-authnpx skills add AnilBurcu/claude-code-react-native --skill supabase-mobile-authgit 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/supabase-mobile-auth)<a href="https://agentmods.dev/skills/anilburcu/claude-code-react-native/supabase-mobile-auth"><img src="https://agentmods.dev/badge/skills/anilburcu/claude-code-react-native/supabase-mobile-auth.svg" alt="Measured on agentmods" 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 | $0.00064 | $0.01107 |
| Opus 5 | $0.00032 | $0.00553 |
| Sonnet 5 | $0.00013 | $0.00221 |
| Haiku 4.5 | $0.00006 | $0.00111 |
Grade A, and why
supabase-mobile-auth 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 3d 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 — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Supabase in a mobile app, the parts the docs gloss over
Native sign-in beats browser redirects
On mobile, prefer token-based native flows over web OAuth redirects. The user stays in the app, there is no browser handoff to break, and no deep-link dance:
- Apple: the native Sign in with Apple sheet returns an identity token; pass it to
signInWithIdToken. Hash the nonce (SHA-256) into the Apple request and pass the raw nonce to Supabase, and remember Apple only returns the user's name on the FIRST authorization, so persist it immediately or lose it. - Google: the native Google sign-in SDK returns an id token for
signInWithIdToken. Check whether your chosen Google sign-in library supports a nonce parameter. Some do not, and then Supabase's nonce check fails; the "skip nonce check" switch in the Supabase dashboard exists for exactly that case. Prefer a nonce-capable library when starting fresh, and treat the skip switch as a documented tradeoff rather than a mystery setting. - Email: OTP codes (
signInWithOtpthenverifyOtp) avoid deep links entirely, which on mobile removes a whole class of "the magic link opened the wrong thing" support tickets.
With only native flows, no URL detection is needed: detectSessionInUrl: false, and deep-link handling stays out of the auth path entirely.
Session storage and refresh
- Supply an explicit storage adapter. Working choices: encrypted MMKV (fast, sturdy), AsyncStorage or an encrypted wrapper over it (Supabase's documented default), or SecureStore with care, since sessions are larger than what some iOS releases historically accepted per value.
- Refresh needs the app-state pattern: start auto-refresh when the app becomes active, stop it in the background. A refresh that fires while the app is suspended can rotate the token without persisting the result, and the next launch presents a stale refresh token, which trips refresh-token-reuse detection and signs the user out.
- Serialize concurrent refreshes. Two simultaneous
getSessioncalls both trying to refresh is another reuse-detection trigger; a simple in-process mutex around refresh ends it. - On sign-out, also clear the persisted session storage explicitly. Belt and suspenders, but a cached session resurrecting a signed-out account is a real bug class and clearing storage is one line.
- Copy-ready wiring for all of the above (storage adapter, refresh lifecycle, serial lock, fetch timeout) is in reference.md.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 3d ago First seen · 48 lines · 64 tokens per session scan A f477a1f8343c
supabase-mobile-auth is a skill published in the GitHub repository AnilBurcu/claude-code-react-native (3 stars, last pushed 1mo ago), licensed MIT. It adds 64 tokens to every session and 1,107 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-31.
Other skills, from other repositories
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…
expo-launchpad-evaluator
Phase A, step 6 — skeptical QA. Run the app, watch it, then judge against the contract. Default = functional check; --strict adds quality scoring and an edge-case sweep.
expo-launchpad-design
Phase A design — define the ui/designTokens.ts spec (colors, spacing, radius, typography), the visual/component concept (game: code-drawn Skia shapes / app: RN primitives), and the asset plan (icon+splash branding, contrast-safe accessibility). Advances pipeline state to contract.
expo-launchpad-plan
Phase A plan — assign app identity (appname/appslug/bundleid/orientation) into config.md, then write the PRD in defaultlanguage with a kind-branched structure (game: core loop/mechanics/content metrics/progression/win-lose; app: purpose/journeys/features/data model/navigation), plus a project structure map, and…
expo-launchpad-contract
Phase A contract — propose the 8 Mandatory Hard Gates, the Platform-Robustness Gates (R1–R11), and 5–10 Functional Criteria derived from the PRD; mark the contract AGREED (1-pass default, rigorous self-review in --strict) and advance the pipeline to generator.
expo-launchpad-research
Phase A research — kind-aware market/genre (game) or category/competitor (app) discovery, concept proposal via AskUserQuestion, a store clone-avoidance check (App Store 4.3 / Google Play impersonation), and the research spec write-up.