---

name: create-site description: >- Creates a new Power Pages code site (SPA) from a curated template or from scratch using React, Angular, Vue, or Astro. Guides through the full process from initial concept to deployed site: requirements discovery, template selection or scaffolding, component planning, design, implementation, validation, and deployment. Use when the user wants to create, build, use a template for, or scaffold a new Power Pages website or portal. user-invocable: true argument-hint: Optional site description allowed-tools: Read, Write, Edit, Grep, Glob, Bash, WebSearch, AskUserQuestion, Task, TaskCreate, TaskUpdate, TaskList, mcp__plugin_power-pages_playwright__browser_navigate, mcp__plugin_power-pages_playwright__browser_snapshot, mcp__plugin_power-pages_playwright__browser_click model: opus

Plugin check: Run node "${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 path-agnostic upfront tasks first, then append branch-specific tasks after the creation path is selected.
• 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.
• 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

<!-- not-a-gate: prose-only section — mentions of `AskUserQuestion` here describe the live-status protocol that wraps every real prompt in Phases 3/4/8; the actual gates are catalogued in §6.13 of references/approval-gates.md and marked at their call sites below -->

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:

<!-- gate: create-site:1.purpose | category=plan | cancel-leaves=nothing -->

🚦 Gate (plan · create-site:1.purpose): Path-agnostic discovery prompt collecting site name, purpose, and audience. Determines what kind of site the user needs before the skill decides between a template-backed path and the from-scratch scaffold path. Fires only on the "site purpose unclear" branch (step 3 below).

Trigger: Phase 1 when site name, purpose, or audience was not provided in $ARGUMENTS. Why we ask: Wrong purpose/audience context → wrong branch decision and wrong generated site plan; cleanup is annoying. Cancel leaves: Nothing — no scaffolding has started yet.

1. Create the minimal upfront todo list (see Progress Tracking):

   • Discover site requirements
   • Select template or choose from-scratch

2. If site name, purpose, and audience are clear from arguments:

   • Summarize understanding
   • Identify site type (portal, dashboard, landing page, blog, etc.)

3. If site name, purpose, or audience 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") | | 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) |

4. From the user's answers, derive:

   • __SITE_NAME__ (Title Case, e.g., Contoso Portal)
   • __SITE_SLUG__ (kebab-case derived from site name, e.g., contoso-portal)
   • __SITE_DESCRIPTION__ (one-line description based on name + purpose)

5. Summarize the path-agnostic understanding and confirm with user before proceeding:

   • Site name
   • Site purpose/type
   • Target audience

   Do not ask for framework or project location in Phase 1. Each creation path asks for its location after Phase 1.5 selects that path.

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, audience, and derived naming values.

---

Phase 1.5: Template Branch Decision

Goal: Route the user into the appropriate creation path after path-agnostic Discovery.

Current implementation state: Template discovery, selection, supporting-solution import, packaged SPA cloning/upload, optional seed data, activation, live-site preview, and terminal telemetry are implemented for kind: "spa". Traditional catalog entries are accepted but not shown until their solution-only provisioning flow is implemented. The user can always choose Start from scratch to continue into the existing scaffold flow.

Actions:

1. Mark Select template or choose from-scratch as in_progress.

2. Fetch the template catalog:

   node "${PLUGIN_ROOT}/scripts/fetch-template-catalog.js"
   

   Use the returned immutable commit SHA for every template artifact request in this run. Pass --ref <tag-or-branch> only for a deliberate test or rollback.

   Evaluate the JSON result:

   • If ok: false: tell the user templates are temporarily unavailable and continue with the from-scratch path. This is additive; a catalog failure must never block create-site.
   • If ok: true but selectableCatalog.templates is empty: tell the user no supported SPA templates are currently available and continue with the from-scratch path. Do not offer entries from catalog.templates whose kind is traditional.
   • If supported SPA templates are available: use selectableCatalog.templates for every matching, preview, browse, and selection step below. Keep catalog.templates only as the complete downloaded manifest.

3. Semantically match the template families against the Phase 1 context ($ARGUMENTS, site name, purpose, audience, and any framework mentioned by the user):

   • Use each family template's displayName, description, keywords, audience, available variant frameworks, and any variant-specific previews.
   • Do not compute a numeric score or invent a ranking script. Keywords guide agent judgement; they are not counted.
   • Treat a template family as the user-facing template and a framework variant as the installable package. A family can have multiple variants (react, vue, angular, astro).

<!-- not-a-gate: read-only route selection after semantic matching; no project directory, Dataverse write, or durable skill state exists yet -->

4. Ask the user how to proceed after semantic matching:

   | Match situation | Question | Header | Options | |-----------------|----------|--------|---------| | One or more clear matches | I found matching template(s) for your site. What would you like to do? | Creation Path | Show matching templates (Recommended), Browse all templates, Create from scratch | | No clear match | I couldn't find a matching template for your site. What would you like to do? | Creation Path | Browse all templates, Create from scratch (Recommended) |

   Branch on the answer:

   • **Sho