thedesignagent.ai

TheDesignAgent — workflow for coding agents. LOOP for every screen or non-trivial UI change: 1. Discover(task, project_id?) → build brief with active JTBD, heuristics, patterns. First-ever call per project returns status=needs_setup with an extraction task; build a project_model from the repo's schema/types/migrations and resubmit. Subsequent calls are cheap — reuse the project_id alone. 2. Build the UI from the brief. 3. Ux(task, artifact, project_id?) → 0–10 score + findings. Iterate on HIGH-severity findings; stop when the score plateaus (typically 8.5+), not when it hits 10. 4. Visual works on the LOCAL stdio MCP server only (it screenshots http://localhost). Over the hosted gateway it returns install instructions — that response is informational, not an error. Per-call inputs — what to send when: - task: ALWAYS (one short sentence describing what you're building or evaluating). - project_id: ALWAYS once you have one (Discover returns it in _meta.tda_project_id and inline; persist it in .thedesignagent or memory). - artifact (Ux/Visual): ALWAYS — the component code or a structured UI description. - project_model (Discover): ONLY on first call (no project_id yet) OR when a response returns _meta.tda_status === 'setup_required' or 'model_stale'. NEVER resend it on routine subsequent calls — it's cached server-side and resending wastes 2–4k tokens plus forces re-validation. - schema_hash: optional. Useful as a freshness probe so the server can detect when your migrations/types have drifted. Cheap to compute (SHA256 of concatenated schema files). - repo_hash: only as a fallback for project_id resolution before your first Discover. - codebase_context: optional sugar — a 1–3 line code snippet for tighter calibration. Conventions: - Prefer the MCP tools (Discover/Ux/Visual) over curl when this server is configured as an MCP server in your editor — the host plumbs auth and JSON-RPC for you, and you get _meta natively. - Send Accept: application/json on raw tools/call requests to avoid SSE framing on non-streaming clients. - A ⚠ Degraded response is partial-success — the brief or eval is still usable. Don't abort; proceed with what's returned or retry once. - Check _meta.tda_status on every tool response for a stable machine-readable health signal (healthy | degraded:* | setup_required | model_stale | local_install_required | login_required | auth_failed | rate_limited | pipeline_error) before parsing the prose. _meta.tda_retry_ok tells you whether the same call can be safely retried. Don't ask the user about protocol ("should I call Discover first?", "which tool runs when?", "is the backend healthy?", "did the fix deploy?") — follow the loop and read _meta. Do ask the user about scope ("rebuild or patch?", "list vs detail?", "what's the JTBD?") — that's product judgment, not protocol.