Work with a design system

Make the next page belong with the rest.

On this page 4 sections

If your product already has a design you want to keep, give Impeccable that context before asking it to expand the interface. Existing code, components, and rendered pages are evidence of the system too.

Record what you have

Ask Impeccable to document the current system:

/impeccable document

It reads the implementation and records colors, typography, layout rules, and components in DESIGN.md, with additional generated metadata in .impeccable/design.json. Review the record so it captures intentional decisions, rather than accidents or outdated styles.

If DESIGN.md already exists, ask for a refresh when the implementation has changed. Keep audience, goals, and product constraints in PRODUCT.md, established with init. Context files explains what belongs in each record.

Build within the system

Name a representative page or component when it will help:

/impeccable add a billing settings page. Follow our existing settings screens and reuse the shared form controls.

A new page can explore a better layout for its task while keeping the established visual identity. A small addition inherits the surrounding design. Missing documentation alone does not give Impeccable permission to replace a coherent interface.

The new-page workflow explains how you choose a structure within an existing system.

Keep changes reusable

When repeated patterns should become shared components or tokens, use extract:

/impeccable extract the repeated filter controls into our design system

Use automatic design checks or a detector scan to find supported kinds of drift from documented values. For an intentional exception, record a specific ignore with the reason.

Refresh the record when the system changes

After an approved visual change, ask Impeccable to refresh DESIGN.md from the implementation. If only the generated metadata is stale, preserve the document:

/impeccable document: refresh .impeccable/design.json from the existing DESIGN.md and current components. Preserve DESIGN.md.

Use doctor when you are unsure which files need attention. Commit shared design decisions with the code so the next session and the rest of the team use the same context.