frontend-design

frontend-design

UI work in two parts. The decisions (direction, tokens, critique) go to ac/design-director, a read-only agent, when the work needs them. The implementation is yours. DESIGN.md is the contract between the two: tokens in YAML, intent in prose. Covers web in any framework, iOS-feel and Material-feel interfaces, and Flutter.

Standing rules

These hold for the whole run and sit before the procedure so a compaction keeps them.

• Direction before code. No palette, typeface or layout is chosen while writing components. Without a visual DESIGN.md or a theme with a point of view, run phase 2. With one, build inside it.
• Tokens only. Every colour, size, radius and duration comes from DESIGN.md or the theme files; no literal outside them.
• Generic instructions fail. "Clean and modern" lands on the same palette every time; commit to named hex values and typefaces, and keep the patterns in references/anti-slop.md out of the result. The user's own words win over any default here.
• Ground the screen in its subject. The audience, the job and the subject's own vocabulary are where distinctive choices come from; the hero shows the most characteristic thing in that world, and a big number with supporting stats and a gradient accent is the default to avoid. Words are design content: a button names its action, an error says how to fix it, an empty state invites (anti-slop.md, Subject, hero and copy).
• One platform family per surface. iOS-feel follows the HIG, Android and Material-feel web follow Material 3, Flutter uses the adaptive widgets; numbers in references/tokens-and-platforms.md.
• UX first. Every screen designs loading, empty, error and success, not only the happy path. Touch targets 48 px or larger, visible keyboard focus, text contrast 4.5:1, prefers-reduced-motion honoured, one signature motion per screen and feedback under 200 ms (references/motion.md).
• Build what the brief lists. Models add tests, docs and extra components nobody asked for; name such an idea in the report instead of building it.
• Judge by the render. Your description of the result is not evidence; a screenshot is.
• ac/design-director cannot ask the user anything, so the choice it recommends goes to the user through the question tool, in the user's language.
• A failed subagent moves down its model chain; it is not a question. A subagent call that comes back with a provider failure (Subagent failed (sessionID: ...), a <subagent ... state="error"> message, an error such as provider.invalid-output) or with no answer at all (Subagent completed without a text response., an empty report) failed on its model, not on the work. Continue the same child instead of spawning a new one: call subagent again with the same agent, sessionID: "<the sessionID from the failure text>" and the prompt Your last turn stopped on a provider error. Continue the task from where you left off without repeating finished work., so the child keeps everything it already read. When it answered nothing or broke off mid-stream, continue it on the same model until it has run retryAttempts times there (from the ac_models tool, 3 in the shipped config); a 5xx was already retried inside the call, so it goes straight on. Then call ac_fallback_next({ tier: "<the agent name without ac/>", tried: [<every model this call ran on>], session_id: "<the sessionID from the failure text>", status: <the HTTP status, when the error carried one> }), with tried starting at the agent's chain head from ac_models unless you set its model yourself, continue the same child with model: "<the returned value>" as well, and give that model the same number of attempts. wait:<seconds> means that model has retries left: wait that long with one shell sleep and continue the child on the same model with tried unchanged. Start a fresh spawn with the full prompt only when the continuation is refused (Subagent session not found, is not a child of the current session) or the child's context overflowed. Only none, every entry of the chain tried, is a failure to report.