client-intake-builder git:20260611.809260eA

Immutable. This exact content never changes and is served at /api/v1/blob/cfd3036f7370198a.

---
name: client-intake-builder
description: Generate a branded, single-file HTML client intake questionnaire for any service business. Picks the right question set (brand identity, web design, automation project, or pre-call brief), styles it with the project's brand colours and fonts, and includes validation, progress, and a success state. Pairs with php-form-mailer to make it send email. Use when the user says "intake form", "client questionnaire", "project brief form", or "onboarding form".
---

# Client Intake Builder

You build the form a client fills in before the first real conversation. A good intake questionnaire does two jobs at once: it gathers the answers the project actually needs, and it shows the client they are dealing with a professional before any work begins. The form is part of the brand.

## Step 1: Establish the brief

Ask (or take from the request):

1. **Service type**, which selects the question bank:
   - `brand` for brand identity / logo projects
   - `web` for website projects
   - `automation` for automation / systems projects
   - `precall` for a short pre-call brief before a discovery call
2. **Brand styling**: if the project folder has a site or brand CSS, read the colours and fonts from it. Otherwise ask for 2 or 3 brand colours, a font preference, and the business name for the header.
3. **Anything unusual to ask** beyond the standard bank.

## Step 2: Plan the questions

Build sections A to E from the bank for the chosen type. Keep the total under 20 questions; an intake form that takes more than 10 minutes does not get finished.

### Question banks

**brand**: A. The business (name, what it does, years active) · B. The project (new brand or rebrand, what triggered it, deadline) · C. Audience and market (ideal customer, main competitors, how they differ) · D. Taste (3 brands they admire and why, words their brand should and should not feel like, colour likes/dislikes) · E. Logistics (budget range as radio bands, decision maker, how they found you)

**web**: A. The business · B. The site (purpose, must-have pages, current site and what fails about it) · C. Content (who writes copy, what exists, photography) · D. Taste (3 sites they like and why, features seen elsewhere) · E. Logistics (budget bands, deadline, hosting/domain status)

**automation**: A. The business · B. The pain (the repetitive task, hours per week it costs, who does it now) · C. The stack (tools in use, where the data lives, what must not change) · D. The win (what done looks like, how they would measure it) · E. Logistics (budget bands, urgency, technical contact)

**precall**: One short section, 6 questions max: what they need, what prompted it now, timeline, budget band, decision maker, anything they want you to see before the call.

Every multiple-choice question gets explicit `value` attributes plus human-readable labels, so a mail handler can map them later.

## Step 3: Generate the HTML file

One self-contained file: `intake-<type>.html`. Requirements:

- All CSS and JS inline. The only allowed external request is a Google Fonts link if a webfont was chosen; offer a system-font fallback for zero external requests.
- Branded header with the business name, the section structure A to E with visible progress, and a closing reassurance line about confidentiality.
- Every input has a `<label>`, required fields are marked, and the form validates name and email in JS before submit.
- A hidden honeypot field named `website` for spam protection.
- A styled success state that hides the form on submission.
- Mobile-first layout, readable at 360px wide, keyboard navigable, `prefers-reduced-motion` respected if anything animates.
- No analytics, no trackers, no external JS.

The form `action` is left as a clearly marked placeholder.

## Step 4: Wire it up

The form needs a backend to send email. If the `php-form-mailer` skill is installed, offer to run it on the generated file next. Otherwise point the user at the placeholder `action` and the README of their form backend of choice.

## Rules

- Never invent the user's services, prices, or budget bands. Budget radio bands come from the user.
- Ask for brand colours once; never default to a generic template look if brand assets exist in the project.
- Keep the client's perspective in the microcopy: questions in plain language, no industry jargon the client will not know.
- The intake answers are client-confidential by design. Do not add features that send data anywhere except the user's own form handler.