The review standard the website suite already uses, generalized. Run it at the END of a work batch, after a multi-file fix wave, or before trusting a new tool — the moments cross-file consistency silently breaks. Read-only: report findings; fix only when asked.

Read-only consistency check of any live site, on any stack. FACTS: one approved facts list (value, source, owner); scripts/facts_check.py reports every figure on the sitemap's pages that differs from it (text, titles, descriptions, alt texts, structured data, llms.txt) and retired phrases (old names, taglines, claims) still in use. POSITIONING: rules map page paths (/en/business/*) to an audience and the term each page owns; it lists pages that lost the term in title, meta description or H1/intro, as the starter's positioning test does. AI answer engines quote whatever figure and wording they find. Stdlib Python; runs weekly beside the AI check, in-house. Trigger phrases: "facts check", "check our figures", "do our pages contradict each other", "claims register", "is the old name still on the site", "positioning check of the live site", "do our pages still carry their terms".

Adds an optional editor UI to the `new-website` Astro overlay. **Opt-in:** the default scaffold is CMS-free (Markdown-in-git is the workflow). Run this only when new-website §1 Q3 says a non-technical person edits after launch. Keystatic is git-based — it writes Markdown/Markdoc into the repo, so

The entry point for every new site you build. It **decides the stack**, **sequences the work**, and **scaffolds a self-contained, handoff-ready repo** from this skill's `templates/`. Concrete content/SEO/design/QA work is delegated to seven sibling skills + existing global skills.

Links to other people's sites rot: companies rebrand, move domains, or shut down. The offline test gate (`tests/links.spec.ts`) can only catch domains you *already know* are dead. This skill is the active sweep that *discovers* the rot.

The core failure this fixes: a site's own phrasing collides with an unrelated established concept, so Google (and LLMs) file it under the wrong thing — "contacts" → contact lenses, "frequent flyer" → airline miles, "travel networking app" → meet-strangers apps. No amount of on-page polish fi

Owns the **how it says it** layer of a new site: tone of voice and EEAT signals, captured in the per-site docs that everything downstream reads. **Positioning** (what you offer, for whom, the market category) is owned by `website-positioning` and worked out first; this guide reads it from `POSITIONI

A build is a tight loop of `npm`/`astro`/`playwright`/`git` calls. Approving each one by hand is friction with little safety benefit for the exact commands the skills run every day. This skill gets the repo to "quiet for the safe stuff, blocked for the dangerous stuff", and keeps it that way as the

Answer one question: **can the right visitor quickly tell this is for them, what they get, and why to believe it?**

The gate every page passes before launch, and the check re-run after any edit. Two parts: the **automated basic tests**, then the **performance check**.

A two-pass audit of a site's code/config/content, modelled on the `portfolio-code-reviewer` Double-Knuth. It sits **on top of `website-qa`**: the tests are the floor (must be green first); this is the human-grade review that catches what a test suite can't — cross-file drift and half-done work.

OPTIONAL colours and logo for a site whose owner is not a designer. Writes three prompts the owner pastes into the design tool she likes (three palettes, five variations of a simple SVG mark, a download package of her favourite), then checks what comes back with code and installs it: contrast of every text colour on every background in both themes, SVG safety, the seven icon files, the theme tokens, the share cards. Refuses and names the problem instead of adjusting anything silently; puts every file back if the site's tests go red. Never runs unasked: asked once after positioning, or run later on an existing site. Trigger phrases: "I need a logo", "pick colours", "colour palette", "brand colours", "favicon", "app icons", "my logo as the favicon", "install my logo", "new colours for the site", "does my palette pass contrast". Not for a tagline, fonts, a raster (PNG/JPG) logo, generated photos (image), or the share-card design (og-images).

Add a contact form to a new-website site that needs no server and no setup: the visitor fills in a few fields, presses a button, and their own email program opens with a message to the owner, ready to send. Nothing is sent or stored by the site. Adds a form component, its texts in English and German, one small script of the site's own (so a strict Content-Security-Policy holds), and tests/mail-form.spec.ts. The owner's address is always shown under the form for visitors without a mail program or without JavaScript. Run when new-website Q2 asks for a contact form, or later when the owner wants one. Trigger phrases: "contact form", "add a form", "enquiry form", "visitors should be able to write to us", "kontaktformular". Not for newsletter sign-up, file uploads, or anything that has to be stored.

The visual build standards for a new site: mobile-first responsive graphics (WebP/AVIF, sized-to-display, srcset, lazy-load, descriptive alt, no layout shift), dark mode (CSS-variable theme tokens + a no-FOUC script + WCAG AA contrast in BOTH themes), and the brand/theme token block that BRAND.md mirrors. Use when building or reviewing layout, images, theming, or BRAND.md (step 6 of the new-website pipeline). Contrast is enforced by a11y.spec.ts (light+dark). Trigger phrases: "dark mode", "theme toggle", "responsive images", "mobile optimization", "image optimization", "WebP", "layout shift", "CLS", "design system", "theme tokens", "brand colors", "BRAND.md".

Add a photo place whose photos take turns by themselves, with one dot per photo, to a new-website site: a component, one script of the site's own (so a strict Content-Security-Policy holds), its texts in English and German, and tests/hero-carousel.spec.ts. Settings: pause "button" (default, a visible Pause / Resume button) or "dots" (no button, a dot stops it); swap "instant" (default) or "fade". Built to keep the page from jumping, the dots readable on any photo, and phones usable. Run on request, for a home page or any page. Trigger phrases: "photos that rotate", "auto-rotating hero", "carousel", "slider", "key visual that changes", "dots under the photo", "slideshow", "Bildwechsel", "Karussell". Not for one photo (no carousel needed), a gallery the visitor pages through, or video.

Add a page to a site, or rewrite one, so it is worth reading and findable before it is built. Writes one page document (a brief, then the full draft), has a fresh pair of eyes judge it for the reader, for search and AI answers, and for originality, takes the owner's go on the exact sentences, builds, then checks the build kept the approved text. It calls the checks other skills own (website-seo-geo, ai-seo, seo-audit, copywriting, search-console-insights, website-review) and does not repeat them. Use for a new page, a new article, a page rewrite, or "is this page any good". Trigger phrases: "add a page", "new page", "write a page about", "new article", "rewrite this page", "this page feels thin", "what should this page rank for", "review the draft before we build it".

OPTIONAL public scorecard: publish what a site's own test gate checked, as a dated section on one page. `npm run scorecard` runs the whole suite and writes scorecard.json (checks passed per area, pages, date, tested version); a component renders it and tells the reader when the site was edited after the run. The owner can add the four Lighthouse scores of a PageSpeed run, with a re-run link. A red run writes nothing, so a card never shows a failed run as passed. Never runs unasked: publishing test results is the owner's choice. Ships an opt-in tests/scorecard.spec.ts. Trigger phrases: "publish our test results", "public scorecard", "quality report", "show the Lighthouse scores on the site", "proof the site is tested", "update the scorecard". Not a performance audit (website-qa) and not an SEO report (search-console-insights).

OPTIONAL: find the one short line that sits under the logo (the tagline; a German-speaking owner calls it the "Claim"). Leads with purpose: starts from what the business is there to do for its customer, taken from POSITIONING.md, not from clever wording. Shows the owner six to eight candidate lines in three or four different directions, asks which direction sounds like them, then refines on the owner's feedback, for at most three rounds, until they pick ONE or stop. Records it in TAGLINE.md and writes SITE.tagline; ships an opt-in tests/tagline.spec.ts. Adds no claim POSITIONING.md lacks and loses every conflict with it. Never runs unasked. Trigger phrases: "tagline", "Claim", "strapline", "slogan", "motto", "the line under the logo", "a line for under our logo", "what do we stand for in five words". Not for positioning itself, the page headline, or the story one-liner.

Count what a live WordPress site holds before anyone promises to move it, write the new site's redirects, and check them after the move. Read-only toward the site: no login, no backup. scripts/wp_inventory.py counts each content type the REST API lists, where the sitemap disagrees, page builders and forms, and whether the count is complete. scripts/make_redirects.py turns its address list and the owner's decisions into public/_redirects lines. scripts/check_move.py asks the new site for each old address and names those missing, sent home or not where the decisions say. Stdlib Python. Trigger phrases: "how big is this WordPress site", "count the pages", "WordPress migration estimate", "what plugins does this site use", "write the redirects", "redirect map for the move", "did every page make the move", "check the redirects after the move", "are any old addresses broken".