Build and Deploy a Personal Brand Professional Website with Claude Code

July 27, 2026 Updated July 28, 2026 Claude Opus 5

Build and deploy a personal brand website with Claude Code in one run. Made for dentists, lawyers, coaches, consultants, and trades, with a repo ready for Vercel or Cloudflare.

Design-phase doctrine adapted in part from Anthropic's frontend-design skill (Apache 2.0)

Web Development Claude Code website-builder personal-brand web-design astro claude-code small-business

Tested on: Claude Opus 5

Prerequisites

Claude Code on a machine with Node.js 22 or newer The run executes npm install and npm run build; Astro 7 needs Node 22.12+. Expect a 20-60 minute session including installs.
Started in the directory where the project should be created The prompt creates the website as a new kebab-case folder under the current working directory.
Real business details within reach Services, license numbers, client quotes you may publish, a booking link, and photo paths make the result far better; gaps fall back to interview questions and stated defaults.
A browser Claude Code can drive, strongly recommended The design pass is much better when the model can see the page it built. Chrome DevTools MCP is the pick because it gives both screenshots and performance traces - claude mcp add chrome-devtools npx chrome-devtools-mcp@latest. Playwright MCP works too. With neither, the run falls back to a Chrome DevTools Protocol script and reports that it did.

Variables

Everything about the professional*

Paste all you have, in any language - name, profession, city and service area, phone, email, services, credentials and licenses, real client testimonials, booking link, website domain, photo file paths, brand preferences.

Site language

The language all site copy is written in. Several languages separated by commas builds a multilingual site with a switcher, and the FIRST one listed becomes the default. Developer docs and the final report stay in English.

Design direction

Three adjectives or a short vibe line, e.g. calm, premium, editorial. Keep the default to let the run derive it from the brief.

You are the design lead and web engineer for one client, delivering a complete, production-ready personal-brand website in this single session. The client is a skilled professional, not a developer. Work through every step below in order and do not stop for approval between steps; the only user interaction allowed is the interview in Step 2. Done means: the build exits clean, every route answers, and every deliverable in Step 7 exists. ═══ INPUTS ═══ PROFESSIONAL BRIEF: {{professional_brief}} SITE LANGUAGE: {{site_language}} DESIGN DIRECTION: {{design_direction}} Parse the brief into an intake record with these fields, leaving unknowns blank: full name; profession; business name; city and country; service area; phone; email; street address; services (list); credentials (licenses and license numbers, degrees, certifications, memberships); proof (client quotes with permission, case results, review links); booking link; website domain; social profiles; photo file paths; brand preferences. All site copy is written in the site language. The README, CONTENT-TODO, code comments, and your final report are written in English. Read SITE LANGUAGE as a LIST. Split it on commas and trim: one entry builds a single-language site and every i18n instruction below is skipped entirely. Two or more entries build a multilingual site, and the order is meaningful - the FIRST entry is the default locale, served unprefixed at /, and each later entry is served under its own path prefix. Resolve each name to its ISO 639-1 code and record the locale list before Step 1; "Spanish, English, French" resolves to es at /, then en and fr under /en/ and /fr/. Where a language has more than one living script, take the script the professional's own market uses and say which in ASSUMPTIONS: Serbian means Cyrillic, and Chinese means Simplified unless the brief points at Hong Kong or Taiwan. The page set, section order and conversion mechanics are identical in every locale. Only the copy, the html lang and the URL prefix change. ═══ STEP 1 - CLASSIFY ═══ Assign the profession to exactly ONE category. Never invent a fifth. - REGULATED - clients entrust health, legal standing, or money to a licensed practitioner: dentist, doctor, therapist, lawyer, notary, financial advisor, accountant. - CONSULTANT - expertise sold to businesses: marketer, growth advisor, market analyst, fractional executive, strategy consultant. - COACH - skills or growth taught to individuals: private teacher, tutor, language instructor, executive coach, life coach, music teacher. - TRADE - hands-on local service at homes or sites, often time-critical: plumber, electrician, home inspector, personal trainer, locksmith, landscaper. Tie-break in this order: requires a professional license and serves individuals -> REGULATED; primary buyer is a business -> CONSULTANT; teaches or develops individuals -> COACH; shows up in person to do physical work -> TRADE. For hybrids, pick the category whose visitor question dominates: "can I trust them with something critical" (REGULATED), "have they solved my business problem" (CONSULTANT), "do they fit how I learn" (COACH), "are they nearby, fast, and fair" (TRADE). Record the category and a one-line justification for the final report. CATEGORY CONTRACTS - the chosen block binds every later step. REGULATED - Pages: index, about, one page per service (cap 6), reviews, contact, privacy, disclaimer. - Index sections in order: hero (value proposition, credentials chip, primary CTA) / trust strip (license, years, memberships) / services grid linking to service pages / practitioner bio teaser / reviews teaser / "what to expect" in 3 steps / FAQ (5 questions) / contact band with NAP (name, address, phone) and EITHER opening hours OR, when the practice keeps no fixed schedule, one sentence stating how it takes appointments. A practice that publishes hours it does not keep makes a false statement a visitor acts on, so the policy sentence is the correct output there and the hours block and openingHours are both omitted rather than invented. - Primary CTA: book a consultation (booking embed if a link exists, else the contact form). Secondary: phone link, or a mailto: link when the intake supplies an email address and no phone, because a phone link with no number behind it is not a secondary CTA. - Tone: authoritative, calm, reassuring. Never promise outcomes; "painless", "guaranteed", and "beat the market" are banned. - Schema.org type, most specific match: Dentist, Physician, MedicalBusiness (therapist), LegalService (lawyer), FinancialService, or AccountingService. Attorney and ProfessionalService are deprecated types; never use them. - Disclaimer page: lawyer - attorney advertising notice, prior results do not guarantee a similar outcome, no attorney-client relationship is formed by using this site; health - content is not medical advice, and "Do not send health details through this form" repeated under the contact form; finance - content is informational only and is not investment, tax, or legal advice. Write these as proper paragraphs in the site language and mark each with "[CONFIRM WORDING FOR YOUR JURISDICTION]". CONSULTANT - Pages: index, about, case-studies, contact, privacy. - Index sections in order: hero (who you help + measurable outcome + book-a-call CTA) / client logo strip (ONLY if real client names exist; otherwise omit the strip entirely) / 2-3 case study cards with metrics / method (a named 3-4 step framework derived from the brief) / about teaser / FAQ (4 questions) / final CTA band. - Primary CTA: book a discovery call. Secondary: email link. - Tone: strategic, peer-to-peer, specific. Numbers over adjectives. - Schema.org: Person plus Service (provider, serviceType, areaServed). COACH - Pages: index, about, programs, contact, privacy. - Index sections in order: hero (transformation promise + portrait slot + book-intro CTA) / proof strip / who this is for (the stuck points) / method (named, 3-5 steps) / story teaser / programs teaser with visible pricing / testimonials / final CTA band. - The about page carries the origin story AND the methodology. The hero reserves a video slot (poster placeholder plus a CONTENT-TODO entry); rapport sells coaching. - Programs page: each package gets a name, outcome, duration, and visible price; if no pricing is provided, show "from [ADD PRICE]" rather than hiding pricing. - Primary CTA: book an intro session. Tone: warm, direct, empowering. - Schema.org: Person plus Service; add Course only for a defined curriculum. TRADE - Pages: index, one page per service (cap 6), service-area, reviews, contact, privacy. - Index sections in order: hero (service + city + availability + tap-to-call + quote CTA) / trust strip (license number, insured, years, rating slot) / services grid / service area with city list / job gallery (empty labeled slots plus a CONTENT-TODO entry; never stock photos) / reviews / two-step quote form / NAP band. - A sticky mobile bottom bar with a tel: call button renders on every page. The phone number is clickable everywhere it appears. - Quote form is two-step: step 1 service type + timeline, step 2 name + phone. FOUR visible fields and no more; the hidden form key and the honeypot are not fields and do not count toward that. - Tone: direct, fast, dependable. Short sentences. - Schema.org, most specific match: Plumber, Electrician, HomeAndConstructionBusiness, or LocalBusiness; include areaServed with the city list and openingHoursSpecification (24/7 only if emergency service is real). A trade usually answers hours only IN PART - genuine 24 hour emergency cover, plus planned work in weekday slots nobody has put times to. Assert only the part the brief actually states, so 24/7 for the emergency cover and no weekday schedule anywhere, and carry the planned work in the prose availability sentence. One openingHours set cannot express two different availabilities without misstating one of them. ═══ STEP 2 - INTERVIEW ═══ Compare the intake record against the category contract. If a question tool (AskUserQuestion) is available AND fields are missing, ask at most TWO rounds of at most 4 questions each, only for missing fields, in this priority order: Round 1 - essentials: 1 services offered; 2 credentials and license numbers; 3 street address and service area; 4 for REGULATED and TRADE the opening hours, and for CONSULTANT and COACH the website domain they plan to use. Round 2 - brand and proof: 5 three adjectives for how they want to come across; 6 what makes them different from local competitors, in one sentence; 7 real client quotes they have permission to publish (quote + first name); 8 booking link (Cal.com or Calendly), if any, and the website domain if Round 1 spent its fourth question on hours instead. Hours earn a Round 1 slot for the two categories that print them, because a practice that shows a street address and no hours reads as abandoned, and openingHours is part of their JSON-LD. The other two categories rarely have public hours at all, so asking wastes the slot. Every question names its default. Defaults when skipped or unanswered: services - the 4 most standard for the profession; credentials - no specifics, the placeholder token LICENSE-NUMBER-PENDING per the Step 5 SAMPLE RULE, which is the ONLY licence placeholder token this prompt uses, whether the number is unissued or simply not supplied; address - city only, no map; hours - when the brief gives NO hours at all, omit the hours block and the openingHours property entirely rather than guessing a schedule, write the availability sentence the category contract allows in their place, and add a CONTENT-TODO entry; when it answers IN PART, assert only the part the brief actually states and carry the rest in the availability sentence rather than discarding what is known or inventing what is not; domain - example.com placeholder plus a CONTENT-TODO entry; adjectives - the category tone words; differentiator - none claimed, so write specific copy without superlatives; quotes - sample content per the SAMPLE RULE; booking - the contact form is the CTA. No question tool available: apply every default silently and list each assumed value under ASSUMPTIONS in the final report. Never re-ask anything already in the brief. Never exceed 8 questions. ═══ STEP 3 - RESEARCH (conditional) ═══ If web search is available, run exactly three searches; otherwise skip this step and note the skip in the report - the category contract fully covers the build. 1 "[profession] website must-have sections" - harvest the trade's vocabulary and 2 copy specifics. 2 "[profession] [city]" - note what 3-5 local competitor sites share: their palette, their type, their layout. This is the single most valuable input to Step 4, because the archetype is chosen against it. 3 REGULATED only: "[profession] website disclaimer requirements [country]" - refresh the disclaimer paragraphs with currently expected notices. Search indexes are dominated by US and UK regulators, so this query returns their material for most of the world even with the country named. Read what comes back BEFORE using it: material from another jurisdiction tells you which KINDS of notice a regulator asks for and nothing about the wording that binds this practitioner, and adopting a foreign bar's phrasing on a licensed professional's site is a false statement about which rules they answer to. If the returns do not cover the actual jurisdiction, write the notices in the structure the returns suggest, mark each one in the rendered page with the visible token [CONFIRM WORDING FOR YOUR JURISDICTION], say so in the report, and make it a CONTENT-TODO entry in the first tier. A visible marker is the honest output; silently shipping another country's boilerplate is not. A search that errors is reworded and retried once, then abandoned; note any abandoned search in the report rather than substituting a guess for its findings. Findings sharpen copy and design divergence. They never change the page set or section order. ═══ STEP 4 - DESIGN DIRECTION ═══ 4A - CHOOSE AN ART DIRECTION. Pick exactly ONE archetype below and argue the choice in two sentences from three inputs: what the profession physically looks like at work, the differentiator from Step 2, and what the Step 3 competitors all look like, which you choose against. The Step 1 category does NOT select the archetype - a dentist can be POSTER BOLD and an analyst can be INK AND PAPER. If DESIGN DIRECTION above is anything other than "derive from the brief", it selects or overrides the archetype. SWISS CLINICAL - pure #FFFFFF ground, true black or near-black text, ONE fully saturated signal colour at full strength and never decorative. Zero border-radius throughout. Grotesk display with a monospace utility face for figures and labels. Silhouette: a strict visible grid, dense information blocks separated by white space rather than rules. Motion: instant, 120-180ms, no easing theatre. INK AND PAPER - true paper white, ink black at full strength, and ONE accent that is emphatically not ochre or terracotta. High-contrast display serif at large sizes, drop caps permitted, hairline rules as structure. Silhouette: asymmetric editorial columns, a wide measure for the lead, pull quotes breaking the column, and no alternating full-width bands anywhere. Motion: almost none, because the type is doing the work. This archetype sits closest to the banned defaults below, so choosing it demands the strongest argument and real editorial column structure rather than a serif dropped onto tinted bands. NIGHT INSTRUMENT - a near-black ground, never pure black, one luminous accent that reads as emitted light, greys between. Tight grotesk display, monospace numerals. Silhouette: dark panels with 1px luminous edges, figures laid out like an instrument readout. Motion: precise and short, additive glow on focus. No glassmorphism, no blurred panels. Derive the ground rather than reaching for a familiar dark grey: pick the hue first from what the work is lit by, then set the ground between 4 and 9 percent lightness in that hue and build the panel and edge greys from it. State the hue and why in decision 3. POSTER BOLD - two or three flat colours at FULL saturation, no tints, no neutrals beyond one. Heavy condensed or geometric display at poster scale, body face small by deliberate contrast. Silhouette: full-bleed colour-block sections with type set into the blocks, hard edges everywhere. Motion: colour and position snap between states. SOFT ARCHITECTURE - layered warm neutrals with real depth from cast shadow, never gradient fills. Humanist sans throughout, generous line height, large soft type. Silhouette: overlapping planes, offset cards, photographic space with room to breathe. Motion: slow and weighted, 400-600ms with physical easing. TECHNICAL MONO - monospace-forward everywhere including headings, a restrained two-value palette plus one accent, exposed labels and metadata so dates, versions and figures read as annotations. Silhouette: visible baseline grid, tabular alignment, a page that reads like a well-kept document. Motion: cursor-adjacent, so underscores, carets and stepped reveals. Archetypes are grammars, not skins. Having chosen one, follow ITS logic below and do not average it back toward a comfortable middle. Any hex value written above is naming a property, not handing you a swatch: derive your own from the profession and never copy a literal out of this prompt. 4B - WRITE DESIGN.md in the project root BEFORE any code, containing exactly these seven decisions: 1 Positioning line - one sentence a stranger absorbs in 3 seconds: who this is, what they do, where. 2 Archetype - the name plus the two-sentence argument from 4A. 3 Palette - 4 to 6 named hex values following the archetype's palette logic, with the accent's reason tied to the profession written down. Compute and record the real contrast ratio for every text pair you actually use; body text below 4.5:1 is not used, and say which pairs you rejected. 4 Type pairing - display plus body, optional third utility face, in the archetype's type register. Before writing a family into the config, confirm it exists in Fontsource AND covers the site language's script; an unresolvable family fails the build. For non-Latin scripts name the subset explicitly (cyrillic, greek, vietnamese). Banned as display faces: Inter, Roboto, Poppins, Space Grotesk, Arial, Playfair Display. 5 Signature element - ONE ownable visual device derived from the profession's actual work (a dental arch curve as the section divider, pipe-gauge numerals for a plumber, a plotted-line motif for an analyst). It appears on every page in 3 to 5 places; a sixth use is a tic, so cut it. Nothing else decorative competes with it. Spend the design's boldness here and keep the surroundings quiet. 6 Hero treatment - the tier from the HERO TREATMENT block in Step 5, named exactly, plus what it depicts and why that image belongs to this profession rather than to any professional. 7 Motion plan - the archetype's motion vocabulary written as concrete durations and easings, plus what is deliberately NOT animated. An archetype whose vocabulary is a snap has no duration and no easing curve to name, so write none and say why rather than inventing a curve to fill the row. All motion respects prefers-reduced-motion. HARD BANS regardless of archetype, being the recognised marks of template AI design: indigo-to-violet gradients and purple-on-dark heroes; a hero followed by exactly three feature cards; coloured left-border accent strips on cards; uniform 16px border-radius on everything; emoji as icons; glassmorphism panels; fake team or diversity stock photos; lorem ipsum; a fade-up stagger on load as the only motion idea in the build. BANNED STARTING POINTS. Independent runs of this prompt demonstrably converge on the following, and convergence is the failure this step exists to prevent: a desaturated off-white ground with green-cast or blue-cast near-black text and one warm ochre or terracotta accent; a characterful display serif over a workhorse grotesk body reached for by reflex; letterspaced small-caps kickers above every h2; alternating quiet tinted bands down the whole page; oversized numerals as the boldest object on the page. None of these is forbidden in itself - each is forbidden as a DEFAULT, meaning you may only arrive at one by arguing for it from the brief. Two or more of them together means the design defaulted rather than being chosen: discard it and restart decision 3 under a different archetype. If these skills are available in this session, use them now and reconcile their output with this contract, which wins on conflict: frontend-design for the direction as a whole, and algorithmic-art or canvas-design to originate the hero visual and the signature element rather than reaching for a generic shape. ═══ STEP 5 - BUILD ═══ Project directory under the current working directory: kebab-case business name if one exists, else kebab-case full name, suffixed "-site" (bright-oak-dental-site). If the directory already exists, append "-2". Then: 1 npm init -y; then edit package.json: "name" = the directory name, "private": true, "type": "module", "engines": {"node": ">=22.12.0"} exactly as written, scripts "dev": "astro dev", "build": "astro build", "preview": "astro preview". 2 npm install astro tailwindcss @tailwindcss/vite @astrojs/sitemap 3 Write .nvmrc containing exactly: 22. Both version files are required and neither replaces the other: Cloudflare reads .nvmrc, Vercel reads engines and ignores .nvmrc. 4 astro.config.mjs in this exact shape - current as of mid-2026; do not substitute older patterns, and never install the deprecated @astrojs/tailwind package: import { defineConfig, fontProviders } from "astro/config"; import tailwindcss from "@tailwindcss/vite"; import sitemap from "@astrojs/sitemap"; export default defineConfig({ site: "https://example.com", integrations: [sitemap()], vite: { plugins: [tailwindcss()] }, fonts: [ { provider: fontProviders.fontsource(), name: "Display Face", cssVariable: "--font-display", weights: ["400 700"], subsets: [/* EVERY script, see below */], fallbacks: ["sans-serif"], optimizedFallbacks: false }, // read the weights note below before copying this line { provider: fontProviders.fontsource(), name: "Body Face", cssVariable: "--font-body", weights: ["400 700"], subsets: [/* EVERY script, see below */], fallbacks: ["sans-serif"], optimizedFallbacks: false } ] }); Replace site with the real domain from the interview (else keep example.com plus a CONTENT-TODO entry) and the two font names with the DESIGN.md pairing. subsets MUST list every script the site language needs - ["cyrillic", "latin"] for Russian, ["greek", "latin"] for Greek - because the default ships Latin-only unicode ranges and every non-Latin glyph then falls back to a banned system face, silently destroying the type direction. optimizedFallbacks: false stops Astro generating its Arial-metric fallback family. The font family schema is strict, so a mistyped key fails the build with an exact message rather than being ignored. weights: ["400 700"] is a VARIABLE RANGE and only works on a variable family. Check each family before copying that line, because many of the best display faces are static single-weight files - Anton ships weight 400 and nothing else - and asking Fontsource for a range requests weights that do not exist. For a static family list its real weights as separate strings instead, ["400"] or ["400", "700"]. Also set styles: ["normal"] on every family unless the design genuinely sets italic: the default is ["normal", "italic"], which downloads AND preloads italic faces at highest priority on every page, and on a three-family site that is around 100kB of transfer for faces nothing on the page uses. fallbacks must match the CATEGORY of the face it backs and not the literal sans-serif in the template above: a serif display face backed by a system sans jumps visibly on first paint, so write ["Georgia", "serif"] behind a serif and keep sans-serif behind a sans. MULTILINGUAL ONLY - with two or more locales, add an i18n block to the same config and hand the sitemap the same locale map so it emits hreflang alternates for you. The locale list and the BCP 47 map are locale-invariant facts, so they live in src/data/site.js like every other fact and this file imports them; hardcoding them here would give the router and the site data two versions of the same truth that can silently disagree: import site from "./src/data/site.js"; ... i18n: { defaultLocale: site.defaultLocale, locales: site.locales, routing: { prefixDefaultLocale: false } }, integrations: [sitemap({ i18n: { defaultLocale: site.defaultLocale, locales: site.localeTags } })], // localeTags maps each code to its BCP 47 tag, es to es-ES prefixDefaultLocale: false is what puts the default locale at / with no redirect hop. Now subsets must cover the UNION of every locale's script, not just the default one, or the site builds perfectly and one language renders in a fallback face. Two script traps that produce a clean build and a visibly wrong page. First, several languages set an apostrophe-class modifier letter INSIDE their words, where the mark is a letter and not punctuation. Those codepoints sit INSIDE the standard latin subset, which Fontsource ships as explicit narrow range fragments, so presence is rarely the problem and hunting for a family that carries them wastes the step. The real trap is METRICS: some families draw such a mark WIDER than their own lower-case o, every word carrying it then reads as a hole in the middle, and every coverage test in existence passes. Step 6 measures it. Second, NEVER self-host a CJK face: Fontsource splits Han into more than a hundred numbered subsets totalling megabytes, the named-subset field cannot usefully address them, and one such family destroys the performance floor on its own. Instead let Han fall back per glyph by appending a system stack to that family list, which costs zero bytes and renders natively on the devices those readers actually use: "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "Noto Sans CJK SC", sans-serif. Record in DESIGN.md that the CJK locale's headings resolve to a system Han face, so the type pairing is honest about differing there. 5 src/styles/global.css: first line @import "tailwindcss"; then an @theme block mapping the DESIGN.md palette to Tailwind color tokens (--color-*); then base element styles. Apply the faces with element selectors (h1-h3 and display elements use var(--font-display); body uses var(--font-body)); do not create Tailwind font-family tokens for them. Inside @theme also set --default-font-family: var(--font-body), because Tailwind's stock stack routes through Roboto and Arial, which the type direction bans. Two cascade facts to build around: your custom classes are unlayered and therefore beat every Tailwind utility, so a utility like pt-0 silently loses against a custom padding rule - override with another custom class, not a utility; and a prefers-reduced-motion block placed outside a layer outranks any animation defined inside one. 6 src/layouts/Base.astro: html lang set to the site language code; <Font> tags (imported from astro:assets) with preload for both faces; title and description props; canonical URL; Open Graph tags; the category's JSON-LD carrying WHICHEVER of name, address, phone, areaServed, openingHours and sameAs have known values and omitting outright every one that does not, because an absent property is correct while an empty or guessed one is a false claim a search engine will repeat - NEVER invent ratings, review counts, aggregateRating, or awards; a skip-to-content link; Header; slot; Footer. MULTILINGUAL ONLY: Base takes the locale and a route key as props. html lang carries THAT page's locale, canonical points at that page's own URL, og:locale follows it, and the JSON-LD gains inLanguage. The head then emits one <link rel="alternate" hreflang> per locale for the SAME route key, plus one hreflang="x-default" pointing at the default locale's copy of that route. Every page in a translation group lists the complete group including itself, because a one-way alternate is ignored. Title and description are translated per locale, never reused from the default. 7 Data, then components. src/data/site.js exports ONE object holding every fact from the intake record and interview: name, profession, business, NAP, hours, services, credentials, proof, booking link, domain. Every component and page reads from it, so the address exists in one place and is edited once. Facts are never retyped into markup. Components: Header (nav in page order plus the primary CTA button), Footer (NAP, credentials line, social links, legal links, and the hours or the availability sentence ONLY on pages whose body does not already carry it - the footer renders on every page, so printing it unconditionally breaks the once-per-page rule below), the category's section components, and for TRADE the sticky call bar. MULTILINGUAL ONLY: split the single source of truth by what actually varies. src/data/site.js keeps the locale-INVARIANT facts - phone digits, tel and mailto hrefs, email, domain, booking URL, social URLs, license number, map query, opening and closing times as numbers when hours are published at all, and the routing facts astro.config.mjs imports from here: defaultLocale, locales as the ordered array with the default first, and localeTags as the locale-to-BCP-47 map. One file per locale under src/i18n/<locale>.js keeps everything whose WORDING changes: profession title, service names, page titles and descriptions, section headings, body copy, day names, the address as it is written in that language, CTA labels, form labels and validation strings, the sample caption line. Every locale file exports the same key set; a key present in one and missing in another is a bug, so assert the key sets match at build time and fail loudly rather than rendering undefined. Never fall back silently to the default locale's string, which ships a page that looks translated and is not. Also build a LanguageSwitcher component: plain anchors, zero JS, each with lang and hreflang set to its target and the current locale marked aria-current="true" rather than removed from the list. It links to the CURRENT page's counterpart in each locale by route key, never to that locale's home page - dropping a reader on the home page because they changed language is the defect this rule exists to prevent. Label each option in its OWN language, not the current one. It sits in the header, keyboard reachable, and is not hidden behind a hover menu. EVERY BUILD, single-language included: the multilingual block above ends here, and this budget has nothing to do with locales. One source of truth is not the same as one appearance, so budget the repeats: on any single page, each intake fact prints at most TWICE in visible text. The exceptions are the phone number for TRADE and REGULATED, which may reach three appearances because click-to-call is the conversion, and the business name. Count the built page, not the source, then cut: a full street address printed four times and a license number printed six reads as padding and buries whichever instance was the useful one. The full hours table, or the availability sentence that replaces it, appears exactly ONCE per page; everything else links to it. 8 Pages exactly per the category contract, sections in the stated order. MULTILINGUAL ONLY - route layout, so the page body is written once and never forked per language. Each page in the contract becomes ONE component under src/components/pages/ that takes the locale and its dictionary and renders the whole page. Then two thin entry files point at it: the default locale's route lives at src/pages/<page>.astro, and the other locales share src/pages/[lang]/<page>.astro whose getStaticPaths returns one params entry per NON-default locale. An entry file only picks the dictionary and renders the component; if layout logic starts appearing in an entry file, it belongs in the component. Astro resolves static routes before dynamic ones, so the unprefixed default and the prefixed locales never collide. Sanity-check the arithmetic after building: the page count is the contract's page count times the number of locales, and any other number means a locale is missing pages or a route is generated twice. Copy rules: hero H1 caps at 9 words and names the profession plus the city (REGULATED, TRADE) or the outcome (CONSULTANT, COACH); subline caps at 20 words; one primary CTA and at most one secondary. All copy in the site language, written for this specific professional from the brief and interview; specific nouns over adjectives; zero exclamation marks. Banned in any language, including equivalents: "leverage", "seamless", "comprehensive", "unlock", "elevate", "world-class", "cutting-edge", "solutions", "we've got you covered". FAQ answers state only facts from the brief or interview; pricing appears only if provided. MULTILINGUAL ONLY: write each locale natively, do not translate the default locale sentence by sentence. Word counts differ per language, so re-cut the H1 to that language's own rhythm inside the same word cap rather than forcing a literal rendering that reads translated. Regulated-profession vocabulary is where a plausible translation does real damage, because a practice area, a court, a procedure and a professional title are legal terms of art with one correct local form and several convincing wrong ones, so use the term the profession itself uses in that jurisdiction and never a dictionary equivalent. For every locale you cannot personally hold to a native professional standard, still write the full copy, then add a CONTENT-TODO entry naming that locale and the files, asking for a native review by someone who works in that field, and state it in ASSUMPTIONS too. Never leave a locale machine-shaped and unflagged. HERO TREATMENT - the home page hero carries the design. The tier is set by the Step 1 category and is not negotiable, because attention is worth different things to different visitors. CONSULTANT and COACH get a generative canvas: ONE <canvas> running a single fullscreen fragment shader on raw WebGL2, or a 2D canvas flow field, hand-written with no library. Budget 6kB of unminified JS. The shader depicts something true about the work - a field of converging paths for a growth advisor, an accumulating weekly rhythm for a coach - never a generic particle cloud or noise blob. Read the palette from the CSS custom properties with getComputedStyle so the canvas cannot drift from DESIGN.md. REGULATED gets choreographed vector work: inline SVG animated by stroke-dasharray and stroke-dashoffset, and CSS 3D transforms with perspective. Zero JS. Calm is the product here, so a churning canvas actively works against the brief. TRADE gets no hero animation at all. The space above the fold is a phone number, the city, and availability. Someone with a burst pipe converts in seconds and every millisecond of motion is spent against them. Motion on a TRADE site is limited to focus and hover states. Rules binding every tier: a static first paint - CSS-painted or inline SVG - sits behind the animation and is what the visitor sees at LCP, so the animation is never the LCP element. Reduced motion is checked with matchMedia("(prefers-reduced-motion: reduce)") BEFORE the loop starts, and when it matches the loop never runs and the static paint stands alone. The render loop stops on document.hidden and when the hero leaves the viewport via IntersectionObserver. Device pixel ratio is capped at 2. If WebGL context creation returns null the static paint stands and nothing throws. Scroll-driven CSS animation is permitted as enhancement inside @supports (animation-timeline: scroll()), because Firefox stable still ships it behind a flag; content must never depend on scrolling to become visible. 9 Contact page: NAP, hours or the availability sentence, the form, the booking embed if a link exists, and a map iframe only if a street address exists (keyless Google Maps embed, loading="lazy"). Booking: a plain styled link to the booking URL is the GUARANTEED baseline and always ships. An inline embed is an enhancement on top, and only when you have fetched the provider's current embed snippet during this run - cal.com and calendly.com both change theirs. Never reconstruct an embed loader from memory: a stale snippet fails silently and the visitor sees an empty box where the calendar should be, which is worse than a link. Fetch it with curl, NOT with a fetch tool that summarises a page for you, because a summarised code block is a paraphrase and pasting a paraphrase of a loader is reconstructing it from memory with extra steps. Providers often generate the snippet inside the logged-in app and do not publish it as copyable text; when that happens, take it from the provider's own public source repository or their embed package, and if neither yields verbatim bytes then ship the plain styled link, say so in the report, and put the embed in CONTENT-TODO. No booking URL means the primary CTA points at the contact form. 10 The form posts to Web3Forms: action https://api.web3forms.com/submit, method POST, hidden access_key field with value YOUR-WEB3FORMS-KEY, a honeypot field, and at most 3 visible fields (name, phone or email, message) - except the TRADE two-step quote form. REGULATED forms repeat the "do not send health/case/financial details" caveat beneath the form. Add a mailto fallback link beside every form. 11 Images: if the brief lists real photo paths that exist on disk, copy them into src/assets and render through the astro:assets Image component with explicit widths. Otherwise build placeholder art from the palette and signature element as inline SVG - abstract shapes, never fake humans - and slot every future photo as a labeled aspect-ratio box plus a CONTENT-TODO entry. Never download stock photos. Favicon: an SVG monogram in the palette. Generate public/og.png (1200x630, name + profession + palette) with a one-off node script using the sharp package. Astro lists sharp under optionalDependencies, NOT dependencies, so it is usually already on disk and the project still must not rely on that: add sharp to devDependencies in package.json before importing it, or the script breaks on any install that skips optional packages and on any platform with no prebuilt binary. If sharp errors after one fix attempt, drop the og:image tags and add a CONTENT-TODO entry instead. 12 SAMPLE RULE, exactly: testimonials, case studies, or review quotes not present in the brief or interview render as realistic, fully styled sample content, and the section carries one muted caption line directly under its heading: "Example testimonials shown. Replace with your real client quotes before launch." Translate it into the site language and adapt the noun for case studies. Sample client names are first name plus initial only. NEVER render sample content for license numbers, credentials, degrees, years of experience, client logos, star ratings, review counts, or case-study metrics attributed to named clients: those come from the brief or interview, or are omitted. The caption is not decorative; publishing fabricated reviews is illegal in most jurisdictions. One exception, and only in this exact shape. It covers ANY slot a category contract requires on the page whose value the brief does not supply: a credential that exists or is being issued but carries no number yet, and equally the TRADE trust strip's insurance and rating slots, which that contract mandates while the rule above forbids inventing either. The slot still renders, with the missing value as an UNMISTAKABLE placeholder token in the same visual register as YOUR-WEB3FORMS-KEY - an upper-case token such as LICENSE-NUMBER-PENDING, INSURANCE-DETAILS-PENDING or REVIEW-LINK-PENDING, never a digit string and never a sampled rating. A plausible-looking number is a false verifiable claim about a real person and it can reach production unnoticed precisely because it looks right; a token cannot. Do not style it to blend in, keep it in the layout so its length is visible, translate the surrounding label but never the token itself, and give it a CONTENT-TODO entry together with the verification link if one exists, at the rank Step 7 assigns rather than a number chosen here. Where the credential itself is not yet issued, the surrounding copy says so in that locale's own professional register rather than implying it is already held. 13 public/robots.txt: allow all, plus a Sitemap line pointing at /sitemap-index.xml on the site domain. 14 Legal pages: privacy - what the form collects and where it goes (Web3Forms to the owner's email), no analytics, the site sets no cookies of its own, embeds are governed by their providers' policies. REGULATED adds the disclaimer page from the contract. 15 Accessibility floor: semantic landmarks, exactly one h1 per page, alt text on every image, visible keyboard focus, AA contrast verified against the real palette values, 44px tap targets, prefers-reduced-motion honored. 16 Performance floor: zero client-side JS frameworks and no animation library. Hand-written vanilla JS only, and only for the mobile menu, the hero canvas where the tier allows one, and a booking embed's own loader. Fonts preloaded; no external requests except the booking embed and the map iframe. 17 wrangler.jsonc: { "name": "<directory name>", "compatibility_date": "<today>", "assets": { "directory": "./dist" } }. And .gitignore: node_modules, dist, .astro. Astro 7's compiler is strict: close every tag, no block elements inside <p>, valid nesting only. Build errors are loud and exact - read them and fix precisely. One silent trap the compiler will NOT catch: a line break between two inline things is not a space. Two adjacent {expressions} split across lines render as "ValueOneValueTwo", and the same happens when an inline element starts on a new line, so "or call\n<a href={tel}>{phone}</a>" renders as "or call+15125550164". Both build cleanly and read as broken English on the live page. Keep an inline value, its separator and any wrapping tag on ONE line, interpolate a single pre-joined string, or write an explicit {" "}. Never call .toLowerCase() on a value that contains a proper noun. ═══ STEP 6 - VERIFY ═══ 1 npm run build MUST exit 0. Fix every error and rebuild until it does; a failing build is never deliverable. 2 Start npm run preview; curl every route in the category page set plus /sitemap-index.xml and /robots.txt; confirm each answers 200; kill the preview server. 3 Check the built dist/: "lorem" absent; "{{" absent; YOUR-WEB3FORMS-KEY present exactly where forms are; exactly one h1 per page; title, meta description, and og:title on every page; one application/ld+json block on EVERY page and not only the index - extract each one and JSON.parse it to prove validity. MULTILINGUAL ONLY, all mechanical and all cheap to get wrong: the built page count equals the contract's page count times the number of locales; every locale's full route set answers 200, including the unprefixed default; the locale dictionaries export identical key sets; html lang on each page matches the locale its URL claims; the hreflang set on every page names all locales plus x-default and is reciprocal, so following an alternate and reading its alternates gets you back; each canonical points at its own URL and not at the default locale's; and no page in a non-default locale still contains a default-locale string, which you check by taking a handful of distinctive default-locale sentences and grepping the other locales' HTML for them - a hit means a dictionary key silently fell through. 4 Proofread the RENDERED prose, not the source. Extract the visible text from each built page and read it. Structural checks pass happily on broken English, so look specifically for words fused together, a letter followed immediately by a digit, a missing space after a full stop, a lower-cased proper noun, and any untranslated English string on a non-English site. Fix what you find at the source. Reading alone under-counts this, so ALSO measure it in the browser during item 5 below, the LOOK AT THE PAGES pass, because finding one fused joint by eye means others are there unseen. For every p, li, dd and address whose OWN computed display is block, inline or list-item, walk adjacent child nodes and skip any pair where either side already ends or starts with whitespace, where both sides are text nodes, or where either side is visually hidden. For the pairs that remain, take the last client rect of the left node and the first client rect of the right node, require that they sit on the same line, and flag any horizontal gap under 2px. Fix each flagged joint at the source. Do NOT substitute a string comparison of concatenated text for this measurement. A flex or grid parent separates its children visually with no space character anywhere in the markup, and a screen-reader-only span contributes text that never paints, so a string test flags all of them and you would then damage correct layouts by inserting spaces into them. Measure the rendered gap. 5 LOOK AT THE PAGES. This pass is required, not optional, and you take the first of these routes that is available: Chrome DevTools MCP; else Playwright MCP; else write a throwaway Node script driving any local Chrome or Chromium over the DevTools Protocol. If none of the three works, say so plainly in VERIFICATION RESULTS - never skip it silently. Set the viewport with device-metrics emulation, NOT a browser window size: a window flag leaves the layout viewport wider than requested, and the resulting screenshot is a crop that mimics text-overflow bugs that do not exist. Confirm the viewport by reading back innerWidth. Note that a tool which resizes the browser WINDOW cannot go narrow enough for a phone, since the window has an operating-system minimum around 500px; device-metrics emulation has no such floor. At 390px and at 1440px, on every page: assert documentElement.scrollWidth is not greater than clientWidth, then look at the render and fix what is visibly broken - overlap, collision, illegible contrast, a hero that fails to paint. Then judge the render against DESIGN.md: does this look like the archetype you argued for, or has it drifted back toward a generic tasteful default? If it has drifted, fix the design, not the description. Still at 390px, measure the rendered box of every link, button and form control. Audit against TWO thresholds, because one number cannot catch both failures. The primary CTA, every header and footer nav item, and every tel: and mailto: link ANYWHERE on the site must be at least 44px tall; audit those against 44 and not 24, or a 30px CTA passes here and still fails the Step 5 accessibility floor. Everything else must clear 24px in both dimensions, and an ordinary text link inside a paragraph may stay at that size. Where a tel: or mailto: sits mid-sentence it is covered by the stricter rule and not by the prose exemption, because a phone number is the one target on the page that has to be hittable in a hurry: grow it with padding-block so the paragraph's line rhythm does not change. The one accepted exception is an off-screen honeypot input. Always padding, never larger text. Line-height alone does not grow the hit box. MULTILINGUAL ONLY, in the browser on one page per locale. Do NOT use document.fonts.check for this. It reports whether a face MATCHING the specifier is available, not whether that face contains the codepoints, so it returns a false positive for a script your fonts do not cover at all and a false negative for a subsetted file that is rendering correctly. It also cannot be called with the family name as authored, because Astro emits hashed families such as "Body Face-a5fe668c3cfce359"; read the real family name off a live element's computed style before measuring anything. Then run BOTH of these, because they fail independently. Coverage. Render each locale's hardest characters in the site face, then again with the font stack forced to a family you know lacks them, and compare measured widths. Identical widths mean both runs fell through to the same system face and your own font is not carrying that script. Han is EXPECTED to fall through per the config rule, so there just confirm it lands on a real system face and not on tofu by looking at the rendered heading. Metrics, and ONLY when some string in the build actually prints an apostrophe-class modifier letter inside a word. Skip this test rather than measuring a mark the site never shows. This is the one no coverage test catches: a glyph that is present and drawn at the wrong advance width. Using canvas measureText with the element's computed font string, measure that mark and the same face's lower-case o at the same size. The mark MUST measure GREATER THAN ZERO and narrower than the o, and both halves of that are load-bearing: an ABSENT glyph measures zero, zero is narrower than the o, so a narrower-than test on its own scores a missing mark as a pass. Widely used families do fail this in practice, one setting such a mark at 0.600 em against an o of 0.556 em, which turns every affected word into a gap in the middle, where a family that handles it correctly sets the same mark near 0.350 em. A face that fails either test is replaced, not patched with a second fallback family. Then exercise the switcher for real: from a deep page, not the home page, follow it into every other locale and confirm you land on the SAME page translated, that the current locale is marked rather than missing, and that returning by the switcher brings you back to where you started. Finally check that the longest locale does not break the layout - German-style compounds and Cyrillic both run longer than English, so re-measure overflow and button wrapping at 390px in the locale with the longest nav labels, not just in the default one. 6 Performance floor, measured rather than assumed: SITE-AUTHORED client JS at most 8kB gzipped across the site; the LCP element is text or the static hero paint, and never the canvas on the tiers that have one; no layout shift from fonts. The 8kB governs the JavaScript YOU wrote and nothing else. A booking provider's own loader is exempt because no provider ships one near that size - Cal.com's is roughly 22kB gzipped - so it can never be made to fit and pretending otherwise just makes the budget unsatisfiable the moment a booking link exists. Measure it separately, name the figure and the pages that request it in the report, and keep it off every page that does not need it. With Chrome DevTools MCP available, take a performance trace of the home page and report the real LCP figure. 7 Re-run npm run build after any fix. ═══ STEP 7 - DELIVER ═══ 1 README.md (English), sections in order: what this site is; run it locally (nvm use, npm install, npm run dev); deploy path A - push to GitHub and import in Vercel or Cloudflare, both auto-detect Astro (build command astro build, output dist); deploy path B - CLI, npx vercel or npx wrangler deploy using the committed wrangler.jsonc; deploy path C - no git: npm run build, then drag dist/ to Netlify Drop or Cloudflare's upload page, or zip the whole project for Vercel Drop, which builds it; custom domain pointers; edit guide (business facts in src/data/site.js and nowhere else, page copy in src/pages for a single-language build or in src/i18n/<locale>.js for a multilingual one, palette in the global.css @theme block, fonts in astro.config.mjs); for a multilingual site also which locale lives at which URL, that facts stay in src/data/site.js while all wording lives in src/i18n/<locale>.js, and the exact steps to add or remove a language. List every file that must change and verify the list by reading your own build rather than reciting this one: src/i18n/<locale>.js for the new dictionary, src/i18n/index.js to register it (a static import cannot discover a file on its own), and the locale list, which per Step 5 lives in src/data/site.js with astro.config.mjs importing it; say in the README that this is where it lives, and while you are there OPEN the config and confirm it really imports those values rather than importing them and then repeating the literals underneath, which reads as correct and drifts on the first language added; activate the form (free Web3Forms access key, 250 submissions per month, replace YOUR-WEB3FORMS-KEY); activate booking (swap the booking link); a closing note that installing Anthropic's skills (/plugin marketplace add anthropics/skills) gives Claude Code the frontend-design, canvas-design and algorithmic-art skills for future design iterations, and that adding Chrome DevTools MCP lets it see the pages it changes. 2 CONTENT-TODO.md (English), each entry naming the file, ordered by this precedence and no other, so that two rules can never claim the same rank: FIRST every visible placeholder token that stands where a verifiable claim about this person belongs, licence and registration numbers before anything else, because until it is replaced the page carries a claim it cannot support; SECOND removing the sample caption lines and the samples under them once real quotes go in; THIRD the things that merely leave the site incomplete - the domain, naming whichever file your build actually declares it in, real photos, the Web3Forms key, the booking link, the video slot (COACH), gallery photos (TRADE). Within a tier, order by how visible the defect is to a visitor. If a tier is empty it contributes no entries and the next tier starts at 1. 3 git init -b main, add everything, one commit: "Initial website". If git is unavailable, skip and say so in the report. 4 Final chat report with exactly these seven sections, in English: SITE SUMMARY - category with its one-line justification, page list, directory name, and for a multilingual site the locale list with which one is unprefixed and the total built page count. DESIGN DIRECTION - the archetype and the argument for it, positioning line, palette names with their contrast figures, type pairing, signature element, hero treatment. ASSUMPTIONS - every interview default that fired, or "none". SAMPLE CONTENT MARKED - which sections carry the caption line, or "none". VERIFICATION RESULTS - build status, route checks, dist checks, the rendered-prose proofread, which browser route the visual pass used and what it changed, and the measured JS weight and LCP. DEPLOY OPTIONS - the three paths, one line each. FIRST FIVE EDITS - the top of CONTENT-TODO.md. ═══ EDGE RULES ═══ - Brief lacks BOTH a name and a profession: if the question tool exists, ask one combined question; otherwise stop and output only a two-line request for name and profession. These two facts are the only hard requirement. - Hybrid or unknown profession: classify by the tie-break order, state the call, proceed. Never refuse a lawful profession; never invent a fifth category. - Photo paths that do not exist on disk: fall back to placeholder art, note it in ASSUMPTIONS, never fail the build over an image. - No web access: Step 3 skips; nothing else changes. - SITE LANGUAGE names exactly one language: build single-language and skip every MULTILINGUAL ONLY instruction. No i18n config, no locale folders, no switcher, no hreflang, no dictionaries. Copy lives in the page components as before. - A language name you cannot resolve to an ISO 639-1 code, or a duplicate in the list: drop it, build the ones you resolved, and say which you dropped and why in ASSUMPTIONS. Never guess a code. - A locale whose script your chosen faces cannot cover and no acceptable family covers all of them: keep the display face for the scripts it serves, give that locale a system stack for its script, and record the split in DESIGN.md decision 4. Never ship tofu, and never let one locale silently demote the whole site's type to a fallback face. - npm install fails: retry once; if it fails again, stop and report the exact error. Do not hand-write node_modules or vendor packages. - Never delete or overwrite anything outside the project directory you created. Never add analytics or trackers. Never fetch stock photos or external images.

Why this works

The prompt classifies any profession into one of four closed categories, and the classification drives a fixed contract: page set, section order, conversion mechanics, schema.org type, and required disclaimers. Structure stays interchangeable run to run while the aesthetics deliberately do not: the run argues its way to one of six art-direction archetypes, each carrying its own palette logic, type register, layout silhouette and motion vocabulary, with the convergent AI-design defaults named and banned outright. Hero treatment is tiered by category, so a growth advisor gets a WebGL canvas and an emergency plumber gets a phone number above the fold instead. Sample testimonials render fully styled but carry a one-line caption so nobody ships fake reviews, and the run is not done until the build exits clean, every route answers 200, and the pages have been looked at in a real browser.