Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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 table for Postgres + SQLite
waitlist
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 incat 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).
For every adapter chosen, emit its file but leave it commented out in
lib/waitlist/destinations.ts. The user uncomments + supplies env when
they're ready.
Prompt 4 — UI surface:
modal (default) / inline-section / both
Phase 3 — Install deps
Pick the right package manager command (pnpm add, npm install, yarn add,
bun add) and run one install with all packages — running multiple
installs back to back is slower and noisier.
The literal sentinel __YEAR__ (note: underscores, not braces) is not a
scaffold token — it stays in the rendered email template and is substituted
at runtime by lib/resend.ts so the copyright year stays fresh year over
year. Don't add it to your token map.
For component CSS variables, prefer arbitrary value classes
(bg-[var(--brand-primary)]) backed by CSS custom properties the skill
inserts into the user's globals.css (offer to insert; don't overwrite).
Each key gets a one-line # comment above it explaining where to get it.
Phase 5 — Wire trigger
If modal was chosen, point the user at where to mount <WaitlistTrigger />
or <WaitlistModal />. Don't auto-edit pages — show a 5-line snippet they
can paste into their hero/header. Suggest the obvious spot (header/hero CTA)
based on a quick grep for "early access", "get started", "join", or
similar copy in app/page.tsx or pages/index.tsx.
If inline-section was chosen, append (don't overwrite) a <WaitlistSection />
import + render to the most likely landing file, after asking
"insert into app/page.tsx after line N? (y/n)".
Phase 6 — Smoke test
Print:
Env-var checklist with where-to-get-it links per key emitted in Phase 4.
Optional dev-server check:
"want me to start the dev server and curl /api/waitlist/check? (y/n)"
if yes: pnpm dev background, wait 4s, curl -X POST localhost:3000/api/waitlist/check -H 'Content-Type: application/json' -d '{"contact":"test@example.com"}'
expect { "hasNip05": false } (a real NIP-05 like agus@nostrplebs.com
would return { "hasNip05": true })
Do not auto-call /api/waitlist/subscribe — that triggers real
Resend + relay traffic. Tell the user how to test it themselves with
their own email.
End with a one-paragraph "what's next": fill .env, mount the trigger,
run pnpm tsc --noEmit, deploy.
Notes for the agent running this skill
Don't overwrite files without diffing. If lib/nostr.ts already
exists, ask first.
Append, never replace in .env.example, globals.css, and any page
the user already authored.
If the user picks email-only, skip every Nostr file — including
lib/nostr.ts, the NIP-04 DM template, the npub/nip05 detection
branches in the modal. Ship a slimmer modal with a single email
field. (Source: templates/components/waitlist-modal.tsx.tpl has a
{{NOSTR_BRANCHES}} block that gets replaced with empty string when
Nostr is disabled.)
The Destination adapters are best-effort. Errors logged, never
thrown to the response. The user can change this in lib/waitlist/run.ts
if they want hard failures.
