Design a three-screen onboarding for a fitness app

## Role and objective
You are a product designer creating a three-screen onboarding flow for a fitness app. Produce a screen-by-screen design specification for the app’s intended users, whose audience is "[FILL IN: audience]". Keep the flow limited to exactly three onboarding screens and make the user’s intended outcome "[FILL IN: onboarding goal and primary user action]". Treat "[FILL IN: app name and brand description]" as unconfirmed until supplied; do not invent a brand identity, feature set, or user promise. The output must follow the required screen-list, component, state-behaviour, and design-token structure. Completion means every one of the three screens has its components, interactions, loading/empty/error behaviour, accessibility details, and responsive rules, with no unsupported product facts.

## Scope and given facts
In scope:
- A fitness app onboarding flow.
- Exactly three screens.
- Screen content, components, navigation, states, accessibility, responsiveness, and design tokens.
- A WCAG 2.2 AA accessibility target.
- A question about whether ADA Title III or Section 508 governs the audience.
- Layout behaviour at 200% zoom and a 320px viewport.
- Explicit US date, number, currency, and address formats where those data types appear.

Out of scope:
- Adding screens beyond the three-screen onboarding.
- Inventing the app name, logo, brand colours, exercises, health claims, subscription terms, user demographics, or backend capabilities.
- Writing production code or a complete visual asset package.
- Assuming that ADA Title III or Section 508 applies without confirmation.

Fill these slots only with user-provided or verified project information:
- "[FILL IN: app name and brand description]" — provide the approved name, brandAnchor wording, visual identity, and fixed brand constraints.
- "[FILL IN: onboarding goal and primary user action]" — state the intended completion outcome and main action.
- "[FILL IN: audience and governing accessibility regime]" — identify the audience and confirm whether ADA Title III, Section 508, another regime, or no specified regime governs.

## Working rules
Design exactly three screens. Assign each screen a distinct onboarding purpose. If the onboarding goal is supplied, map the three screens directly to that goal; if it is not supplied, keep the purpose of each screen provisional and label the missing goal rather than choosing one arbitrarily.

Preserve any supplied brandAnchor wording exactly wherever it is used. If no brandAnchor is supplied, use neutral placeholders such as "[FILL IN: approved brand treatment]" and do not create colours, typography, imagery, or slogans as confirmed facts.

For every screen, judge:
1. Whether the primary action is visible, understandable, reachable, and different from secondary actions.
2. Whether the content needed to continue appears before the action.
3. Whether the flow explains progress without implying a number of steps beyond three.
4. Whether controls have visible labels, focus order, keyboard operation, touch-friendly interaction, and screen-reader names.
5. Whether loading, empty, and error states explain what is happening and what the user can do next.
6. Whether the layout remains usable at 200% zoom and at a 320px viewport with no horizontal scrolling.

Use WCAG 2.2 AA as the accessibility target. Ask for confirmation of "[FILL IN: governing accessibility regime]" and identify whether ADA Title III or Section 508 governs the audience; do not assume either regime applies. If date, number, currency, or address inputs appear, state the exact US format for each relevant field. If none appears, say that the format is not applicable rather than adding an input.

Treat unconfirmed details as slots. Do not claim that a design improves retention, conversion, safety, health outcomes, or performance unless verified evidence is supplied.

## Output structure
Order the response as follows:

1. **Screen list** — list exactly three screens. For each, provide its provisional or confirmed purpose, entry condition, exit condition, primary action, secondary action if needed, and relationship to the overall onboarding goal. Do not add a fourth screen, modal, or separate onboarding step.
2. **Components per screen** — for each screen, list the hierarchy of content and interface components, including headings, explanatory text, progress indication, fields, buttons, navigation, imagery, and permission prompts only when justified by supplied facts.
3. **Behaviour per state** — for each of the three screens, specify default, loading, empty, error, success, focus, keyboard, screen-reader, back-navigation, and validation behaviour as applicable. State the user-visible message, recovery action, and whether progress is preserved. If a state is not applicable, mark it "Not applicable" with a reason.
4. **Design tokens** — provide colour, type, spacing, shape, elevation, motion, focus, and responsive tokens. Use "[FILL IN: approved token]" for values not supplied. Include contrast intent for WCAG 2.2 AA without inventing measured ratios.
5. **Responsive and accessibility decisions** — state how the three screens survive 200% zoom and a 320px viewport without horizontal scrolling, and list keyboard operation, focus order, visible focus treatment, and screen-reader labels.
6. **Open decisions** — list only unresolved slots and the information needed to fill each one.

## Style rules
Use a hybrid style. Use numbered and bulleted lists for the screen inventory, components, states, tokens, and verification details. Use short narrative paragraphs only for the flow rationale and accessibility rationale. Keep the register professional, direct, and supportive without motivational fitness clichés, exaggerated transformation language, shame-based wording, or unexplained design jargon.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification
1. Confirm that the deliverable contains exactly three onboarding screens and no extra onboarding step disguised as a modal, interstitial, or separate flow.
2. Confirm that every screen is clearly tied to the fitness app onboarding goal, or that the missing goal remains a named slot.
3. Confirm that the app name, brand description, brandAnchor, features, health claims, and visual values were not invented beyond the input.
4. Confirm that "[FILL IN: app name and brand description]", "[FILL IN: onboarding goal and primary user action]", and "[FILL IN: audience and governing accessibility regime]" were not filled with arbitrary values.
5. Confirm that loading, empty, and error behaviour appears for each screen, with "Not applicable" and a reason where a state truly cannot occur.
6. Confirm that keyboard operation and screen-reader labels are specified for interactive elements on all three screens.
7. Confirm that the design targets WCAG 2.2 AA and explicitly asks whether ADA Title III or Section 508 governs, without assuming either one.
8. Confirm that 200% zoom and a 320px viewport are addressed with no horizontal scrolling.
9. Confirm that US date, number, currency, and address formats are specified only when those data types appear.
10. Confirm that the output uses the required sections: screen list, components per screen, behaviour per state, and design tokens.
11. Confirm that no production code, unsupported product capability, extra screen, invented metric, or out-of-scope feature was added.
12. Confirm that any unresolved decision is listed in Open decisions with the exact information needed to resolve it.