---
name: create-site
description: Scaffold a brand-new site from scratch to a reusable standard — accessibility-tagged, SEO-optimized (sitemap/robots/hreflang), multilingual, TinaCMS-backed, correct social-preview images, favicon + site title, unique per-page metadata, legal pages (privacy/AUP/license), a Tina-powered contact form, an AI provider key wired into GitHub Actions, a STYLE.md design contract, optional graph memory, review-aware security CI, responsive breakpoints, and a git repo with CI already wired up. Use when the user says "create a new site", "spin up a site", "/create-site", "new landing page from scratch".
---

# Create Site skill

Turns "build me a new site" into a fully standards-compliant repo *before* any real content exists, then hands control back to the user for the parts only they can supply (copy, images, legal specifics, keys).

Two phases. Do not blend them: everything decidable without the user happens first and silently; everything else is one batched interview at the end.

## Phase 0 — the only upfront questions (one batched user-input request)

Ask only what blocks scaffolding — nothing content-related yet:

1. **Project name + target directory** (default: sibling of other site projects, e.g. `~/Documents/<Name>`)
2. **Domain**, if already registered (else leave placeholder, fill in later)
3. **Locales**: default/primary language + which additional locales to support now (can add more later — don't over-collect)
4. **License posture**: proprietary "all rights reserved" (default for a personal/business site) vs. open-source (MIT/Apache-2.0) — determines what goes in `LICENSE`
5. **AI provider for GitHub Actions automations**: OpenAI, Claude, or Gemini (single choice; the key gets wired in Phase 1 as a placeholder secret, populated for real in Phase 2)

Do not ask about copy, images, colors, or legal-entity details here — those are Phase 2.

## Phase 1 — automated scaffold (no more questions until it's done)

When the user provides an existing site template, inspect it first, then copy it (excluding `.git`, `node_modules`) into the target directory rather than rebuilding from scratch. Otherwise scaffold the smallest equivalent structure using the project's existing framework and CMS choices.

Work through this checklist. Each numbered item corresponds to a standing requirement — don't skip one silently, and don't gold-plate beyond it either.

1. **Copy + rename.** Copy the template, rename in `package.json`, add `.env.local` from `.env.example`, `git init` fresh (do not carry over the template's git history).

2. **Multilingual/locale routing.** Add `next-intl` (or the lightest static-export-compatible i18n approach — check what's current when this runs, don't assume). One JSON message file per locale under `src/locales/<locale>.json`. Default locale unprefixed at `/`, others at `/<locale>/`. Add a `locale` field to the Tina `page` collection so translated copy lives in Tina, not hardcoded. Add `hreflang` alternate `<link>` tags per locale on every page (see step 4).

3. **Accessibility tagging.** Every generated layout, page, form, and interactive control gets: a skip-to-content link, landmark roles (`header`/`nav`/`main`/`footer`), keyboard-visible focus states, accessible names and labels, a required `alt` field on every Tina image field (not optional — Tina schema should reject empty alt text), and `aria-live`/`role="alert"` on dynamic status text. Add an automated accessibility scanner (for example `@axe-core/cli` or `pa11y-ci`) to `.github/workflows/build.yml`, run it against the built `out/` directory, and fail on serious/critical violations only.

4. **SEO.** Add `next-sitemap` (postbuild script → `sitemap.xml` + `robots.txt`), canonical `<link>` per page, `hreflang` alternates per step 2, Open Graph `type`/`locale`, and a placeholder Google Search Console verification meta tag (real value comes in Phase 2 once the user has the domain verified). Structured data (`WebSite`/`Organization` JSON-LD) using placeholders for name/logo, filled in Phase 2. Run sitemap, metadata, and link checks from `.github/workflows/build.yml`.

5. **Social preview images.** This is not optional boilerplate; missing dimensions and oversized assets commonly break previews:
   - Every page needs `og:title`, `og:description`, `og:image`, **`og:image:type`, `og:image:width`, `og:image:height`**, `og:image:alt`, and matching `twitter:*` tags. Missing width/height is the single most common reason Instagram/iMessage silently drop a preview even when Facebook/Twitter still render it — never ship without them.
   - The image itself must be landscape-ish: aspect ratio between 1:1 and 1.91:1. A portrait or arbitrary screenshot must be padded onto a canvas (matching the site's brand background) rather than used raw — do not just point `og:image` at whatever asset exists.
   - Keep the file small (aim well under 300KB) — large images can time out on strict fetchers (iMessage/Instagram) before Facebook/Twitter's more patient crawlers would notice.
   - Write a `scripts/generate-og-image.*` helper (Python+Pillow or Node+sharp, whichever the project already leans toward) that composites a 1200×630 default from the site's brand palette + wordmark, so future pages get a consistent preview without manual editing. Give the Tina `page` collection an optional per-page OG image override field.
   - Default `og:image` content is a Phase 2 input (the user supplies brand art or approves the generated default).

6. **Site title + favicon.** `site.title` in Tina content (Phase 2 fills the real value; scaffold a placeholder now). Favicon: use a light/dark dual-icon pattern with `rel="icon"` and `media="(prefers-color-scheme: light)"` plus a dark counterpart and `apple-touch-icon`. Generate from whatever mark the user supplies in Phase 2; scaffold the `<link>` tags now with placeholder files so the wiring doesn't get forgotten later.

7. **Dark/light asset variants — optional.** Wire the `prefers-color-scheme` CSS custom-property split in the base stylesheet either way (cheap, mechanical), but only ask the user for actual dark-mode art in Phase 2 if they want it. Don't block scaffolding on this.

8. **Unique per-page title/description.** The Tina `page` collection already requires `title` + `description` — add a CI lint script (`scripts/check-unique-metadata.*`) and run it from `.github/workflows/build.yml`; fail the build if two pages share an identical title or description, or if either is empty. This is the enforcement mechanism, not a manual reminder.

9. **Legal pages.** Scaffold `/privacy` and `/usage-policy` (Acceptable Use Policy) as Tina `page` documents with placeholder body copy the user fills in during Phase 2. Add a `LICENSE` file at repo root matching the Phase 0 license choice (proprietary notice with the user's entity name as a placeholder, or the actual MIT/Apache-2.0 text if open-source). Add a copyright line in the footer component (`© <year> <Entity>`, placeholder entity name).

10. **Contact page via Tina forms.** The template's `forms` collection + `/app/forms/[slug]` route + `TinaForm.tsx` + `/api/forms/submit` already work end to end — wire a `/contact` page around it with a default field set (name, email, message). The `/api/forms/submit` handler only logs by default; leave that as-is unless the user asks for real delivery (email/Slack/DB) — that's a scope decision for them, not an assumption to make silently.

11. **AI provider key for GitHub Actions.** Based on the Phase 0 choice, add the corresponding secret name convention (`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` / `GEMINI_API_KEY`) to `.github/workflows/ai-automation.yml` — one provider per project, one small real automation (for example, translating changed Tina copy or generating alt text), never a no-op placeholder. Do not paste the actual key value anywhere in the repo or in chat; tell the user in Phase 2 to set it with the provider's secret-management workflow, or hand it to you via a user-only environment variable/file path — never have it land in the conversation log if avoidable.

12. **STYLE.md.** Generate a design-tokens document: color palette, type scale, spacing scale, the three breakpoints from step 15, component rules (button states, focus rings, card radius/shadow). Populate real values once the user gives brand colors/fonts in Phase 2; scaffold the structure now. Add one line to the project's `AGENTS.md` (or provider-specific instruction file): *"All visual changes must conform to STYLE.md — treat it as the design contract, not a suggestion."*

13. **Graphify.** Once the initial file tree exists, run `graphify update .` (or `graphify init .` if that's the current bootstrap command — check, don't assume) so the knowledge graph exists from commit one. Note in the project's agent instructions that graphify should be queried first for codebase questions when it is available.

14. **Related skills.** Check the host agent's skill registry for `ponytail`, `impeccable`, and equivalent review/design skills. If the host supports installation and the user has authorized it, install missing skills; otherwise record them as optional and continue. Apply available skills before final UI review. Add a short note to the project's agent instructions confirming the smallest-working-diff convention and the review step before merge.

15. **Responsive breakpoints.** Standard three: mobile `<640px`, tablet `640–1024px`, desktop `>1024px`, as CSS custom properties/media queries in the base stylesheet, documented in STYLE.md. Every scaffolded page component gets checked at all three widths before Phase 1 is declared done (use whatever local dev/browser tooling is available — don't skip this because it's "just CSS").

16. **Quality + security CI.** Create `.github/workflows/security.yml` using a standard hosted runner and adapt the checks to the project's language:
    - Gitleaks secret scan on `ubuntu-latest` using the standard `gitleaks/gitleaks-action`.
    - Static checks translated to web: no hardcoded API keys/tokens in client-bundled code, no `http://` links outside localhost, no `dangerouslySetInnerHTML`/`eval` on untrusted input, no secrets in `NEXT_PUBLIC_*` env vars.
    - Style quality is not a universal CI-executable check — add a PR template checklist line to run the host agent's available review skills before requesting review. Don't fake an automated gate that doesn't exist.

17. **Git + GitHub Actions, fully wired but not pushed yet.** `git add -A && git commit` locally. Do **not** run `gh repo create` or `git push` without asking first — creating a remote repo and pushing are both visible, hard-to-quietly-undo actions. Ask once, batched with the Phase 2 interview: "Ready to create the GitHub repo and push? (y/n)".

When every item above is either done or explicitly deferred to Phase 2, move on — don't keep polishing Phase 1 waiting for content that hasn't arrived yet.

## Phase 2 — the content interview (one batched pass, after scaffolding is done)

Now ask for everything Phase 1 couldn't invent. Group into one message, not sixteen round-trips:

- Site title, one-line description/tagline, and per-page copy (or: "should I draft placeholder copy for you to edit?")
- Logo / wordmark source file (for favicon + OG image generation) — light and dark variants if step 7 was opted into
- Brand colors + fonts (feeds `STYLE.md` + the OG image template)
- Legal entity name + jurisdiction (feeds privacy/AUP/copyright placeholders) — note you are not a lawyer; offer to draft standard boilerplate and flag that a real policy review is on them
- Domain, if not already known, and whether Search Console is already verified (for the real verification meta tag)
- The AI provider key itself — hand-off path only (see step 11), never pasted raw into chat if avoidable
- Confirm: create the GitHub repo and push now?

Apply everything gathered, regenerate the placeholder-filled files (favicon, OG image, STYLE.md, legal pages, site title), run the CI checks locally once (a11y scan, unique-metadata lint, build), then report what's done and what's still a placeholder.

## Do not

- Do not ask Phase 2 questions before Phase 1 scaffolding is complete — the point of the two-phase split is that content questions don't block structural work.
- Do not invent brand colors, legal entity names, or real copy — placeholder + flag, never fabricate as if real.
- Do not push to GitHub or create the remote repo without an explicit yes.
- Do not paste API keys into the conversation if a file/env-var hand-off is available instead.
- Do not build a bespoke i18n/CMS/sitemap system when the Headless Site Template + `next-intl` + `next-sitemap` already cover it — reuse, don't reinvent.
- Do not claim subjective style review is automated CI — be honest that it is a checklist item pointing at available agent skills.