AI website prompt pack

How to use this

These prompts are written for Claude or another capable coding assistant working in a real project folder. Use them in order, one stage at a time, and read what comes back before moving on. The assistant is fast, but you are still the designer and the person responsible for what ships. Replace every [square bracket] with your project's details. The more specific you are, the better the result, so paste in your completed website specification brief wherever a prompt asks for project details.

A few habits that make every prompt work better:

• Start each new session by pasting the project context prompt (Stage 0), so the assistant knows the rules.
• Ask for one thing at a time. "Build the whole site" gets you a generic site.
• Ask the assistant to explain its plan before it writes code, and correct the plan first.
• Commit or back up your work after each stage that works, so you can roll back.
• Check costs and usage terms for whatever assistant you use. They change, so compare current terms yourself.

Stage 0: Project context (paste at the start of every session)

You are helping me build a website for a client. Here is the context.
Follow these rules for every task in this session.

Client: [Business name], a [type of business] in [city, state].
Main goal of the site: [primary goal, e.g. get phone calls and bookings].
Main visitor action: [call / book / fill in form].
Audience: [who they are, what device they mostly use].
Tone: [friendly / calm / professional].
Brand: colors [codes], fonts [names], logo at [path].

Tech: [plain HTML, CSS and a little JavaScript / the framework I am using].
Project folder structure: [describe or say "propose one"].
Hosting target: a static host.

Rules:
1. Mobile first. Every layout must work at 360px wide before anything else.
2. Use semantic HTML (header, nav, main, section, footer, one h1 per page).
3. Accessible by default: real labels on form fields, alt text on images,
   visible focus states, color contrast that meets WCAG AA for body text.
4. No placeholder lorem ipsum in final output. Where real text is missing,
   write a clear marker like [CLIENT TEXT: services intro].
5. Never invent facts about the business: no fake reviews, awards, years in
   business, prices or statistics. Leave a marker instead.
6. Keep dependencies minimal. Ask before adding any library.
7. Reuse components. Do not copy and paste the same block across pages.
8. Before writing code for a task, give me a short plan and wait for my OK.

Reply with "Ready" and a one paragraph summary of what you understood.

Stage 1: Plan the sitemap and page structure

Using the context above and this brief:

[paste the sitemap, features and content sections of your brief]

1. Propose the final sitemap as a list of pages with a one sentence purpose
   for each.
2. For each page, list the sections from top to bottom, and for each
   section say what it must achieve for the visitor.
3. Mark where the main call to action appears on each page.
4. List every piece of content we still need from the client.
5. Point out anything in the brief that is unclear or contradictory.

Do not write code yet.

Stage 2: Design tokens and base styles

Create the base styles for the site.

1. Define design tokens as CSS custom properties: colors (background,
   surface, text, muted text, primary, primary text, border, focus),
   a type scale of 5 to 6 sizes, spacing scale, border radius and
   maximum content width.
2. Set base typography: readable body size on mobile, comfortable line
   height, heading styles from h1 to h4.
3. Add a simple reset, sensible link styles, a visible focus outline, and
   a utility for visually hidden text for screen readers.
4. Check the text and primary colors for contrast and tell me the ratios.
   If any pair fails WCAG AA for its use, suggest an adjusted value.

Put this in [path, e.g. styles/base.css]. Explain any choice that is not
obvious.

Stage 3: Project scaffold

Set up the project scaffold.

1. Propose a folder structure for pages, shared components, styles, images
   and scripts. Wait for my OK.
2. Create a shared page layout with: skip to content link, header with logo
   and navigation, main area, footer with business name, address, phone,
   and links to legal pages.
3. Navigation must collapse into an accessible menu button on small
   screens. It must work with a keyboard and announce its open or closed
   state to screen readers.
4. Add a README explaining how to run the site locally and how to build it.

Keep it as simple as the project allows.

Stage 4: Reusable components

Build these reusable components, one at a time. After each one, stop and
show me how it is used.

[List, for example:]
* Hero: heading, short paragraph, primary button, optional image
* Service card: icon or image, title, two line description, link
* Call to action band: heading, sentence, button, phone link
* Testimonial block: quote, name, source (content supplied by client only)
* Contact details block: address, phone (click to call), hours, map link
* FAQ list: accessible expand and collapse

For each component:
* Accept content as inputs, never hard code the client's text inside it.
* Work from 360px wide upward.
* Use only the design tokens from Stage 2.
* Include the accessible attributes it needs.

Stage 5: Build one page at a time

Build the [page name] page using the layout and components we made.

Sections, in order:
[paste the section list for this page from Stage 1]

Content:
[paste the real text, or write "use markers where text is missing"]

Requirements:
* One h1 that says what this business does and where.
* The main call to action is visible without scrolling on a phone.
* Images have meaningful alt text, or empty alt if purely decorative.
* Unique page title (under about 60 characters) and meta description
  (under about 155 characters) written for this page.

When done, list anything you were unsure about.

Stage 6: Forms

Add the contact form to the [page] page.

Fields: [name, email, phone, message, preferred contact time].
Required fields: [list].
Submissions go to: [the form handling method or service I am using].

Requirements:
* Every field has a visible label, not only placeholder text.
* Error messages appear next to the field, in text, and are announced to
  screen readers.
* Use the right input types so phones show the right keyboard.
* Include basic spam protection that does not punish real users
  (for example a hidden honeypot field).
* Show a clear success message after sending.
* Add a short line near the button linking to the privacy policy.

Explain how I test that submissions actually arrive.

Stage 7: Search basics

Review the whole site for search basics and fix what you can.

Check and report on:
1. Every page has a unique title and meta description.
2. Heading order makes sense on every page (no skipped levels for styling).
3. Every image has appropriate alt text.
4. Internal links use descriptive text, not "click here".
5. There is a sitemap file and a robots file.
6. The business name, address and phone are consistent everywhere.
7. Add structured data for a local business with the details I give you:
   [name, address, phone, hours, URL]. Do not invent any field.

Give me a table of what you changed and anything I still need to provide.

Stage 8: Accessibility review

Act as a careful accessibility reviewer. Go through every page and
component and check:

* Keyboard: can I reach and use everything with Tab, Shift Tab, Enter,
  Space and Escape? Is focus always visible? Is the order logical?
* Screen readers: do landmarks, headings, labels and button names make
  sense when read aloud?
* Color: does all text meet WCAG AA contrast? Is color ever the only way
  information is shown?
* Motion: is any animation reduced when the visitor prefers reduced motion?
* Zoom: does the page still work at 200% zoom?

List every issue with the file, the problem and the fix, then fix them one
by one after I approve the list.

Stage 9: Performance review

Review the site for loading speed on a mid range phone with a slow
connection.

Check and fix:
* Images: correct dimensions, modern formats, lazy loading below the fold,
  width and height set to prevent layout shift.
* Fonts: limit the number of weights, preload only what is needed,
  use a font display setting that shows text quickly.
* CSS and JavaScript: remove anything unused, defer scripts that are not
  needed for the first view.
* Third party embeds: load maps, videos and chat widgets only when needed.

Tell me what you changed and how I can measure the difference myself with
a free page speed testing tool.

Stage 10: Pre launch test pass

Help me test the site before the client sees it.

1. Write a test checklist for this specific site, covering every page,
   form, link and feature in the brief.
2. Find any broken internal links, missing images or console errors.
3. List every remaining content marker like [CLIENT TEXT: ...].
4. Check the site at 360px, 768px and 1280px widths and report anything
   that overflows, overlaps or looks broken.

Do not fix anything yet. Give me the list first.

Use the launch QA checklist alongside this.

Stage 11: Deploy preparation

Prepare this site for deployment to a static host.

1. Tell me the exact build command and output folder.
2. Set up redirects from these old URLs to the new ones:
   [old URL to new URL list].
3. Add a custom 404 page that matches the design and links home.
4. List the DNS records I will need to point [domain.com] at the host,
   and warn me about any existing records I must not remove, such as
   email records.
5. Write a short rollback plan: how I put the previous version back if
   something goes wrong after launch.

Do not change any DNS or hosting settings yourself.

Stage 12: Handoff notes for the client

Write plain English handoff notes for the client, who is not technical.

Include:
* What the site includes, page by page, in one line each.
* How to request a change, and what counts as a small change.
* Which accounts they own (domain, hosting, analytics, form service) and
  that they should keep those logins safe.
* What to do if the site looks broken.
* What the maintenance plan covers, using this scope: [paste scope].

Keep it under one page. No jargon. Where a term is unavoidable, explain it
in a few words.

Fixing a bug

Something is wrong. Here is what I see:
[describe exactly what happens, on which page, device and browser]

Here is what I expected:
[describe]

Here is the error message, if any:
[paste]

Before changing any code: explain the most likely cause, tell me which
files are involved, and suggest the smallest fix. Wait for my OK.

Making a change without breaking things

I need to change [describe the change].

1. List every page and component this change could affect.
2. Make the change.
3. Tell me exactly what I should check by hand on each affected page to
   be sure nothing else broke.

Checklist for each stage

• I read the plan before letting the assistant write code
• I checked the result in a browser, on a phone sized screen
• No invented facts, reviews or numbers appeared in the content
• I backed up or committed the working version
• I wrote down anything to come back to