create-site

Plugin check: Run node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js" — if it outputs a message, show it to the user before proceeding.

Create Power Pages Code Site

Guide the user through creating a complete, production-quality Power Pages code site from initial concept to deployed site. Follow a systematic approach: discover requirements, scaffold and launch immediately, plan components and design, implement with design applied, validate, review, and deploy.

Core Principles

• Use best judgement for design details: Once the user picks an aesthetic direction and mood, make confident decisions about specific fonts, colors, page layouts, and component behavior. Do not ask the user to specify every detail — use the design reference and your own taste to make creative, distinctive choices.
• Use TaskCreate/TaskUpdate: Track all progress throughout all phases — create the todo list upfront with all phases before starting any work.
• Scaffold early, design with intention: Get the dev server running immediately after discovery so the user has something to look at. Then plan the design and features while the scaffold is live — apply the chosen aesthetic during implementation.
• Live preview feedback loop: The dev server MUST be running before any customization begins. Browse the site via Playwright (browser_navigate + browser_snapshot) to verify every significant change. Do NOT take screenshots — only use accessibility snapshots to check page structure and content.
• Keep the scaffold loader in sync with reality: The scaffold loader polls public/scaffold-status.json. Update this file before every AskUserQuestion (to raise the "waiting for your input" banner so the user doesn't miss a terminal prompt) and before each implementation step in Phase 5 (so the progress-bar label matches what you're actually doing while the decorative spinner continues its default cycle). See [Live Preview Status Protocol](#live-preview-status-protocol).
• Use real images: Source high-quality photos from Unsplash wherever pages need visual content — hero sections, feature cards, about pages, backgrounds, etc. Use https://images.unsplash.com/photo-{id}?w={width}&h={height}&fit=crop URLs with specific photo IDs found via WebSearch. Never leave image placeholders or broken <img> tags pointing to nonexistent files.
• Git checkpoints: Commit after every individual page and component — each gets its own commit so breaking changes can be reverted.

Constraint: Only static SPA frameworks are supported (React, Vue, Angular, Astro). NOT supported: Next.js, Nuxt.js, Remix, SvelteKit, Liquid.

Initial request: $ARGUMENTS

Live Preview Status Protocol

While the scaffold loading screen is visible (from Phase 2.6 until the Home page itself is replaced in Phase 5), the loader polls GET /scaffold-status.json every 1.5 seconds. The message you write into <PROJECT_ROOT>/public/scaffold-status.json appears as the label under the progress bar, and awaitingInput controls the "waiting for your input" banner. The decorative spinner above the progress bar continues its built-in phrase cycle; keep the progress-bar label current so the loader still reflects what is actually happening.

Why this matters: When the browser with the loader takes over the user's screen, a prompt in the terminal can sit unanswered for a long time because the user doesn't realize anything is waiting. The banner makes it obvious.

File shape (all fields optional — omit any field you don't want to change):

{
  "message": "Creating Contact page",
  "awaitingInput": false,
  "inputPrompt": "Please check your terminal to respond."
}

• message — one short present-participle phrase shown as the status line under the progress bar in the loader (replacing the default "Getting started…" / "Setting up infrastructure…" cycle). Include the grouping context inline when it helps (e.g., "Creating Footer component (shared components)").
• awaitingInput — when true, a prominent pulsing banner appears at the top of the loader and stays visible until this field is cleared. Set this before every AskUserQuestion call and clear it (false) immediately after the user answers.
• inputPrompt — short context for the banner (e.g., "Choose a framework"). Optional.

When to update the file:

1. After scaffold launches (end of Phase 2): write an initial status like { "message": "Planning your site", "awaitingInput": false }.
2. Before any AskUserQuestion that runs while the scaffold is visible (Phases 3, 4, and any in-scaffold prompt in Phase 5): set awaitingInput: true with a short inputPrompt. After the user answers, write again with awaitingInput: false.
3. Before each implementation step in Phase 5 — applying design tokens, creating each shared component, creating each page, updating the router, updating navigation — update message to the specific action. Examples: "Applying design tokens", "Creating Navbar component", "Creating Contact page".
4. At the end of Phase 5, after the Home page has been replaced: delete public/scaffold-status.json so it isn't deployed with the site.

Write the file with the Write tool (atomic overwrite). You do not need to read it first.

Phase 1: Discovery

Goal: Understand what site needs to be built and what problem it solves

Actions:

1. Create todo list with all 8 phases (see [Progress Tracking](#progress-tracking) table)
2. If site purpose is clear from arguments:
3. Summarize understanding
4. Identify site type (portal, dashboard, landing page, blog, etc.)
5. If site purpose is unclear, use AskUserQuestion:

| Question | Header | Options | |----------|--------|---------| | What should the site be called? (e.g., "Contoso Portal", "HR Dashboard") | Site Name | (free text — use a single generic option so the user types a custom name via "Other") | | Which frontend framework? | Framework | React (Recommended), Vue, Angular, Astro | | What is the site's purpose? | Purpose | Company Portal, Blog/Content, Dashboard, Landing Page | | Who is the target audience? | Audience | Internal (employees, partners), External (public-facing customers) | | Where should the project be created? | Location | Current directory, New folder in current directory (Recommended), Any other directory |

1. Resolve the project location:
2. If "Current directory": Project root = <cwd>.
3. If "New folder in current directory": Create a folder named __SITE_NAME__ inside the cwd. Project root = <cwd>/__SITE_NAME__/.
4. If "Any other directory": Ask for the full path. Verify/create it. Project root = provided path.

After resolving, confirm: "The site will be created at <resolved path>."

Store this as PROJECT_ROOT.

1. From the user's answers, derive:
2. __SITE_NAME__ (Title Case, e.g., Contoso Portal)
3. __SITE_SLUG__ (kebab-case derived from site name, e.g., contoso-portal)
4. __SITE_DESCRIPTION__ (one-line description based on name + purpose)
5. Summarize understanding and confirm with user before proceeding

Audience influences site generation:

• Internal: Prioritize data tables, dashboards, authentication, navigation depth, functional over flashy design
• External: Prioritize landing page appeal, SEO-friendly structure, contact forms, clean marketing-oriented layout

Output: Clear statement of site purpose, framework, audience, derived naming values, and project location

Phase 2: Scaffold & Launch Dev Server

Goal: Get a running site immediately so the user has something to preview while features and design are planned

The scaffold is a temporary branded loading screen — it shows a Power Pages animated "Building your site" experience with orbiting elements, status messages, and feature cards. Its only purpose is to get the dev server running quickly so t