Examples

Prompts you can paste into any connected assistant. Each one names the laws it leans on.

Tip: you don't need to mention the server by name if you've added the project snippet. Your assistant will reach for it on its own.

Review a form before you ship it

Laws 1, 2, 6 · Reference component: the form

Review the checkout form in src/Checkout.tsx against the design framework. Be specific about what to change.

The assistant calls review_checklist and get_section('reference-component-the-form'), then checks submit behaviour, validation timing, error placement and mobile keyboard handling.

Build a component from scratch

Laws 3, 4, 5 · Reference component: the form

Build a three-step onboarding flow for new workspaces. Use the design-framework server first to see how large forms should work.

Expect all steps visible up front, about five fields per step, continuous saving shown structurally, and input that survives a reload.

Replace a confirmation dialog

Laws 2, 5

We show "Are you sure?" before deleting a project. Redesign it according to the framework.

Law 2 says prefer undo over confirmation. The result deletes instantly, shows the item gone in place, and offers undo. Law 5 says the deleted project stays recoverable.

Write error messages that help

Law 2 · Reference component: the form

Rewrite every validation message in src/forms/messages.ts so they follow the framework's guidance on errors.

"Invalid input" becomes "Add your area code". Errors are instructions, and they reserve their space so nothing shifts.

Choose the right kind of button

Law 7

Audit the buttons on the settings page. Does the look of each one match the weight of its action?

A large solid button is the committing action, a small pill with an icon is a quick action, text-only is a secondary path, and destructive actions look destructive. The same meaning always looks the same.

Calm down a dense table

Law 8 · Grouping and density

Our invoices table has borders, zebra stripes and padded rows. Simplify it using the framework's guidance on density.

One quiet cue instead of three. Regular rows, faint rules, numbers aligned right, and sort, filter and highlight available on demand rather than baked in.

Fix a field that needs explaining

Context, not instruction

The "Income" field confuses people and has a paragraph of help text. Fix it per the framework.

Sharpen the label first: "Gross monthly income (before tax)". One line of help at most, an example such as "e.g. EUR 3,200", and edge cases behind a small disclosure.

Set a type scale and spacing rhythm

Typography and rhythm

Propose a type scale and spacing system for this app using the framework's typography guidance.

Four roles at most, one size ratio, one spacing unit tied to line height. The framework deliberately leaves the exact ratios to you.

Review a whole pull request

All eight

Review the UI changes in this PR against every law in the design framework. List each law, whether the change holds, and what to fix.

A good fit for a CI step or a review bot: connect the server, run the prompt on the diff, post the result.

Settle a design argument

North star

Should the save button be disabled until the form is valid? Check the framework and give me a recommendation.

Law 2 and the form guidance answer it: the submit button is always clickable, and pressing it always gets a response.

Without an assistant

The laws are plain text. Print the laws page, or open framework.md, and use it as a design review checklist in a team meeting. The framework doesn't need software to be useful.