nostr-waitlist

Nostr Waitlist Skill

Scaffolds a polished email + Nostr "early access" flow into the host Next.js project. The output is opinionated about UX (Radix dialog, three-state form based on email vs npub vs NIP-05, confetti on success) and unopinionated about destinations — the user picks any combination of bundled adapters (Resend Audiences, webhook, Postgres, Supabase, SQLite) or writes their own satisfying the small Destination interface.

References

• references/nostr-keys.md — how to generate an nsec, what to put in env
• references/destination-adapters.md — the Destination interface + a worked example of a custom adapter
• references/db-schema.sql — canonical waitlist table for Postgres + SQLite
• references/nip-cheatsheet.md — quick recap of NIP-04 / NIP-05 / NIP-44

Phase 1 — Detect stack

Before asking the user anything, gather facts about the host project.

# Run from the project root the user is currently in
cat package.json | grep -E '"(next|react)"' || echo "NOT_NEXT"
ls app/ 2>/dev/null && echo "HAS_APP"
ls pages/api/ 2>/dev/null && echo "HAS_PAGES_API"
ls tsconfig.json 2>/dev/null && echo "HAS_TS"
ls tailwind.config.ts tailwind.config.js tailwind.config.mjs 2>/dev/null && echo "HAS_TAILWIND"
ls pnpm-lock.yaml yarn.lock package-lock.json bun.lockb 2>/dev/null
ls components/ui/dialog.tsx components/ui/button.tsx components/ui/input.tsx 2>/dev/null

Decide:

• NOT_NEXT → stop. Tell the user "this skill targets Next.js. Detected: ." and exit.
• HAS_APP present → use App Router templates (templates/api/app-router/).
• Only HAS_PAGES_API → use Pages Router templates.
• Both present → ask the user which to target (Modal vs section can also live in either; route handler placement is what matters).
• Package manager: pnpm-lock → pnpm, yarn.lock → yarn, package-lock.json → npm, bun.lockb → bun. Default npm if none found.
• shadcn primitives detected → set EMIT_UI = false. Otherwise EMIT_UI = true.