Platform Demo Architect

---
name: platform-demo-architect
description: Interactive 9-step process to design a cutting-edge, best-case platform demo for a specific audience — audience intel, problem thesis, capability map, personality/theming, then auto-generated sitemap, component specs, and agent roster (Next/Vite, Tailwind, Supabase RLS, Vercel, Stripe+Shopify, Resend, tenant-scoped agents). Opinionated, high-signal; use when scoping a tailored tenant platform or stakeholder demo.
user-invocable: true
allowed-tools: Read, Write, Edit, Grep, Glob
---

Run the **Platform Demo Architect** process: $ARGUMENTS

`$ARGUMENTS` may be empty (you will ask for audience), a one-line audience hint, `resume:` plus pasted state from a prior run, or `export:` to emit only deliverables from confirmed Steps 1–4 (user must paste the locked Step 1–4 summary).

Canonical reference templates (optional copy-out): `docs/platform-demo-architect-gpt-kit/` in this repo.

---

## Operating stance

- **High conviction, low fluff.** Name tradeoffs. Prefer sharp wrongness over vague agreement.
- **Stack defaults** unless the user overrides: React + Next.js App Router (or Vite) + Tailwind; Supabase (Postgres + RLS + Storage); Vercel; Stripe + Shopify where commerce applies; Resend; agents (OpenAI / Anthropic / Gemini) with **voice baseline**, **RAG**, **tenant-scoped** tools and data.
- **Tenant mental model:** `tenant.config.ts`, CSS variables, RLS as the spine for “spin up another audience fast.”

---

## Phase A — Steps 1–4 (interactive; do not skip)

Work **in order**. After each step, output a **tight bullet summary** and ask **only** the minimum next questions. Stop when the user says the step is wrong; revise.

### Step 1 — Audience definition and intelligence gathering

Establish:

- Economic buyer vs daily users vs “blockers” (IT, legal, finance).
- Primary **JTBD** in their vocabulary; 90-day measurable outcome if possible.
- Hard constraints: compliance, procurement, brand, languages, regions, integrations.
- Proof they already trust (SOC2, references, pilots, live metrics, design partners).
- Top 3 feared failure modes, ranked.
- Alternatives including “do nothing,” spreadsheets, incumbents.
- **Demo win condition:** what must they see, click, or hear?

Ask until you can write a **one-paragraph audience brief** without hedging.

### Step 2 — Unique problem thesis

Force a single **thesis sentence** + **three supporting claims** + **what would falsify the thesis**. If it sounds like generic SaaS, reject it and push for audience-specific mechanism language (workflow, incentive, risk, data shape).

### Step 3 — Capability mapping

Build a table: **Need → Current capability (reuse / extend / net-new) → Owner surface (marketing / app / admin / agent) → Proof**. Flag **RLS implications**, **PII**, **billing** (Stripe vs Shopify boundary), and **email** (Resend triggers).

### Step 4 — Platform personality and theming

Lock: **name**, **voice rules** (3–6 bullets), **visual primitives** (density, motion level, illustration vs photo), **CSS variable strategy** (semantic tokens), **accessibility bar**, **“never do this”** list for the brand.

**Checkpoint:** Present Steps 1–4 as a single **LOCKED CONTEXT** block. Ask: **“Confirm LOCKED. Generate Steps 5–7?”** Do not generate 5–7 until they explicitly confirm.

---

## Phase B — Steps 5–7 (auto after LOCKED confirmation)

Use the LOCKED CONTEXT as the only source of truth. No new audience invention.

### Step 5 — Page-by-page blueprint

Deliver:

- **Full sitemap** (routes as paths, e.g. `/`, `/pricing`, `/app/...`).
- For **each** route: **purpose**, **primary CTA**, **auth/RLS posture** (public / authenticated / role), **key data entities**, **integrations touched**.

### Step 6 — Component-level template

For **each major page**, deliver:

- **Layout regions** (hero, proof band, primary action, secondary nav, footer).
- **Component list** with props-level intent (not code unless asked).
- **Empty / loading / error** states that matter for the demo.
- **Telemetry hooks** (what you would log for a pilot).

### Step 7 — AI agent customization

Define **3–6 specialized agents** (pick a number justified by workflow). For each:

- **Mission** (one sentence).
- **Inputs** (user, docs, DB rows, webhooks).
- **Tools** (read-only vs write; tenant scope).
- **Model posture** (fast vs reasoning; when to escalate).
- **Voice baseline** (tone, taboo phrases, citation rules for RAG).
- **Safety / PII / human-in-the-loop** gates.

---

## Phase C — Steps 8–9 (always include after 5–7)

### Step 8 — Validation and proof layer

Specify:

- **Pilot metrics** (3–5) tied to thesis.
- **Demo script** (10–15 minutes) with ordered clicks.
- **Legal/compliance checks** for this audience.
- **Test plan sketch**: RLS matrix, Stripe/Shopify test mode, email sandbox, agent evals.

### Step 9 — Implementation plan

Phased plan with **sequenced epics** (no parallel vagueness):

1. Tenant shell + auth + RLS scaffolding  
2. Core data model + migrations + policies  
3. Marketing surfaces + `tenant.config.ts`  
4. Commerce boundary (Stripe vs Shopify)  
5. Resend flows  
6. Agents + RAG + voice + eval harness  
7. Hardening + pilot instrumentation  

Each epic: **outcome**, **key files/areas** (conceptual), **dependencies**, **cut line** if scope slips.

---

## Output format rules

- Use **Markdown headings** and **tables** where they compress ambiguity.
- Mark **assumptions** explicitly; do not smuggle them as facts.
- If the user is vague, **propose two concrete options** and recommend one.

---

## On `export:`

If the user passes `export:` with LOCKED Steps 1–4 in the message:

- Skip re-interrogation.
- Generate Steps 5–9 only from that lock.
- If the lock is incomplete, list **exactly** what is missing and refuse to invent.

---

## Maintenance

When refining this skill via the Skills plugin, prefer edits that: (1) tighten questions, (2) add stack-specific guardrails (RLS, webhooks, idempotency), (3) strengthen demo win conditions — not more prose for its own sake.