Agentic BP DScode-first design system

Prompting

The assistant builds exactly what you describe, from the kit. The clearer the screen in your head, the better the screen on the page.

Before You Prompt

  • Know the screen. What is it for, who uses it, and what they do there? One sentence is enough.
  • Find the pattern. Look through Using patterns and name the one that fits.
  • Gather the content. Real column names, fields, actions and a few sample values make a big difference.
  • For anything bigger than one screen, ask for a plan first. “Advise first, before you change anything” gets you a plan to agree on, not a surprise.

Start Every Screen the Same Way

/prototype-from-kit is the kit's Prototype from kit skill: a short set of instructions that comes with every copy of the kit, in .claude/skills/prototype-from-kit. Typing it at the start of a message tells the assistant to build the screen the kit's way:

  1. Look the screen up in the kit's index, contracts/index.json.
  2. Read only the contracts for the pieces it needs.
  3. Use a pattern when one fits the screen, instead of laying it out by hand.
  4. Build only from kit components, with the options their contracts list.
  5. Stop and ask when the kit is missing something, instead of inventing it.

Begin with the skill, the pattern and one sentence about the screen:

/prototype-from-kit A Contracts list using ListPage inside AppShell, for finance managers who review renewals.

What a Good Prompt Says

  1. The screen and its pattern: “a RecordPage for an account”, not “a page with details”.
  2. The content: columns, fields, sections, tabs, and sample data.
  3. The actions: which buttons, which one is the strong brand Button (only one), and what each one does.
  4. The states: empty, loading, error, success messages, validation.
  5. The widths that matter: “must work on a phone” or “desktop only”.
  6. What to leave out: parts of a screenshot to ignore, or features for later.

Examples

A list of records

Too vague
Make an invoices page.
Clear
/prototype-from-kit An Invoices list using ListPage inside AppShell.
Columns: Invoice number (a link), Account, Status (Paid, Overdue, Draft as badges), Due date, Amount (right-aligned).
Toolbar: search, filters for Status and Due date, and one strong brand action, New invoice.
20 sample rows, 10 per page. Show the empty state when the filters match nothing.
It must work on a phone.

A form

Too vague
Add a form to create a customer.
Clear
/prototype-from-kit A New account page using FormPage.
Sections: Account (Name, required; Type: Customer or Partner; Parent account as a Lookup), Billing (Currency, Billing cycle, Payment terms), Address (two columns).
Save is the one strong brand action; Cancel goes back to the account list.
After saving, go to the account and show a success message.

From a screenshot

Too vague
Make it look like this screenshot.
Clear
Here is a screenshot of our current account page. Rebuild it with RecordPage.
Keep the tabs, the summary numbers and the account details.
Ignore the old side menu and the colors; use the kit's.
If something in the screenshot has no kit component, stop and tell me which, before building.

Work in Small Steps

  • One screen at a time. Get it right, then move to the next one.
  • One change per message once the screen exists: “Add a Status filter to the toolbar”.
  • Point at the thing. Select the element on the page, or name the component and where it sits.
  • Say what is wrong and what you want instead, not only “fix it”.
  • Save good states. Ask the assistant to commit when a screen looks right, so you can always go back.

When a Piece Is Missing

The kit tells the assistant to stop and ask when a screen needs something it does not have. That is on purpose: it keeps every prototype built from the same parts. You have two good answers:

  • Add it to the kit: “Add a Rating component to the kit: contract first, then the component, then its catalog page.”
  • Change the screen: “Use a Select with 1 to 5 instead.”

Check the Result

  • Ask the assistant to check it in the browser and show you a screenshot before you review.
  • Try it at phone and tablet widths, and in dark mode from the top bar.
  • Click through it: menus open, dialogs close with Escape, forms show errors, buttons do what they say.
  • Ask for a review when a screen is done: “Review this screen against the kit rules. Report only.”

Keep the Kit Clean

  • Ask for kit components by name, and use only the options their contracts list.
  • One strong brand Button per view.
  • No colors or spacing typed in by hand: the kit's tokens and layout classes cover them.
  • Describe goals, not other products: “a dense table for power users”, not “make it like product X”.
  • Keep secrets out of prompts: no passwords, keys or real customer data.

Checklist

  • Started with /prototype-from-kit and named a pattern.
  • Gave real content: columns, fields, actions, sample data.
  • Said which button is the strong brand one, and which states to show.
  • Said which widths matter.
  • Asked for a plan first on anything bigger than one screen.
  • Checked it in the browser at every width before calling it done.