ns-notification - Push notifications for NowStack Mobile

SkillCommunication

Set up NowStack Mobile push notifications with Expo, Convex, EAS/APNs, settings, logs, admin tests, and iOS verification. Use for "notifications", "push", "ns notification", or misspellings like "ns-notifciation".

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the ns-notification - Push notifications for NowStack Mobile skill

What this skill tells your AI

The instructions your AI receives, as published by melvynx/saveit.now in .agents/skills/ns-notification/SKILL.md and read by ahel’s review.

This skill is based on a completed production notification rollout:

  • App ID was created with In-App Purchase, Sign in with Apple, and Push Notifications enabled.
  • Working code stored Expo push tokens per device, respected per-user/couple preferences, logged every delivery attempt, and exposed admin test sends.
  • The iOS release path needed an APNs push credential fix before TestFlight push delivery was reliable.

<first_steps>

  1. Read AGENTS.md.
  2. Read .agents/rules/mobile-app.md, .agents/rules/auth-payments-storage.md, .agents/rules/store-release.md, .agents/rules/verification.md, and .agents/rules/typescript-and-code-style.md.
  3. Before editing convex/**, read convex/_generated/ai/guidelines.md and .agents/rules/convex.md.
  4. Read at least one existing authenticated mobile layout, one Convex auth helper file, and one admin route before editing.
  5. For current Expo API details, use the find-docs skill against official Expo docs before changing library-specific calls.
  6. If iOS, App Store Connect, APNs, EAS credentials, entitlements, or TestFlight are involved, read references/ios.md. </first_steps>

<source_reference> This skill is derived from a completed notification rollout, but it must stay portable. Do not reference machine-specific absolute paths, private repo names, or private commit hashes. When implementing in the current repo, look for or create the equivalent local files:

mobile-app/lib/notifications.ts
mobile-app/app/(app)/_layout.tsx
mobile-app/app/(app)/notification-settings.tsx
convex/notifications/
convex/admin/notifications.ts
convex/crons.ts

</source_reference>

  1. Mobile client

    • Use expo-notifications and expo-constants.
    • Set a global notification handler so foreground notifications show a banner/list entry without noisy sound by default.
    • Request permission, create the Android channel before requesting/getting a token, and call Notifications.getExpoPushTokenAsync({ projectId }).
    • Resolve projectId from Constants.expoConfig?.extra?.eas?.projectId with Constants.easConfig?.projectId as fallback.
    • Register the token only after the user is authenticated; reset the one-shot guard on sign-out.
    • Register tap handling once in the authenticated app layout, including the cold-start response from getLastNotificationResponseAsync.
    • Route backend data hints like { type, route, reviewId, month } to real Expo Router paths including route groups.
  2. Convex schema

    • Add pushTokens: userId, token, platform, optional deviceId, optional disabledAt, createdAt, updatedAt.
    • Add notificationPreferences: userId, coupleId, a master pushEnabled, per-notification toggles, updatedAt.
    • Add notificationLogs: coupleId, recipientUserId, type, status, optional payload, optional error, optional sentAt, createdAt.
    • Index for exact access patterns: by token, by user, by user+token, by user+couple, by couple, by couple+status, by status.
  3. Convex API

    • Public authenticated mutation: register or reactivate a token by token string. If the token exists under another user, re-point it to the current user.
    • Public authenticated mutation: disable a token on sign-out or invalidation.
    • Public authenticated query/mutation: read and update the caller's preferences for their active couple.
    • Internal recipient helpers: load active couple members, effective preferences with defaults, and a bounded list of active tokens per user.
    • Internal action delivery: send through https://exp.host/--/api/v2/push/send, parse Expo tickets, classify accepted/rejected, and log every sent/failed/skipped attempt.
  4. Product triggers

    • Trigger notifications from product events, not from UI-only code.
    • Keep notification content privacy-safe. Do not expose raw private answers or sensitive user data; send status-only copy.
    • Typical triggers: cycle/check-in prompt, partner completion, missed action reminder, monthly review ready, AI/product nudge.
    • Use Convex scheduler/crons for recurring prompts and reminders. Keep batch sizes bounded.
  5. Admin diagnostics

    • Add admin queries for recent logs and recent users with active tokens.
    • Add an admin action to send a test notification to a selected active member.
    • In UI, show only token previews, never full Expo tokens.
    • Include sent/accepted/rejected/token-count result text so delivery failures are diagnosable.

<ios_gate> Read references/ios.md before any iOS credential or TestFlight work. The short version:

  • App Store Connect App ID must have Push Notifications enabled before provisioning profiles are generated.
  • EAS must have an APNs push key for the Apple team. This is separate from the distribution certificate and provisioning profile.
  • The app must have a real extra.eas.projectId; token registration should pass it explicitly to getExpoPushTokenAsync.
  • A dev build or TestFlight build is required. Expo Go is not a proof for this app.
  • Regenerate/reinstall iOS credentials if the App Store provisioning profile predates the Push Notifications capability. </ios_gate>
  1. Plan

    • List the mobile, Convex, admin, iOS credential, and verification changes.
    • Get explicit user confirmation before creating/changing external Apple/EAS resources, APNs keys, signing credentials, builds, uploads, or TestFlight sends.
  2. Implement

    • Keep code split cleanly: mobile helper, authenticated layout wiring, Convex notifications/ modules, admin diagnostics, product trigger call sites.
    • Run Convex codegen after schema/function changes.
    • Keep delivery in Convex actions, not mutations or queries, because actions can call external HTTP.
  3. Verify locally

    npm run check-setup
    npx convex dev --once
    cd mobile-app && npx tsc --noEmit
    cd mobile-app && npm run lint
    cd mobile-app && npx expo config --type public
    
  4. Verify iOS delivery

    • Use ns-ios-verification for simulator navigation/tap routing.
    • For real remote push delivery, use a dev build on a capable device/simulator or a TestFlight build with APNs credentials present.
    • Send an admin test notification and inspect notificationLogs for sent, failed, or skipped with the Expo ticket payload.

Signals

GitHub stars
31
Forks
5
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
ns-notification
Source
github.com/melvynx/saveit.now