agentsclimarketplace

Rn module add

Skill lukedj78/dev-flow/rn-module-add

A filesystem contract (.workflow/meta.json) + 37 agent skills that take a product from idea to production: web (Next.js 16) & mobile (Expo/RN), plus an eve agent engine and Linear/scrum. Runs on Claude Code, Codex, Copilot, Gemini, Cursor.

Install
npx -y skills add lukedj78/dev-flow --skill rn-module-add

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use to wire a backend/infra module (auth, db, storage, realtime, push, payments) into a scaffolded Expo + RN app. Reads .workflow/meta.json with stack.framework="expo-rn" and the user-chosen provider for each module (Supabase, Firebase, custom REST, tRPC, RevenueCat). Installs deps, generates the wiring code (lib/auth.ts, lib/supabase.ts, etc.), updates meta.json#stack to record the choice. Always idempotent. Triggers on: "add auth", "wire up db", "set up Supabase", "set up Firebase", "add payments", "add push" (the server-side part), "aggiungi modulo X". Not for: building UI for the module (rn-add-screen does the login screen, etc.), client-side knowledge only (rn-backend, rn-push-notifications), scaffolding (rn-bootstrap).

SKILL.md

10.9 KB, ~2.8k tokens by cl100k_base, as published. Nobody here has run it

rn-module-add — wire a backend/infra module into a scaffolded RN app

Contract

See references/contracts.md (vendored from dev-flow). Key facts:

  • Reads <project-root>/.workflow/meta.json#stack.framework — must be "expo-rn".
  • Requires meta.json#phase ≥ "scaffolded".
  • Each module updates a specific key in meta.json#stack:
    • auth module → meta.json#stack.auth
    • db module → meta.json#stack.db
    • storage module → meta.json#stack.storage (new sub-key)
    • realtime module → meta.json#stack.realtime (new sub-key)
    • push module → meta.json#stack.push (new sub-key)
    • payments module → meta.json#stack.payments
  • Sets meta.json#phase = "module_added" after the first module, then leaves it.
  • Always idempotent: re-running with same provider detects existing wiring and exits 0.

When this skill applies

  • Phase is scaffolded or page_generated or module_added.
  • User asks to add ONE module by name. (To add multiple, run the skill multiple times.)
  • Orchestrator routes here from dev-flow.

Knowledge dependencies (read these first)

  • rn-fundamentals/SKILL.md — TypeScript strict, modern primitives.
  • rn-backend/SKILL.md — provider-agnostic client-auth architecture.
  • rn-backend/references/<provider>.md — provider-specific wiring (supabase.md / firebase.md / custom-rest.md / trpc.md).
  • rn-push-notifications/references/setup.md — for the push module.
  • rn-publishing-payments/references/revenuecat.md — for the payments module.

Monorepo awareness

Before Step 1: check meta.json#stack.framework.

  • If "expo-rn" (mobile-only project): proceed normally, operate at project root.
  • If "monorepo": this skill operates inside apps/mobile/ for mobile-specific modules (push, RevenueCat, expo-image-picker), AND inside packages/api/ for modules shared with web (auth, db, storage, realtime). For shared modules, do NOT re-install the SDK if packages/api/ already has it from a prior module-add (web side) call. Run monorepo-sync-types after db and auth are wired.
  • If anything else: refuse — use module-add (web stacks) or monorepo-bootstrap (greenfield monorepo).

For the monorepo case, "install + generate" means: install npm packages into the appropriate workspace (pnpm add --filter @<slug>/mobile for mobile-specific, pnpm add --filter @<slug>/api for shared backend client), and generate code into the right sub-folder. The reference paths below all reference apps/mobile/ instead of project root.

Workflow

Step 1 — Verify preconditions

Read .workflow/meta.json. Abort if stack.framework ∉ {"expo-rn", "monorepo"} or phase < "scaffolded".

If stack.framework == "monorepo", all subsequent file paths are relative to apps/mobile/ (e.g. apps/mobile/lib/auth.ts) or packages/api/src/ (e.g. packages/api/src/auth.ts). Honor the workspace conventions.

Step 2 — Identify the module + provider

Module the user requested: one of auth | db | storage | realtime | push | payments.

If the user didn't specify a provider, default to:

  • auth, db, storage, realtimeSupabase (the default in rn-backend/references/decision-tree.md).
  • pushexpo-notifications + Expo push service (the default).
  • paymentsRevenueCat (the default).

If the user specifies a non-default provider, accept it: Firebase / custom-rest / tRPC for backend; Stripe for non-digital payments.

Step 3 — Idempotency check

Read meta.json#stack.<module-key>. If non-null:

  • Same provider as requested → "Already wired with X, exiting." Phase stays.
  • Different provider → REFUSE unless user passed an explicit "swap" intent. Removing one provider's code + installing another's is a multi-file change that needs explicit user confirmation. Report and stop.

Step 4 — Install deps

Use npx expo install ... -- --legacy-peer-deps for any package that touches native (auth, db SDKs, payments). Use npm install --legacy-peer-deps for JS-only packages.

Provider matrix:

ModuleSupabaseFirebaseCustom RESTtRPC
auth@supabase/supabase-js, react-native-url-polyfill, expo-secure-store@react-native-firebase/{app,auth}, expo-build-properties(uses existing lib/api.ts) + expo-secure-store@trpc/client, @trpc/react-query, superjson
db(same as auth)@react-native-firebase/firestore(uses lib/api.ts)(uses tRPC)
storage(uses @supabase/supabase-js)@react-native-firebase/storageexpo-file-system + custom upload(uses tRPC or REST)
realtime(uses @supabase/supabase-js)(uses @react-native-firebase/firestore)(WebSocket of your choice)(tRPC subscriptions)
pushexpo-notifications, expo-device(same + @react-native-firebase/messaging)(same; server-side uses your backend)(same)
paymentsreact-native-purchases (RevenueCat)(same)(same)(same)

Step 5 — Generate the wiring

For each (module, provider) combination, write to <project-root>/lib/:

  • auth/Supabaselib/supabase.ts (client) + lib/auth.ts (sign-in/out hooks). See rn-backend/references/supabase.md.
  • auth/Firebaselib/firebase.ts + lib/auth.ts. See rn-backend/references/firebase.md.
  • auth/custom-restlib/api.ts (already exists from rn-bootstrap, extend with refresh-on-401) + lib/auth.ts. See rn-backend/references/custom-rest.md.
  • auth/tRPClib/trpc.ts + lib/auth.ts. See rn-backend/references/trpc.md.
  • payments/RevenueCatlib/purchases.ts + hooks/usePro.ts. See rn-publishing-payments/references/revenuecat.md.
  • push/expo-notificationslib/push.ts + edits to app/_layout.tsx (handlers + permissions). See rn-push-notifications/references/patterns.md.

ALWAYS also create store/auth.ts (Zustand) and ensure app/(app)/_layout.tsx redirects when unauthenticated — see rn-backend/references/patterns.md.

Step 6 — Update .env.example + app.json

Per provider, add the env vars to .env.example:

  • Supabase: EXPO_PUBLIC_SUPABASE_URL=, EXPO_PUBLIC_SUPABASE_ANON_KEY=
  • Firebase: requires GoogleService-Info.plist + google-services.json at root (manual download from Firebase console).
  • Custom REST: EXPO_PUBLIC_API_URL=
  • tRPC: EXPO_PUBLIC_API_URL=
  • RevenueCat: EXPO_PUBLIC_REVENUECAT_IOS_KEY=, EXPO_PUBLIC_REVENUECAT_ANDROID_KEY=

For Firebase or RevenueCat or push notifications, add the relevant app.json config plugin entries (see provider-specific reference).

Step 7 — Verify

Run npx tsc --noEmit. Must pass. If not, fix the wiring before reporting.

For modules with native config plugin changes (Firebase, push), the next build will require a new eas build --profile development. Print a reminder.

Step 8 — Update meta.json + commit

Update meta.json:

  • stack.<module>: set to the provider name (e.g. "supabase", "firebase", "custom-rest", "trpc", "revenuecat", "stripe", "expo-notifications").
  • phase: if currently "scaffolded" or "page_generated", set to "module_added". Otherwise leave.
  • history: append { skill: "rn-module-add", ran_at: <iso>, inputs: { module, provider }, outputs: [<files>], phase_before, phase_after }.

If git repo: git add the new files + git commit -m "feat(<module>): wire <provider>".

Common anti-patterns (NEVER do)

  • ❌ Wire two providers for the same module simultaneously (e.g. Supabase + Firebase auth) — pick one.
  • ❌ Skip the stack.<module> update in meta.json — future re-runs will re-install.
  • ❌ Hardcode secrets in lib/*.ts — read from process.env.EXPO_PUBLIC_*.
  • ❌ Generate wiring without running tsc --noEmit — broken project shipped to user.
  • ❌ Add a module that requires a new dev build without printing the "rebuild required" reminder.
  • ❌ Use npm install without --legacy-peer-deps — fails on unsupported/older Expo SDK versions due to peer-range mismatches (see rn-bootstrap lessons-learned).

Updating meta.json (recommended pattern)

When this skill modifies state (artifact written, phase advanced, history appended), use the canonical script when available:

# Wherever dev-flow is installed (e.g. ~/.claude/skills/dev-flow/), invoke:
python3 .../dev-flow/scripts/update_meta.py <project-root> record-artifact \
    --path <relative-path> --produced-by '<this-skill-name>' [--derived-from <p1> <p2> ...]
python3 .../dev-flow/scripts/update_meta.py <project-root> set-phase <new_phase>
python3 .../dev-flow/scripts/update_meta.py <project-root> append-history \
    --skill '<this-skill-name>' --inputs '{...}' --outputs '{...}' --phase-after <new_phase>

The script enforces phase monotonicity, normalizes legacy kebab-case aliases (e.g. module-addedmodule_added), and writes the canonical sha256 + timestamp into meta.json#artifacts. Fall back to direct JSON editing only if the script is not on PATH (and warn the user).

Folder structure rules (canonical)

When wiring a module for RN/Expo, respect the canonical structure (spec: docs/superpowers/specs/2026-06-06-folder-structure-refactor.md):

  • auth module: client (supabase.ts / firebase.ts) → lib/. Secure-store wrapper → lib/secure-store.ts. Auth store → store/auth-store.ts. UI (SignInForm, SignUpForm) → app/(auth)/_components/.
  • db module: client wiring co-located with auth (lib/). Query hooks → app/<route>/_components/use<X>.ts initially, promoted to components/shared/<dominio>/hooks/ as they spread.
  • storage module: client in lib/storage.ts. Image-picker UI co-located with the screen.
  • realtime module: subscriptions wired in screens or in store/ if cross-feature.
  • push module: lib/push.ts + handlers in app/_layout.tsx.
  • payments module: client in lib/purchases.ts. Paywall UI in app/(app)/paywall/_components/. Pro gating hook → hooks/use-pro.ts.

For monorepo (stack.framework="monorepo"): backend client (auth/db/storage/realtime) goes in packages/api/ and is consumed via @<slug>/api/* workspace import.

Sources

  • Course: codewithbeto.dev/rnCourse — Backend Basics + Supabase + Publishing/Payments modules (paid).
  • Knowledge skills consumed (see above).

What ships with it: 4 files

36.9 KB alongside SKILL.md

Keep looking

Skills are one crate of 327,132. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.