website-stinger

name

website-stinger

description

Builds production-grade SvelteKit (Svelte 5) + Payload CMS + Supabase websites end-to-end from a brief, applying a 12-phase playbook. Default CMS mode is Payload 3.x (self-hosted Next.js on Vercel, consumed via REST from SvelteKit). Fallback CMS mode is TypeScript-as-CMS for one-page lead-gen sites that skip Payload. Trigger on phrases like \\\"build a website\\\", \\\"scaffold a SvelteKit site\\\", \\\"spin up a marketing site\\\", \\\"build me a lead-gen site\\\", \\\"ship a website from scratch\\\", \\\"create a SvelteKit + Supabase site\\\", or whenever the paired `website-worker-bee` Bee is invoked. Do not trigger for one-off page tweaks, copy edits, or deploy-only tasks.

Website Stinger

Equips website-worker-bee to take a brief and produce a working SvelteKit (Svelte 5) + Payload CMS + Supabase monorepo in roughly 45 minutes. The default architecture is:

• apps/web: SvelteKit 5 public site (Vercel)
• apps/cms: Next.js + Payload 3.x admin + REST API (separate Vercel project)
• Supabase Postgres: dual purpose: Payload's content store (in payload schema) + business data (in public schema)

The TypeScript-as-CMS fallback (no Payload, no apps/cms) is available for one-page lead-gen sites where blog/content management is not required.

This skill is predominantly autonomous by design. The Bee batches clarifying questions at the start, then executes phase by phase with smoke checks and commits.

---

When to use

• "Build me a marketing site for a B2B product."
• "Scaffold a SvelteKit + Supabase site with a blog."
• "Spin up a one-page lead-capture site."
• "Take this brand kit and ship a site by EOD."

Do not invoke for: one-page copy tweaks, Lighthouse audits on existing sites, deploy-only requests, or pure design exploration.

---

CMS mode selection

The inputs round (Step 2) asks: "Does this site need a managed CMS admin panel with blog/content management?"

Answer	Mode	Phases affected
Yes (default)	Payload mode: scaffold apps/cms, use Payload Collections for blog/pages, Phase 7 = Payload Admin	Phases 1 (three-app monorepo), 7 (Payload Admin), 9 (Payload blog)
No (fallback)	TypeScript-as-CMS: no apps/cms, blog posts are TypeScript data objects, no admin SPA	Phase 7 skipped, Phase 9 uses static TypeScript data

Document the choice in the Build Report (Inputs section) and in the Phase 1 commit message.

---

Procedure

1. Read guides/00-principles.md first. It encodes the architectural commitments that downstream phases depend on.
2. Collect inputs in one batched round. Use templates/inputs-checklist.md. Include the CMS-mode question. Surface architectural consequences of any phase opt-out before scaffolding.
3. Initialize the Build Report. Copy templates/build-report.md into the target repo as build-report.md and fill the Inputs section.
4. Execute phases in canonical order: 1 → 2 → 5 → 6 → 7 → 3 → 4 → 8 → 9 → 10 → 12 → 11. For each phase: read guides/0N-<topic>.md, glance at the source PRD in research/source-prds/, apply the changes, run the smoke check, update the Build Report row, commit with feat(phase-N): <name>.
5. Skip honestly. When the brief opts out of a phase, mark it skip with a one-line rationale. Never silently downgrade.
6. Walk Risks and Open Questions from the source PRDs into the Build Report's Next steps section.
7. Final pass. Read the Build Report end to end. Anything that reads as "I forgot why I did that" gets the PRD citation now, not later.

See guides/13-build-report.md for the report-authoring discipline.

---

Critical directives

• Always read this SKILL.md and guides/00-principles.md before any file write. Architectural commitments are load-bearing.
• Never deploy secrets, run destructive SQL on shared Supabase projects, or trigger production builds without explicit user confirmation.
• Cite the phase number and the specific PRD section in every commit message and Build Report row.
• When a phase's acceptance criterion cannot be met, mark it Skip with a rationale, never fudge.
• Honor the canonical reading order (1 → 2 → 5 → 6 → 7 → 3 → 4 → 8 → 9 → 10 → 12 → 11).
• Never overwrite a non-empty target directory without confirmation.
• Surface every Risk (R-N) and Open Question (Q-N) from the source PRDs in the Build Report's Next steps.

Full rationale lives in guides/00-principles.md.

---

Guides

• guides/00-principles.md: scope, architectural commitments, CMS-mode toggle, canonical phase order, critical directives
• guides/01-monorepo.md: Phase 1: pnpm workspaces + apps/web (SvelteKit) + apps/cms (Payload) + Vercel
• guides/02-performance-security.md: Phase 2: svelte.config.js, @sveltejs/enhanced-img, hooks.server.ts headers, fontsource
• guides/03-seo-aeo.md: Phase 3: delegates to seo-aeo-worker-bee (SvelteKit track); sitemap coordination with Payload
• guides/04-analytics.md: Phase 4: @vercel/analytics, GA4, Web Vitals in +layout.svelte, attribution store
• guides/05-supabase.md: Phase 5: schema, RLS, dual Postgres namespace, hooks.server.ts client, generated types
• guides/06-auth.md: Phase 6: Supabase Auth (end-users) + Payload Auth (CMS editors), hooks.server.ts route guard
• guides/07-admin-payload.md: Phase 7: Payload admin setup, Collections, Globals, CORS, role/access config
• guides/08-lead-capture.md: Phase 8: SvelteKit form actions, superforms + Zod, attribution, Supabase insert
• guides/09-blog.md: Phase 9: Payload-default (Collections + Blocks) or TypeScript-as-CMS fallback
• guides/10-webhooks.md: Phase 10: +server.ts event endpoints + Payload afterChange hooks + HMAC retry
• guides/11-cro.md: Phase 11: hero structure, form mechanics, mobile, A/B scaffold (Svelte component patterns)
• guides/12-visual-design.md: Phase 12: tokens, Tailwind v4, shadcn-svelte, svelte/transition, mode-watcher, Svelte animation libraries
• guides/13-build-report.md: Build Report authoring discipline

Examples

• examples/example-happy-path-full-build.md: full 12/12 build with Payload CMS (ClearDeck B2B legal-tech)
• examples/example-edge-case-skip-blog.md: one-page SvelteKit lead-gen site (TypeScript-as-CMS fallback, no Payload)

Templates

• templates/build-report.md: the deliverable shape this skill produces
• templates/inputs-checklist.md: pre-scaffold input gathering (includes CMS-mode question)
• templates/generateSEO.svelte.ts: SvelteKit +page.ts metadata helper (PUBLIC_* env)
• templates/design-tokens.css: Phase 12 CSS custom property token block stub
• templates/app-settings-seed.sql: initial app_settings rows
• templates/rls-policy-skeleton.sql: Phase 5 RLS baseline + Payload schema isolation comment

Research

• research/research-plan.md: source list, PRD-to-guide mapping, SvelteKit + Payload + animation sources
• research/README.md: index and pointer to website-stinger/research/ for Payload-specific deep research
• research/source-prds/: the canonical 12-phase guide bundled as source PRDs

---

Paired Bee: .cursor/agents/website-worker-bee.md