The kickoff call is the foundation of every build. Everything that follows — the brief, the build, the SEO strategy — depends on the quality of information gathered here. The call should run 45 minutes. Do not rush it. A thorough kickoff prevents revision loops later.

Before the Call

Look up the client's existing website (if they have one) and spend 10 minutes reviewing it. Note the services they list, the cities they mention, and any obvious gaps or outdated content. This preparation allows you to ask better questions and catch inconsistencies during the call.

Call Structure (45 Minutes)

Design Sliders

Ask the client to score each slider from 1 to 10. Record all six scores. See the Design Standards appendix for how these scores translate into specific font, color, and layout decisions during the build.

Logo — What to Do If Not Available

Ask for PNG or SVG. If the client does not have a logo file ready, follow this decision tree:

Client Brief Fields

Every field in the client brief must be filled before leaving this step. Do not leave any field blank. If the client does not know the answer, note "TBD — follow up" and schedule a follow-up before Step 5.

If the client has an existing website, extract all usable content before it is replaced. This step ensures no copy, imagery, or data is lost during the transition. Even a poorly designed old site often contains accurate business information that would take hours to re-gather.

Asset Handoff Protocol — How Files Move Forward

All scraped assets must be saved in a defined location before Step 5 begins. This is the asset handoff — the link between content scraping and the build. Use this protocol exactly so there is never ambiguity about where files are.

These files live in the client's project folder on the build machine. When Claude Code starts the build in Step 6, the assets are already in place at known paths.

Scraping Method

Use Claude Code to run the scraper. Open the client project repo in Claude Code and run the following command:

Please scrape the following website and extract all content for a rebuild:
[CLIENT WEBSITE URL]

Save all assets to the /assets/ folder using this structure:
- /assets/copy/[page-name].md — all page copy as markdown
- /assets/images/ — all images, converted to WebP where possible
- /assets/logo/ — logo files as PNG and SVG if available
- /assets/brief.md — business name, phone, address, hours, service area
- /assets/testimonials.md — all testimonials with reviewer names and sources

Also provide a /assets/inventory.md summary of what was found and
what was missing or inaccessible (blocked pages, JS-rendered content, etc.).

Cross-reference the business info against this client brief and flag
any discrepancies: [PASTE CLIENT BRIEF FROM STEP 1]

Image Sourcing — Clients Without Photos

When a client has no photos or the existing site has unusable images, use stock photography from these approved sources in this priority order:

If the Client Has No Existing Website

Skip the scrape. Use the client brief from Step 1 as the sole content source. Create the /assets/brief.md file manually from the KO call notes. Note in the inventory that no existing site was available. Proceed to Step 3.

Site Inventory Checklist

Before any build work begins, you need access to the client's domain registrar. DNS changes are required at launch (Step 16), and discovering access problems on launch day creates delays and client frustration. Resolve access now.

Domain Registrar Access

Ask the client: "Who manages your domain — where did you originally register it?" Common registrars include GoDaddy, Namecheap, Google Domains (now Squarespace), Network Solutions, and Bluehost.

What to Document

GitHub Repo Setup

Create the client's GitHub repo now so it's ready when the build starts. All client sites live under the dotcomdesigniowa GitHub organization.

Cloudflare Pages Setup

Create the Cloudflare Pages project now. Connect it to the GitHub repo and configure it for the static site.

The preview URL will be https://[project-name].pages.dev — save this for Step 13.

New Domains

If the client does not have a domain yet, register one through Namecheap or Cloudflare Registrar. Use the client's business name as the basis. Confirm the domain with the client before purchasing. Document the registrar credentials immediately after registration.

The SEO strategy produces the keyword-city matrix that drives the entire site architecture. Every service page and location page built in Step 6 corresponds to a row in this matrix. The strategy must be completed and approved by the client before the brief is locked.

How to Run the SEO Strategy

Navigate to the SEO Portal at seo.dotcomdesignops.com and click "Build New Strategy." Enter the client's website URL and plan level. The system will run automatically and produce a live strategy site within 5 minutes.

What the Strategy Produces

Client Approval — Required Before Step 5

Send the client the live strategy site URL with this message:

Subject: Please Approve Your SEO Strategy — [Business Name]

Hi [Client Name],

Before we begin building your website, we need your approval on the
SEO strategy. This determines which pages get built and which keywords
and cities your site will target.

Please review your strategy here:
[STRATEGY SITE URL]

Check that:
- The services listed match what you offer
- The cities listed are the markets you want to target
- The combination count matches your plan level

Reply "Approved" to move forward, or let us know any changes needed.
We need your approval before we can start building.

[Your name]

Plan Levels Reference

The build brief is the single document that drives the entire Claude Code build session. A well-written brief produces a site that needs minimal revision. A vague or incomplete brief produces a site that requires multiple revision loops. Invest the time here.

Brief Anatomy — 10 Required Sections

Slider Score Translation Guide

In Section 4, translate each slider score into specific design decisions. Do not leave this as raw numbers — give Claude Code explicit instructions derived from the scores.

Content Inventory — Pages on the Existing Site

Before finalizing Section 10 of the brief, review the page list from the /assets/inventory.md file created in Step 2. For each page found on the old site, decide: Include (carry into the new build) or Archive (intentionally drop). Document this decision in Section 10.

AI Friendliness Data Requirements

All 12 items below must be populated in Section 8 of the brief. If any are missing, the brief is incomplete. These data points feed the AI audit at Step 11 — missing them requires rework.

The site build is executed in Claude Code using the static HTML/CSS/JS stack. Claude Code builds the full site based on the brief. Your role during the build is to review output as it comes in, catch issues early, and provide corrections before the full site is assembled.

Build Stack — Non-Negotiable

Formspree Setup

Required Pages

Homepage SOP — 10 Required Sections in Order

1. Navigation bar — Logo, all main nav links, phone number as CTA button. Sticky on scroll. Max 5 nav items.
2. Hero section — H1 with primary keyword, subheadline, primary CTA button (phone), secondary CTA (contact form). Full-width background image with dark overlay.
3. Trust bar — Years in business, license number, service area, key differentiators. Icon + stat pairs. Quick Facts / At a Glance format (AI Factor 15).
4. Services overview — Grid of service cards. Each card links to the corresponding service page.
5. About teaser — 2–3 sentences about the company, photo of owner or team, link to full About page. Must include owner name and one expert quote (AI Factor 27).
6. Gallery teaser — 3–6 photos in a grid. Link to full Gallery page. Skip if no photos available.
7. Testimonials — 3–5 testimonials. Star ratings. Source attribution (Google, etc.). Swipe carousel on mobile.
8. Service area map or list — Embedded Google Map or list of all cities served in plain HTML text (required for AI Factor 19).
9. Contact CTA section — Brand-color background. Phone number in large type. Button linking to contact form. Never a plain paragraph.
10. Footer — Logo, nav links, phone, full address, hours, copyright year (auto-updating JS), license number, "AI Info" link. Dark background. Three-column desktop, stacked mobile.

About Page SOP — Required Sections

The About page carries the most E-E-A-T weight of any page on the site. It must contain all five sections below in this order.

1. Page hero — H1: "About [Business Name]" or "[Business Name] — [City]'s Trusted [Trade] Contractor." Subheadline with years in business. Real photo of owner or team as the hero background.
2. Owner profile — Owner name, title, years of experience, credentials (license, certifications), and a personal story paragraph (3–5 sentences minimum). Photo of the owner. This section is required for AI Factor 21 (Author Profiles) and E-E-A-T.
3. Our story — How the business was founded, what the mission is, what makes them different. 2–3 paragraphs. Must include the specific founding year.
4. Why choose us — 3–4 differentiators in a visually distinct layout (icon grid, numbered list with large numbers). Must be substantively different from the homepage trust bar.
5. Contact CTA — Same visually distinct CTA section as interior pages. Phone number in large type. Button to contact form.

Person JSON-LD schema for the business owner is required on this page. See AI Factor 22 in Step 6's completion gate.

Contact Page SOP — Required Elements

1. Page hero — H1: "Contact [Business Name]" or "Get a Free Estimate." Subheadline with response time (e.g., "We respond within 24 hours").
2. Contact form — Fields: Name (required), Phone (required), Email (required), Service Needed (select dropdown with all services), Message (textarea), "How did you find us?" (select dropdown — required for AI Factor 32). Submit button full-width on mobile, uses brand primary color.
3. Contact details column — Phone (tap-to-call link), full address (links to Google Maps), business hours (day-by-day), email address.
4. Map embed — Google Maps iframe showing the business location. Responsive width.

Interior Page SOP — 9 Required Sections

1. Page hero — H1 with exact keyword + city. Subheadline. CTA button. Relevant, high-quality image. See Hero Image Standards below.
2. Intro section — 2–3 paragraphs of unique copy. First paragraph must define the service in plain language (AI Factor 18). No walls of text. No copy from other pages.
3. Services list — Styled cards or icon+text pairs. Minimum 3 items. Each with title and 1–2 sentence description.
4. Why choose us — 3–4 differentiators in a layout visually distinct from the services list.
5. Gallery or photo — At least one relevant image with descriptive alt text including keyword.
6. Testimonial — At least one styled card with star rating, reviewer name, and source. Never plain text.
7. Contact CTA — Brand-color background section. Phone in large type. Button to contact form.
8. FAQ section — Minimum 5 FAQs in a styled accordion. Each question is a clickable toggle. FAQPage JSON-LD schema required.
9. Internal links — At least 2 links to related service pages or location pages.

Location Page Uniqueness Requirement

Location pages are the most likely to be penalized for near-duplicate content. Each location page must have at least one unique element generated through this research process:

Hero Image Standards

Mobile SOP — Minimum Requirements

Mobile Self-Review Checklist — Before Marking Step 6 Complete

Claude Code must complete this checklist at 375px viewport width before the build is considered done.

AI Friendliness & Audit Build Requirements

Build to pass all four audits from line one. See the System Standards appendix for the complete 32-factor AI Friendliness framework and all four audit standards. The Build Prompt Template contains the full AI Friendliness instruction block to paste into Claude Code.

robots.txt — required exact content:

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GoogleOther
Allow: /

User-agent: Anthropic-AI
Allow: /

Sitemap: https://[DOMAIN]/sitemap.xml

Visual QA is a systematic page-by-page review at three viewports: mobile (375px), tablet (768px), and desktop (1200px). Every page is checked. No page is skipped. Issues found here are fixed before moving to Technical QA. For the full visual quality benchmark, see the Design Standards appendix and the Beautiful Checklist.

Visual QA Checklist — Every Page

Homepage-Specific Checks

Technical QA checks the underlying code and infrastructure — things invisible in a visual review but affecting performance, accessibility, and indexing. Run these checks against the live Cloudflare Pages preview URL.

The SEO readiness audit verifies every on-page SEO element is correctly implemented. This is a confirmation pass — all items should already be in place from Step 6. Cross-reference against the SEO matrix from Step 4.

Schema Validation

Validate schema using Google's Rich Results Test at search.google.com/test/rich-results. Paste the preview URL. Confirm zero errors for LocalBusiness and FAQ schema on the homepage and at least two interior pages.

Run all four audits — PageSpeed Insights, W3C HTML Validation, WAVE Accessibility, and DD AI Audit. Test the homepage, one service page, and one location page. Record all scores. Fix all failures before proceeding.

Score Targets

Common Performance Fixes

Run the DD AI Audit tool to confirm all 32 factors pass. Sites built following the full 32-factor requirements in Step 6 should arrive at this audit already passing. This is a confirmation pass, not a discovery pass.

How to Run

Navigate to ai-audit.dotcomdesignops.com, enter the live Cloudflare Pages preview URL, and click "Audit Site." Also run aifriendliness.com as a secondary technical validator (live PageSpeed, schema validation, Flesch-Kincaid, Core Web Vitals).

llms.txt Template

# [Business Name]

[Business Name] is a licensed [trade] contractor based in [City, State].
We serve [primary service area] and surrounding communities.

## Services
[List all services, one per line]

## Service Area
[List all cities served, one per line]

## Contact
Phone: [phone number]
Address: [full address]
Hours: [business hours]
Website: [domain]

## About
[2-3 sentences: years in business, owner name, mission]

## License & Insurance
[License number, bonding status, insurance status]

## FAQ
Q: [common question]
A: [direct answer]
[repeat for 4+ FAQs]

Content QA is a final human review of all copy on the site before the client sees it. You are reading every page — not skimming. This step catches factual errors, generic AI copy, and inaccurate business information.

Before sending the site to the client for review, confirm the Cloudflare Pages preview URL is live and tested. The Cloudflare Pages URL (https://[project].pages.dev) is what you send in the client review email. Do not send the client a localhost link or a screenshot.

Deployment Confirmation Steps

1. Confirm the latest Git push has deployed: check the Cloudflare Pages dashboard for a green "Success" build
2. Test the preview URL in an incognito window to confirm it loads correctly with no cache
3. Test the preview URL on a real mobile device (not just browser dev tools)
4. Submit a test contact form from the preview URL and confirm receipt in Formspree
5. Copy and save the Cloudflare Pages preview URL — this is what goes in the client review email

Process Flags — Automated Hub Registration

After confirming the Cloudflare Pages build is live, call the In Flight /api/deploy-preview endpoint to register the project:

POST https://hub.dotcomdesignops.com/api/deploy-preview
Content-Type: application/json

{
  "projectSlug": "[in-flight-project-slug]",
  "previewUrl": "https://[cloudflare-project-name].pages.dev",
  "apiKey": "dd-ko-2024"
}

Manual fallback (if Hub is not available): Log the preview URL in the project record manually. Create the Marker.io website project manually using the preview URL. Register the Marker.io project on the Process Flags webhook manually.

Before the client ever sees the site, the Dotcom Design team completes a full internal review. This is a non-negotiable quality gate. The reviewer should be someone who did not build the site — fresh eyes catch issues builders miss. If the team is small, step away from the project for at least one hour before reviewing your own work.

Internal Review Checklist

Visual Quality

• Hero section: headline, subheadline, CTA button, and image all look correct on desktop and mobile
• Two-font system applied: display font on headings, body font on paragraphs
• All section backgrounds alternate correctly (white, light gray, dark/brand color)
• No broken images, missing icons, or placeholder text remaining
• Typography is consistent across all pages
• All buttons have correct labels and correct destinations
• The Beautiful Checklist (Design Standards appendix) — all 14 items pass

Content Accuracy

• Business name spelled correctly on every page
• Phone number correct and clickable (tel: link)
• Address correct on contact page and in footer
• Business hours correct and day-by-day
• All service names and descriptions match client brief
• No lorem ipsum or placeholder copy remaining anywhere
• Owner name, title, and bio correct on About page
• All testimonials are real and attributed correctly

Functional Review

• Navigation works on desktop and mobile — all links correct
• Mobile hamburger menu opens and closes correctly
• Contact form submits successfully (test with a real submission)
• All phone number links open the dialer on mobile
• All external links open in a new tab
• Gallery lightbox works correctly (if applicable)
• FAQ accordions open and close correctly
• No JavaScript console errors

Mobile Review (on a real device)

• All text is readable without zooming
• All buttons and tap targets are large enough to tap comfortably
• No horizontal scrolling on any page
• Sticky call bar displays correctly and does not overlap content
• Images load quickly and look sharp
• Testimonials swipe correctly in carousel

Send the preview URL to the client with clear instructions and a 48-hour response window. If no response within 48 hours, follow up once. If no response after 72 hours, proceed to Step 15 with zero revisions.

Client Review Email Template

Subject: Your New Website Is Ready for Review — [Business Name]

Hi [Client Name],

Your new website is ready for your review! Please take a look at the
preview link below and let us know if you have any changes.

Preview Link: [CLOUDFLARE PAGES URL]

How to review:
- Check all pages using the navigation menu
- Review on both your phone and your computer
- Check that all your services, contact info, and hours are correct
- Note any text changes, photo swaps, or additions you'd like

Please send all feedback by [DATE — 48 hours from now]. We'll make
your requested changes and then schedule the launch.

If everything looks great and you're ready to go live, just reply
"Approved" and we'll schedule the launch.

[Your name]
Dotcom Design

Scope of Revisions

The client is entitled to one round of revisions as part of the build. In-scope revisions include text corrections, photo swaps, and minor layout adjustments. Out-of-scope (separate project) includes: adding new pages, changing the design direction, rebuilding sections from scratch, or adding new integrations.

Implement all in-scope client revisions in Claude Code. After implementing, re-run QA on any pages that were changed based on the type of change made.

Revision Process

1. Work through the revision list item by item in Claude Code
2. Push changes to GitHub and confirm Cloudflare Pages preview updates (60–90 seconds)
3. Re-run QA on all changed pages based on change type (see table below)
4. Send the updated preview URL to the client with a note that revisions are complete
5. Request final written approval: "Please reply 'Approved' to proceed to launch"

Re-QA Requirements After Revisions

Go Live connects the client's domain to the Cloudflare Pages deployment. DNS propagation typically takes 5–30 minutes but can take up to 48 hours in rare cases.

Launch Sequence

1. In Cloudflare Pages, add the client's custom domain: Settings → Custom Domains → Add custom domain
2. Also add the www version: www.[clientdomain.com] — Cloudflare will redirect it automatically
3. Cloudflare will provide DNS records needed (CNAME pointing to pages.dev)
4. Log into the client's domain registrar (Step 3 credentials)
5. Add the CNAME record provided by Cloudflare Pages
6. If domain uses Cloudflare DNS already, the record is added automatically — confirm in Cloudflare
7. Wait 5–30 minutes for DNS propagation
8. Test the live domain in incognito: site loads, HTTPS active, no redirect loops, www redirects correctly
9. Submit sitemap to Google Search Console: search.google.com/search-console
10. Request indexing for the homepage in Google Search Console
11. Send "You're live!" email to client (see template below)

Go Live Email Template

Subject: Your New Website Is Live! — [Business Name]

Hi [Client Name],

Great news — your new website is officially live!

Your website: https://[clientdomain.com]

Your site has been submitted to Google for indexing and should
start appearing in search results within 1–4 weeks.

A few things to know:
- Your contact form is active and submissions will go to [email]
- We've set up monitoring so we'll know immediately if the site
  ever goes down
- Your next monthly SEO report will arrive on [date]

If you notice anything that needs adjusting, just reply to this
email and we'll take care of it.

[Your name]
Dotcom Design

Post-DNS Checks

Hub API Call (Go Live)

POST https://hub.dotcomdesignops.com/api/go-live
Content-Type: application/json

{
  "projectSlug": "[in-flight-project-slug]",
  "liveUrl": "https://clientdomain.com",
  "apiKey": "dd-ko-2024"
}

Within 24 hours of launch, set up uptime monitoring and verify Google has begun crawling the site. These steps take 30 minutes and provide ongoing protection.

Monitoring Setup

48-Hour Check

Return 48 hours after launch and verify:

1. Homepage loads correctly — no errors
2. Contact form still submits correctly from live domain
3. Google Search Console shows no new coverage errors
4. UptimeRobot shows 100% uptime since launch
5. Quick Google search for business name — confirm new site appears or indexing is in progress

The GBP must be updated to reflect the new website. NAP consistency between the website and GBP is a critical local SEO signal. This step is not optional.

GBP Update Checklist

The Quarterback Handoff transfers ownership of the client relationship from the build team to the ongoing account management team. The quarterback is responsible for the client's ongoing SEO, reporting, and relationship. A complete handoff ensures nothing falls through the cracks.

Handoff Package

Ongoing maintenance is the quarterback's responsibility from this point forward. The build team is no longer the primary contact. This page documents recurring maintenance tasks for every active client site.

Monthly Maintenance Tasks

Handling Update Requests

When a client requests a content update, the quarterback opens the client repo in Claude Code, implements the specific change, and pushes to GitHub. Cloudflare Pages auto-deploys within 90 seconds. The client is notified when the update is live.

Process Flags — Closed-Loop Improvement Workflow

Monthly Playbook Review

On the first Monday of every month, the build lead conducts a 30-minute system review:

1. The Four Audit Standards

2. The 32-Factor AI Friendliness Framework

🔧 Pillar 1: Technical Infrastructure (7 Factors)

📝 Pillar 2: Content Structure & Extractability (12 Factors)

🏆 Pillar 3: Entity & Authority Signals (8 Factors)

🤖 Pillar 4: Strategic AI Assets (5 Factors)

3. robots.txt — Required Exact Content

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GoogleOther
Allow: /

User-agent: Anthropic-AI
Allow: /

Sitemap: https://[DOMAIN]/sitemap.xml

4. Tool Ecosystem & URLs

5. Change Protocol — Keeping Standards in Sync

When any standard changes, follow this protocol exactly. Never update one place and leave others stale.

1. Update this page first (System Standards — the source of truth)
2. Update the relevant Playbook step page
3. Update the Build Prompt Template page if the standard affects what gets built
4. Update the Claude Code Workflow page if the standard affects how a build starts
5. Update CLAUDE.md in the playbook repo
6. Commit all changes to git and confirm Cloudflare Pages deploys the update
7. Verify the live production URL reflects the change

Every site we build must be beautiful. This is a defined, measurable standard — not a subjective aspiration. A site that passes all four audits but looks generic or amateur does not meet the Dotcom Design standard. This page defines exactly what beautiful means so Claude Code can apply it consistently without being asked.

Slider Score → Design Decision Translation

The six slider scores from Step 1 translate directly into the following design decisions. Claude Code reads these from Section 4 of the brief and applies them throughout the build.

Typography Pairing Rules

Every site must use a two-font system. Never use a single font for both headings and body text. Never use more than two font families on a single site.

Spacing Scale — Use ONLY These Values

Color Application Rules

Component Quality Benchmarks

The "Beautiful" Checklist — 14 Items

This checklist is used in Step 7 (Visual QA). Every item must pass before Visual QA is marked complete. These 14 items are the definition of "beautiful" for a Dotcom Design site.

Cloudflare

GitHub

Formspree

Marker.io Webhook — In Flight Process Flags

Every new website build is executed in Claude Code. This page defines the exact opening workflow to use at the start of every build session. Using the correct opening ensures Claude Code loads the right context and produces consistent, audit-ready output from line one.

Before Opening Claude Code

1. Confirm the client's GitHub repo exists under dotcomdesigniowa (created in Step 3)
2. Confirm the Cloudflare Pages project is connected to the repo (Step 3)
3. Confirm the complete 10-section brief is finalized (Step 5)
4. Confirm all assets are in the /assets/ folder (Step 2)
5. Confirm CLAUDE.md exists in the repo root (see below)

CLAUDE.md — Required in Every Client Repo

Every client repo must have a CLAUDE.md file in the root. This file tells Claude Code the project context, build standards, and audit requirements before it touches any code. Create this file before the first Claude Code session.

# CLAUDE.md — [Business Name] Website

## Project
- Client: [Business Name]
- Domain: [clientdomain.com]
- GitHub: dotcomdesigniowa/[client-slug]-website
- Cloudflare Pages: [project-name].pages.dev
- Plan Level: [SEO Booster / Plan A / B / C / D / E]

## Stack (NON-NEGOTIABLE)
- Pure HTML5, CSS3, vanilla JavaScript — no frameworks
- No Bootstrap, no Tailwind, no React, no jQuery
- All images: WebP format with explicit width/height attributes
- Fonts: Google Fonts CDN with preconnect + display=swap
- Forms: Formspree at https://formspree.io/f/[form-id]
- Hosting: Cloudflare Pages via GitHub push

## Audit Standards (build to pass from line one)
- W3C HTML Validator: 0 errors
- WAVE Accessibility: 0 errors, 0 contrast errors
- PageSpeed Insights: 90+ mobile performance, 95+ desktop
- DD AI Audit: 32/32 factors at ai-audit.dotcomdesignops.com

## Key Build Rules
- See the full Dotcom Design Playbook at [playbook URL] for all SOPs
- One H1 per page. H2/H3 in sequential order, never skipped.
- Every img has descriptive alt text
- Every form input has an associated label
- hero image: fetchpriority="high" loading="eager"
- All other images: loading="lazy"
- All scripts: defer or async
- robots.txt must allow GPTBot, ClaudeBot, PerplexityBot, GoogleOther, Anthropic-AI
- llms.txt must exist at /llms.txt
- /ai disclosure page must exist and be linked in footer

## Asset Locations
- Logo: /assets/logo/
- Images: /assets/images/
- Copy: /assets/copy/[page-name].md
- Business info: /assets/brief.md
- Testimonials: /assets/testimonials.md

Opening Prompt — Use at the Start of Every Build Session

Open the client repo in Claude Code. This is the first message to send every time you start a build session. Replace the bracketed fields with the actual client info.

You are building a client website for Dotcom Design.

Start by reading:
1. CLAUDE.md in this repo root — the project-specific build context
2. /assets/brief.md — the complete client brief
3. /assets/inventory.md — the content inventory from the old site

After reading all three files, confirm you have read them and summarize:
- Client name and domain
- Plan level and approximate page count
- Any questions or ambiguities before we start building

Do not write any code yet. Confirm you understand the project first.

Build stack: Pure HTML5, CSS3, vanilla JS — no frameworks, no CMS.

AUDIT STANDARDS — build to pass all four from the first line of code:
- W3C HTML Validator: 0 errors (validator.w3.org)
- WAVE Accessibility: 0 errors, 0 contrast errors (wave.webaim.org)
- PageSpeed Insights: 90+ mobile performance (pagespeed.web.dev)
- DD AI Audit: 32/32 factors (ai-audit.dotcomdesignops.com)

These are build requirements. Never build first and fix later.
Build clean code once, not broken code that gets patched.

After the Opening Prompt

Wait for Claude Code to confirm it has read all three files and summarized the project. Then submit the full client brief from the Build Prompt Template. Do not submit the brief in the same message as the opening prompt.

During the Build

Stay engaged. Review output as it arrives. Catch issues early — a correction at page 2 is far cheaper than a correction after all 30 pages are built. All four audits are build requirements. Claude Code builds to pass them from line one.

Useful Mid-Build Commands

Updating Existing Client Sites

For post-launch content updates, open the client repo in Claude Code and say:

Please read CLAUDE.md and the current index.html for context.

I need to make the following update to [Business Name]'s website:
[DESCRIBE THE SPECIFIC CHANGE]

After making the change:
1. Confirm the change looks correct
2. Verify it does not break any adjacent content
3. Commit to main with message: "update: [brief description]"
4. Confirm the Cloudflare Pages build completes successfully

This is the full 10-section client brief template. Fill in every field. Do not leave any field blank. Submit this as one complete message after the opening prompt confirmation.

## CLIENT BRIEF

### SECTION 1: CLIENT & PROJECT IDENTITY
Business Name (exact): 
Domain: 
Plan Level: [SEO Booster / Plan A / B / C / D / E]
GitHub Repo: dotcomdesigniowa/[client-slug]-website
Cloudflare Pages Preview URL: https://[project-name].pages.dev
Formspree Form ID: [form-id from Formspree dashboard]

### SECTION 2: BUSINESS OVERVIEW
Business Name (exact, for NAP): 
Phone Number: 
Address (full, with ZIP): 
Business Hours:
  Monday: 
  Tuesday: 
  Wednesday: 
  Thursday: 
  Friday: 
  Saturday: 
  Sunday: 
Years in Business: 
Jobs/Projects Completed: 
License Number(s): 
Bonded: Yes / No
Insured: Yes / No
Warranty Length (if applicable): 
Response Time (e.g., "same-day estimates"): 

### SECTION 3: SERVICES
Primary Services (most important first):
1. 
2. 
3. 
4. 
5. 
Secondary Services:
1. 
2. 
3. 

### SECTION 4: DESIGN DIRECTION
Design Sliders (1-10):
  Style (Classic → Modern): 
  Tone (Light → Dark): 
  Complexity (Simple → Rich): 
  Voice (Friendly → Authoritative): 
  Market Position (Economical → Premium): 
  Aesthetic (Polished → Gritty): 

Design Translation (derived from slider scores above):
  Font pairing: 
  Color scheme: 
  Section complexity: 
  Copy voice: 
  Layout approach: 
  Component style: 

Reference Site URL (a site they like): 
Color Preferences (if any): 
Font Preferences (if any): 

### SECTION 5: FEATURES & FUNCTIONALITY
Contact form fields: Name, Phone, Email, Service Needed (dropdown), Message, How did you find us? (dropdown)
Gallery required: Yes / No
  If Yes, photo count: 
Special integrations (booking, chat, etc.): 
Special pages requested (beyond standard): 

### SECTION 6: CONTENT ASSETS
Logo: /assets/logo/ (format: [PNG/SVG/wordmark fallback])
Photos: /assets/images/ (count: [N])
Copy: /assets/copy/ 
Business info: /assets/brief.md
Testimonials: /assets/testimonials.md (count: [N])
Team members: [Name, Title, Bio summary]
Owner name and title (for Person schema and About page): 

### SECTION 7: SEO & LOCAL STRATEGY
Primary City: 
Service Area (all cities/counties): 
[PASTE FULL KEYWORD-CITY MATRIX FROM SEO PORTAL HERE]

### SECTION 8: AI FRIENDLINESS DATA
Statistics (use these exact numbers on every page):
  Years in business: 
  Jobs/projects completed: 
  Warranty length: 
  Response time: 
  Service count: 
  Other notable stats: 

Citations (include as external links on every page):
  BBB Profile URL: 
  Google Business Profile URL: 
  License Verification URL: 
  Industry Association URL: 

Schema — required for LocalBusiness:
  Geo Latitude: 
  Geo Longitude: 
  Price Range (e.g., "$$"): 
  Area Served (all cities): 

FAQ Questions — provide 5+ per major page:
Homepage FAQs:
  Q: 
  Q: 
  Q: 
  Q: 
  Q: 
Primary Service Page FAQs:
  Q: 
  Q: 
  Q: 
  Q: 
  Q: 

### SECTION 9: AUDIT STANDARDS
Build this site to pass all four audits at Steps 10-11 with zero rework.
These are build requirements — implement them during the initial build.

W3C HTML (0 errors):
- Every page: 
- Every img: descriptive alt (never empty, never "image")
- Every input/select/textarea: associated 
- No duplicate id attributes
- One H1 per page, H2/H3 sequential, no skipped levels
- Semantic landmarks: 
, 
, 

Something goes wrong on every build. This appendix documents the failure paths for the most common problems and exactly what to do. The goal is never to improvise — consult this page first, follow the steps, and resolve the issue before advancing.

PageSpeed Score Below 90 (Mobile)

The most common failure. Do not guess — use PageSpeed's Opportunities section to identify the specific failing items.

WAVE Accessibility Errors

W3C HTML Validation Errors

DD AI Audit — Red FAIL Factors

Client Rejects the Entire Design Direction (Step 14)

This is rare but it happens. If a client says "I don't like the look of this at all" rather than providing specific changes, follow this process:

1. Do not make any changes yet. First, get specifics: "Can you help me understand what you were expecting that's different from what you see?"
2. If the issue is a specific element (colors, font, hero image), treat it as a standard revision — fix the specific element.
3. If the issue is the overall design direction, review the slider scores from Step 1. Ask: "Do the slider scores we agreed on still represent what you want?" If they've changed, update them and rebuild the brief Section 4 with the new slider translation.
4. A full design direction change is out-of-scope for the included revision round — document it as such, and either scope it as additional paid work or rebuild with updated slider scores as a goodwill gesture (your call based on the client relationship).
5. Never rebuild the entire site without a written revised brief. Make the client confirm the new direction in writing before rebuilding.

DNS Doesn't Propagate (Step 16)

Formspree Form Not Receiving Submissions

Escalation Protocol

If any issue cannot be resolved within 2 hours using this appendix:

1. Document the specific issue — what was tried, what the current state is, what error messages appear
2. Escalate to the build lead with the full documentation
3. If the issue is blocking launch, notify the client: "We've encountered a technical issue and are resolving it. Your site will be live by [specific time]." Never leave a client in silence.
4. Document the resolution in a Process Flag via Marker.io so it can be reviewed for Playbook updates