Skip to main content
Reference — generated from the toolkit

Source of truth: toolkit/templates/design-context-pack.md. Edit it there; this page is regenerated on build.

Design context pack — {product / scope}

  • Owner: Design Version: 0.1.0
  • Design-system / token package version: {semver} (agents must not target "latest")

Components per pattern

One row per UI pattern. If a pattern has no row, the agent must stop and flag it for the component contribution workflow — never invent a bespoke component.

PatternComponentVariant / propsWhen NOT to use
Primary actionButtonintent=primarymore than one per view; destructive actions (use intent=danger + confirm)
Destructive actionButton + ConfirmDialogintent=dangeranything reversible — don't add friction to safe actions
Field inputTextFieldtype=text|number|datemulti-line content (use TextArea); option sets ≤5 (use RadioGroup)
Status of a policy/claim/MTAStatusTagstatus={domain status}free-text status strings — statuses come from the domain glossary
Tabular dataDataTablesortable, paginatedfewer than 3 columns (use List)
Errors, warnings, confirmationsAlertseverity=info|warning|errorvalidation on a specific field (use the field's error prop)
{pattern}{Component}{variant}{when not to use}

Styling rules (enforced by lint)

  • Tokens only — every colour, size, space, radius and type style comes from the DTCG token set. No raw hex. No raw px. No magic numbers. Lint rejects them (design-quality toolchain).
  • No unknown components — imports outside the design-system package fail lint.
  • No style overrides on library components — if a component needs to look different, that is a variant proposal, not a local patch.
  • All interactive states implemented — hover, focus-visible, disabled, loading; the components provide them, don't suppress them.

Copy & tone

Follow the content & microcopy standard: plain English, no unglossed insurance jargon, error messages that say what happened / why / what to do next. Terms come from the domain glossary — the same action is named the same way everywhere.

Accessibility defaults

Library components carry focus order, keyboard operability and ARIA per the WAI-ARIA APG. The agent's obligations on top: meaningful labels (never placeholder-as-label), field-level error identification, and the screen-level criteria in the screen spec it is building against.

Worked examples — good vs bad pairs

At least one pair per high-traffic pattern; agents pattern-match from examples far more reliably than from rules. Grow this section from real review findings.

Example: destructive action

  • Bad: <button style="background:#d4351c">Delete</button> — raw element, raw hex, no confirmation.
  • Good: <Button intent="danger" onClick={openConfirm}>Cancel policy</Button> + ConfirmDialog stating the consequence ("This cancels the policy from {date}. The client will be notified.").

Example: validation error copy

  • Bad: "Invalid input in field DOB." — blames the user, exposes internals, unglossed abbreviation.
  • Good: "Enter the policyholder's date of birth, for example 27 3 1985." — says what to do, gives a format example.

{pattern}

  • Bad: {anti-example — take real ones from design-crit findings}
  • Good: {corrected example}