# UI task Agent: Claude Code · Platform: Web ## What we're building _Describe what you're building._ ## Who it's for _Who will use it?_ ## Done means They can: _What should they be able to do?_ ## Before you change anything Read the relevant screens, components, design tokens and data first. Identify the one main action on this screen and keep existing conventions. Follow CLAUDE.md. Before editing, name the files and components you'll reuse. If something important is missing, say so before building. ## States to design - Loading - Empty / first use - Error with retry - Success ## References (UXKIN) If a layout or wording decision is unclear and UXKIN is connected, look it up with find_ui_references (screens and websites) or find_ui_materials (colors, type, components, DESIGN.md). Say which references you used and what you took from each. Take patterns, not another product's branding. If UXKIN isn't available, continue with the project's own system. ## Build Build the real flow with realistic content and working controls, using existing components. Cover every state listed. Keep the scope to this outcome. ## Check before calling it done Render it and check at 390px and 1440px wide: nothing scrolls sideways, the main action stays visible. Use it by keyboard only (visible focus, every control reachable), check labels and text contrast (4.5:1). Fix what you find. Then report what you ran, what passed, and anything you couldn't check. Don't call something checked from reading the code alone.
Everything stays in this page. Nothing is saved or sent anywhere.
Why a brief beats "make it look good"
Coding agents fill gaps with averages. Ask for "a nice settings page" and you get the most common settings page: generic labels, a happy path only, and no idea who it's for. The fix isn't a longer prompt, it's a more specific one: the person, the outcome, what has to stay the same, and how the result will be checked.
The builder asks for exactly those things and turns them into a short Markdown brief. It also adds the steps agents tend to skip: read the existing code first, cover every state, and check the rendered result instead of calling it done from the code.
What each answer does
- What you're building sets the scope. One screen or one flow is better than "the dashboard".
- Who it's for decides what matters most on the screen. "A store owner checking what needs attention each morning" leads to different choices than "users".
- What they should be able to do becomes the definition of done. Write it as something you can test.
- What must stay the same protects your components, tokens and tone of voice, so the new screen belongs to your product.
- One design question gives the agent a specific thing to look up, like where an error message should go, instead of copying a whole design.
Pick states, not styles
Most AI-built screens look fine with perfect data and fall apart with real data. Choosing states like Empty / first use, Error with retry or Long text tells the agent to design those on purpose. It's a better use of your words than adjectives like "clean" or "modern", which every agent already aims for.
After you paste it
Let the agent read your code and list what it will reuse before it builds. If it asks questions, answer them in the brief so the next session has them too. When it's done, review the result with the coding agent UI checklist: the brief says what to build, the checklist confirms it was built.
Questions
Is the prompt builder free?
Yes. It's free, needs no account and runs entirely in your browser. Nothing you type is saved or sent anywhere.
Which coding agents does it work with?
Any agent that takes a text prompt. Choosing Claude Code, Cursor, Codex or GitHub Copilot adds a line pointing the agent at the instruction file it already reads (CLAUDE.md, .cursor/rules, AGENTS.md or .github/copilot-instructions.md).
Do I need UXKIN connected to use the brief?
No. The brief works on its own. If your agent has UXKIN connected, leave the switch on and the brief tells it to look up real references for your open design question. If it isn't connected, the agent is told to continue with your project's own design system.
Should I save the brief in my repository?
For bigger tasks, yes. Download it as a Markdown file and keep it next to the feature, so you (and the agent in a later session) can check the result against what was asked.
Sources and review
Checked against UXKIN's live tools on September 29, 2026. Client apps change their settings screens over time; follow your client's own documentation for the exact steps.
Put it to work
Connect UXKIN and your agent can answer the brief's open design question with real app screens and website design systems instead of guessing. Browsing the library is free.