# Platform Demo Architect > 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. - Skill: `joshuashepherd/platform-demo-architect` (Agent Skill) - Install (CLI): `npx skillmds@latest add joshuashepherd/platform-demo-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/joshuashepherd/platform-demo-architect/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: JoshuaShepherd (https://skillmd.com/u/joshuashepherd) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/joshuashepherd/platform-demo-architect --- 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.