Create a complete, implementation-ready page specification: layout, components with Object IDs,
multilingual content, interactions, states, validation, spacing, and typography.
All 9 steps must be completed in sequence before the specification is considered done.
Validation runs at step 9 before the spec is written to disk.
Read the design log at {output_folder}/_progress/00-design-log.md before starting.
Check Current table for any in-progress work from a previous session.
Load page context from the existing page folder:
{output_folder}/C-UX-Scenarios/[NN-slug]/pages/[NN].[step]-[page-slug]/
The page boilerplate created in Phase 3 contains scenario, page number, platform,
page purpose, entry context, exit action, and on-page interactions.
Update the design log Current table: add this page with status "specifying".
Present the page basics form to the user and collect all required fields:
- Page name/title
- URL/route (if applicable)
- Main user goal (one sentence)
- Entry points (where users come from)
- Exit points (where users go next)
For public pages, also collect SEO data — check the project brief's SEO Strategy for target keywords:
- Primary keyword
- Secondary keywords
- URL slug (from keyword map)
Store all captured values as page_basics:
page_title, url_route, user_goal, entry_points, exit_points,
primary_keyword (public pages), secondary_keywords (public pages), url_slug (public pages).
Ask the user to describe the major areas of the page (header, hero, main content, sidebar,
footer, etc.). Do not define individual components yet — only high-level sections.
For each section described, store:
- section_name
- section_purpose
- section_priority (primary / secondary)
Confirm the section list with the user before proceeding.
Work through each section identified in step 2. For each section, go top-to-bottom,
left-to-right. Ask the user to describe the next object in the section.
For each object described, load and execute the object router:
data/object-types/object-router.md
The router will: ask for object type, load the correct object-type template, guide through
complete documentation, generate a specification with an Object ID, then return here.
After each component specification is complete, check project config:
if design system is enabled, run workflows/wds-7-design-system/design-system-router.md
to check for similar components and extract component-level info. Update page spec with
the reference. If design system is disabled, keep the full specification on the page.
Continue until the user confirms all objects in the section are documented.
Move to the next section. Continue until all sections are complete.
Present a summary: sections processed, total components, components by type, all Object IDs assigned.
Ask the user what languages this page supports. Store as supported_languages array.
For every text element on the page (labels, buttons, headings, messages, placeholders,
error text — derived from the component list), ask the user to provide content in every
supported language. Primary language first, then each additional language.
Store multilingual_content keyed by element and language.
No text element may have content in only a subset of languages — full coverage is required.
For each interactive component in the registry (from step 3), ask the user what happens
when the user interacts with it. Cover: on click / on input / on focus,
immediate response, state changes, navigation (if applicable), data sent/received.
Store interaction_behavior keyed by Object ID. Do not generate behaviors without
user input — ask for each component individually.
Do not define visual states in this step — that is step 6.
Define page-level states first. Ask the user to describe each situation:
default/loaded, empty (no data), loading (fetching), error (something went wrong),
success (after action completes). For each: when it occurs, what user sees, available actions.
For each component with multiple possible appearances, ask the user to define applicable states:
default, hover, active/pressed, focus, disabled, loading, error, success.
Only specify states that actually apply to each component.
Store page_states and component_states.
Do not define validation rules in this step — that is step 7.
Identify all fields and inputs that require validation. For each, ask:
- What makes it valid / invalid?
- Required or optional?
- Format rules and length limits?
- Custom rules?
- Validation timing: on blur, on submit, or real-time?
For each validation rule, define error messages in ALL supported languages.
Assign an error code (e.g., ERR_EMAIL_INVALID) to every message.
Store validation_rules and error_messages per field, with codes and translations.
Do not generate the specification document yet — that is step 9.
Proceed with full validation definition. Every input field must have rules and error messages.
No validated fields on this page. Store an empty validation_rules object and note
"No form inputs on this page" before proceeding to step 8.
Walk through adjacent section pairs top-to-bottom. For each pair, ask the user which
spacing token applies. Present the full table of gaps at once for efficiency.
Available tokens: zero, sm, md, lg, xl, 2xl, 3xl.
Zero-spacing is an intentional design choice — document it, never skip it.
Store spacing objects using naming convention:
- {page-slug}-v-space-{size} for vertical spacing
- {page-slug}-v-separator-{size} for lines/dividers with spacing
Also capture grid gaps for sections with repeated items (card grids, lists).
For each heading in the content (from step 4), define typography tokens.
Collect from the user: semantic tag (h1/h2/h3) and visual size per breakpoint
(mobile / tablet / desktop).
Available heading tokens: heading-xxs (14px), heading-xs (16px), heading-sm (18px),
heading-md (20px), heading-lg (24px), heading-xl (30px), heading-2xl (36px),
heading-3xl (44px), heading-4xl (56px).
Rule: use token names only — never arbitrary pixel values.
Rule: step up one token size per breakpoint (mobile → tablet → desktop) as a guide.
Store typography_tokens with Object ID, tag, and visual size per breakpoint.
Present the complete invisible layer to the user — spacing objects and typography tokens.
Ask if anything needs adjusting before generating the specification.
Verify all data from steps 1-8 is present before generating:
page_basics, layout_sections, component registry with Object IDs, multilingual_content,
interaction_behavior, page_states, component_states, validation_rules, error_messages,
spacing_objects, typography_tokens.
If any section is missing, return to the relevant step to complete it first.
Generate the complete specification document using the template at:
templates/page-specification.template.md
Fill ALL sections with data from steps 1-8. Do not invent new formats —
the template defines the structure.
Run the validation script before saving:
wds-validate.js --page {current-page-path}
Review any errors or warnings reported. Fix issues in the relevant data sections
and re-run until validation passes.
Save the complete specification to:
{output_folder}/C-UX-Scenarios/{scenario-slug}/pages/{NN}.{step}-{page-slug}/{NN}.{step}-{page-slug}.md
Present the summary to the user: sections, components, languages, interactions, states,
validation rules, spacing objects, typography tokens — with counts.
Update the design log: append a row to the Design Loop Status table with status "specified":
| [scenario-slug] | [NN.step] | [page-name] | specified | [YYYY-MM-DD] |
Remove this page from the Current table. Do NOT skip this — the design log drives the
adaptive dashboard across sessions.
{output_folder}/C-UX-Scenarios/{scenario-slug}/pages/{NN}.{step}-{page-slug}/{NN}.{step}-{page-slug}.md
Return to the calling workflow's transition logic. If called from step-01-exploration.md (Discuss)
or workflow-suggest.md (Suggest), the calling step determines what comes next.
The design log status "specified" is the signal that this page is done.