AI design agent

The AI design agent is a Claude Code plugin that ships with this design system. It gives an AI assistant the same rules documented on this site, so it can build, review, and clean up DayTwo screens without a person re-explaining the system each time.

Build to the system

Generate new screens that use our components, tokens, states, and three languages from the first version.

Review and catch gaps

Check a screen for missing states, usability problems, and functionality a redesign dropped.

Stays accurate

Each skill reads the live tokens and USAGE.md when it runs, so it never falls behind changes to the system.

What it is

The agent is a set of three installable skills — create, review, simplify — not a prompt you paste in. Once the plugin is installed, a skill runs when you ask Claude Code something it matches — "review this screen", "check the states", or "did this refactor drop anything?" — and returns a structured answer based on this design system.

Every skill is documented in full on this page, so you can understand and use the agent without opening the repository.

Why it stays accurate

The skills do not keep their own copy of the colours or component list. They read the live files when they run: the generated packages/tokens/dist/tokens.json and this repo's USAGE.md. Change a token, and the skills use the new value on their next run.

Get started

Set it up

In the design-system project, run npm install, then npm run build:tokens once so the skills have tokens.json to read.

Install the plugin

In a Claude Code session, run the command below. It registers all three skills.

Ask in plain words

You don't call anything special. Ask for a review or a new screen, and the matching skill runs.

/plugin install ./daytwo-design-agent

You can also name a skill directly when you want a specific one:

# Runs the matching skill automatically:
Check the states on the Community Discover tab.

# Or name the skill:
Use daytwo-ui-review to check what this change dropped.

Using it in Claude chat or Lovable

The three skills are a Claude Code plugin — they only run inside Claude Code. Tools like Claude chat, Lovable, v0, or ChatGPT have no plugin system; the only thing they accept is text in the prompt. So for those, the design system travels as one paste-in block — the same rules, compressed to fit any prompt.

Two forms, one system

In Claude Code, install the plugin. Everywhere else, paste the design brief. Both carry the same rules — colours, type, spacing, states, three languages — so a screen comes out on-brand either way.

Paste the block below at the top of your prompt, then describe the screen underneath — e.g. "Build a screen for a shop owner to record a cash sale, big amount on top, one confirm button." The full version, with every hex value and the exact type scale, lives in DESIGN-BRIEF.md at the repo root.

You are designing for DayTwo, a mobile finance app for small-business owners in
Myanmar and Thailand. The feel is calm, premium, and trustworthy — Apple-minimal,
not busy or loud. Follow these rules exactly.

Brand & tone — Clean, spacious, one clear thing to do per screen. Warm, plain
copy; never scold on errors. Assume a first-time, low-literacy user on a cheap
Android phone in bright sun.

Colours — Primary action (buttons/CTAs): teal #005E77 + white text. Accent/focus
only: aqua #14DBDB (never behind white text, never body text). AI features only:
violet #7C3AED or gradient linear-gradient(135deg,#8B5CF6,#6366F1 52%,#14DBDB).
Text #1A1F22 / #5B656C / #7C868D. Background #FFFFFF, inset #F7F8F9. Success
#1E8E4E, Warning #9A6400, Error #C42B22.

Type — body 17, headings semibold; a hero number caps at 22–28 (classy, not
shouty). Corners: buttons are pills, cards radius 16. Space on an 8-pt grid;
screen padding 16–20. Shadows very soft; prefer a hairline border.

Rules — one primary teal pill per screen; 44–48px tap targets. Always include
empty / loading / error / offline states. App ships in English, Burmese, Thai —
short labels, no text baked into images. No aqua text, no violet unless AI, no
heavy shadows, no pure black.

Now design the screen I describe next, following all of the above.

The three skills

Three skills, one per verb — create a new screen, review an existing one, simplify a busy one. Each reads the design system first, then returns a structured answer. Expand any skill to see what it checks and what it returns.

Create

daytwo-ui-create

Build a new screen, sheet, or component from the design system.

“Create a screen for recording a cash sale from the home screen.”

You get: The screen’s one job, a component plan, the primary action, required states, copy guidance — and what not to build.

Review

daytwo-ui-review

The full audit — brand & craft, usability, missing states, device/offline constraints, and dropped functionality.

“Review this screen against the DayTwo Design System.”

You get: A summary, ranked top issues (each with a concrete fix), missing states, device/language/offline risks, functionality risk, and a prioritized fix list.

Simplify

daytwo-ui-simplify

Reduce a screen to its calmest form without deleting anything real.

“Simplify this onboarding screen while preserving all states and actions.”

You get: A KEEP / REMOVE / MOVE breakdown, a risk check, and a proposed revision.

Which skill for which job

I want to…	Use
Build a new screen the right way from the start	`daytwo-ui-create`
Review a screen — on-brand? usable? states? offline? did a change break it?	`daytwo-ui-review`
Make a busy screen calmer without breaking it	`daytwo-ui-simplify`

daytwo-ui-review is the full audit. What used to be separate skills — a consistency sweep, a usability walk, a states check, a low-end/offline check, a regression diff, a prioritized cleanup list — are now dimensions inside review. Ask for one by name in your prompt ("focus on missing states", "check it offline in Burmese", "did this refactor drop anything?") and review leans into it.

What good output looks like

A good result is specific and tied to a user outcome, and every fix names a real token or component. A generic answer counts as a failed run. Each skill's test prompt describes what a failing run looks like, so quality is something you can check rather than judge by feel.

Remove the secondary CTA. This screen's job is to record one sale, so keep one primary action and move 'Share' into the overflow menu. This keeps the next step clear for a first-time user.

Don't

Make the screen simpler. Consider better error handling and cleaner styling.

How it stays honest

Live references

The references folder is eight pointer files aimed at the real tokens and USAGE.md. The component index is the source of truth for exports, and skills flag any drift between them.

Testable

Each skill has a test prompt with expected behaviour, an example of good and of bad output, and notes on improving a weak run — so you can tell whether it still works.

Real proof runs

The examples folder holds real runs against DayTwo screens — a states review, a regression diff, and a consistency sweep — the kind of output review now produces for each of its dimensions.

Folder layout

daytwo-design-agent/
  README.md
  .claude-plugin/plugin.json      the plugin manifest
  skills/<name>/SKILL.md          one folder per skill (create, review, simplify)
  references/                     eight pointer files to the live tokens and catalog
  test-prompts/                   prompt + expected/good/bad output + improvement notes, per skill
  examples/                       real sample runs against DayTwo screens