product-showcase
The product-showcase skill generates a multi-page marketing website for web apps by automating screenshot capture, animated GIF creation, and content generation at three depth levels: quick single-page sites, standard multi-page layouts with features and workflows, or thorough comprehensive sites with per-feature pages and interactive demonstrations. Use this when launching a complex application, agentic AI tool, or product that requires showing actual functionality rather than static descriptions to communicate its value.
git clone --depth 1 https://github.com/jezweb/claude-skills /tmp/product-showcase && cp -r /tmp/product-showcase/plugins/frontend/skills/product-showcase ~/.claude/skills/product-showcaseSKILL.md
# Product Showcase Generator Generate a marketing website that actually teaches people what a web app does. Not just a hero and feature grid — a multi-page site with real screenshots, animated GIF walkthroughs of workflows, feature deep-dives, and progressive depth from "what is this" to "here's exactly how it works." Especially valuable for complex apps, agentic AI tools, and anything where a static screenshot doesn't convey the value. ## Depth Levels | Depth | Output | Duration | |-------|--------|----------| | **quick** | Single page — hero, features, CTA. Same as before. | 15-20 min | | **standard** | Multi-page site — home, features page, how-it-works with screenshots. | 1-2 hours | | **thorough** | Comprehensive site — home, per-feature pages, animated GIF walkthroughs, use cases, comparison page, docs-style demo. | 3-6 hours | Default: **standard** ## Browser Tool Detection Before starting, detect available browser tools: 1. **Chrome MCP** (`mcp__claude-in-chrome__*`) — preferred for authenticated apps 2. **Playwright MCP** (`mcp__plugin_playwright_playwright__*`) — for public apps 3. **playwright-cli** — for scripted flows ## Workflow ### 1. Gather Input | Field | Required | Example | |-------|----------|---------| | App URL | Yes | `https://app.example.com` or `http://localhost:5173` | | App name | Yes | "Acme CRM" | | Tagline | No | "The CRM that gets out of your way" | | Target audience | No | "Small business owners" | | Pricing info | No | Free tier, $29/mo pro | | CTA text + URL | No | "Start Free Trial" → signup page | | Testimonials | No | User provides or skip section | ### 2. Capture Screenshots Use `capture-screenshots` (shipped in `bin/`) to capture the app. This is faster and more consistent than generating Playwright scripts each time. #### Quick capture (all key pages at once): ```bash capture-screenshots http://localhost:5173 \ --pages /,/dashboard,/contacts,/settings \ --output showcase/screenshots \ --prefix screen \ --mobile --dark ``` This produces desktop (1280x720), mobile (375px), and dark mode variants for each page in one run. #### For authenticated apps: ```bash capture-screenshots https://app.example.com \ --pages /,/dashboard,/settings \ --auth user:password \ --output showcase/screenshots \ --mobile --dark ``` #### What to capture: **a. First Impression** — the main page/dashboard becomes the hero image. Note the immediate value proposition. **b. Features** — each major section. Use `--pages` with all nav paths. Capture 6-10 key screens that tell the product story. **c. "How It Works" flow** — the main workflow in sequence. Run `capture-screenshots` multiple times with `--prefix workflow-step` as you navigate through the flow steps. **d. Detail shots** — zoom into specific UI elements. Use `--full-page` for scrollable content. **e. Both modes** — `--dark` flag captures light and dark variants automatically. Use the best-looking mode for the hero. #### Post-capture optimisation: ```bash img-process batch showcase/screenshots --action optimise --max-width 1920 -o showcase/screenshots-opt ``` #### f. Extract the Value Propositions Don't just list features. For each one, answer: **why does the user care?** - BAD: "Contact management page" - GOOD: "See every client, their history, and what needs attention — in one view" - BAD: "Search functionality" - GOOD: "Find anything in seconds — semantic search understands what you mean, not just what you type" ### 3. Generate the Site #### Quick Mode: Single Page (same as before) One HTML file: hero + feature grid + CTA. Use for MVPs and quick marketing. #### Standard Mode: Multi-Page Site ``` showcase/ ├── index.html # Home — hero, overview, feature highlights, CTA ├── features.html # All features with screenshots and descriptions ├── how-it-works.html # Step-by-step workflow walkthrough with screenshots ├── screenshots/ # All captured images │ ├── hero.png │ ├── feature-*.png │ ├── workflow-step-*.png │ └── *.gif # Animated walkthroughs └── styles.css # Shared styles (or inline Tailwind CDN) ``` **Home page**: Hero with animated GIF or key screenshot, 3-4 feature highlights (not all features — just the best), "How It Works" summary (3 steps), CTA. **Features page**: Every feature with a real screenshot and benefit-focused description. Group by category if there are 6+. Each feature gets enough space to actually explain what it does. **How It Works page**: The primary workflow as a step-by-step visual guide. Each step has a screenshot (or animated GIF), a heading, and 2-3 sentences. This page answers "ok but what does using it actually look like?" #### Thorough Mode: Comprehensive Site ``` showcase/ ├── index.html # Home — hero, overview, value proposition ├── features/ │ ├── index.html # Feature overview grid │ ├── [feature-1].html # Deep-dive: one page per major feature │ ├── [feature-2].html # Each with screenshots, GIFs, use cases │ └── [feature-n].html ├── how-it-works.html # Full workflow walkthrough ├── use-cases/ │ ├── [use-case-1].html # Scenario: "A day in the life of..." │ └── [use-case-2].html # Scenario: "When a new client calls..." ├── compare.html # "Why [app] vs alternatives" (optional) ├── screenshots/ │ ├── hero.png │ ├── feature-*/ # Per-feature screenshot sets │ └── workflows/ # Animated GIFs └── styles.css ``` **Per-feature deep-dive pages**: Each major feature gets its own page with: - Hero screenshot of the feature in action - "What it does" — 1-2 paragraphs explaining the value - "How it works" — step-by-step with screenshots or GIF - "Why it matters" — the problem this solves - Edge cases or power-user tips - Link to next feature (flow between pages) **Use case pages**: Story-driven pages that show the app in a real scenario: - "It's Monday morning. You open the dashboard and see..
Hit the Cloudflare REST API directly for operations that wrangler and MCP can't handle well. Bulk DNS, custom hostnames, email routing, cache purge, WAF rules, redirect rules, zone settings, Worker routes, D1 cross-database queries, R2 bulk operations, KV bulk read/write, Vectorize queries, Queues, and fleet-wide resource audits. Produces curl commands or scripts. Triggers: 'cloudflare api', 'bulk dns', 'custom hostname', 'email routing', 'cache purge', 'waf rule', 'd1 query', 'r2 bucket', 'kv bulk', 'vectorize query', 'audit resources', 'fleet operation'.
Scaffold and deploy Cloudflare Workers with Hono routing, Vite plugin, and Static Assets. Describe project, scaffold structure, configure bindings, deploy. Use whenever the user wants to create a Worker project, set up Hono on Cloudflare, configure D1 / R2 / KV / Queues bindings, or troubleshoot Worker export syntax, API route conflicts, HMR issues, or deployment failures.
Generate Drizzle ORM schemas for Cloudflare D1 databases with correct D1-specific patterns. Produces schema files, migration commands, type exports, and DATABASE_SCHEMA.md documentation. Handles D1 quirks: foreign keys always enforced, no native BOOLEAN/DATETIME types, 100 bound parameter limit, JSON stored as TEXT. Use when creating a new database, adding tables, or scaffolding a D1 data layer.
Cloudflare D1 migration workflow: generate with Drizzle, inspect SQL for gotchas, apply to local and remote, fix stuck migrations, handle partial failures. Use when running migrations, fixing migration errors, or setting up D1 schemas.
Generate database seed scripts with realistic sample data. Reads Drizzle schemas or SQL migrations, respects foreign key ordering, produces idempotent TypeScript or SQL seed files. Handles D1 batch limits, unique constraints, and domain-appropriate data. Use when populating dev/demo/test databases. Triggers: 'seed database', 'seed data', 'sample data', 'populate database', 'db seed', 'test data', 'demo data', 'generate fixtures'.
Scaffold Hono API routes for Cloudflare Workers. Produces route files, middleware, typed bindings, Zod validation, error handling, and API_ENDPOINTS.md documentation. Use after a project is set up with cloudflare-worker-builder or vite-flare-starter, when you need to add API routes, create endpoints, or generate API documentation.
Build a full-stack TanStack Start app on Cloudflare Workers from scratch — SSR, file-based routing, server functions, D1+Drizzle, better-auth, Tailwind v4+shadcn/ui. Use whenever the user mentions TanStack Start, asks to scaffold a full-stack Cloudflare app with SSR, wants an SSR dashboard, or asks for a React 19 + Cloudflare Workers app with file-based routing and server functions — even if they don't name TanStack Start specifically. No template repo — Claude generates every file fresh per project.
Scaffold a full-stack Cloudflare app from the vite-flare-starter template — React 19 + Hono + D1+Drizzle + better-auth + Tailwind v4+shadcn/ui + TanStack Query + R2 + Workers AI. Run setup.sh to clone, configure, and deploy. Use whenever the user wants a batteries-included Cloudflare full-stack app, vite-flare-starter scaffold, or a React + Cloudflare app with auth + database + Workers AI ready to go.