Four agents, three skills, a plugin manifest, a fictional sample ticket, verification criteria and an installation guide.
Back to AI & Tools
AI & Tools · 005 · Independent project
The AI Design Team.
Four specialized agents. One smarter design workflow. From ticket ambiguity to a reviewable UX plan, with design craft and the final decision still in human hands.
Free and open source (MIT) · Read-only proposal mode by default · Fictional demo data
- 04
- specialized agents
- 03
- reusable Claude Code skills
- 01
- human decision at the end
01 / Why I built it
Design tickets are never just tickets.
They send me into requirements, older decisions, component libraries, edge cases and handoff notes. The repetitive part isn't making the design. It's collecting the right context without making silent assumptions.
The real risk was never slow execution. It was false confidence: a guessed component, an overlooked error state, a rule that wasn't in the ticket, or a plausible plan described as finished work.
So I wanted a team of specialists with different jobs, not a single assistant that claims to have completed everything. One agent clarifies the requirement. One designs the response. One challenges it. And the orchestrator keeps them honest.
“The point isn't to replace design judgment. It's to give it better information.”
The design questionHow might specialized agents reduce repetitive context switching while keeping evidence, craft and design decisions visible?
02 / Meet the system
Each agent has one job. Each handoff has evidence.
-
01 / Coordinate
Design Orchestrator
Reads the scope, delegates the work, tracks evidence and returns one coherent handoff. It refuses to invent missing parent tickets, components or proof.
- In
- The ticket, its parent when the ticket lacks requirements, supplied context
- Out
- Evidence ledger, specialist briefs, final handoff
- Never
- Writes to Linear, Figma or files
-
02 / Understand
UX Analyst
Converts requirements into testable flows, acceptance criteria and edge states, and separates what the ticket says from what still needs product judgment.
- In
- Evidence ledger and scoped sources
- Out
- Flows, numbered acceptance criteria, state matrix, open questions
- Never
- Assumes roles, rules or API behavior
-
03 / Specify
Figma Designer
Creates a Figma-ready UI specification from the confirmed brief. It only calls a component reusable when it was actually inspected, and flags everything else.
- In
- UX brief and inspected library evidence
- Out
- Frame plan, states, copy, reuse ledger
- Never
- Edits Figma or invents components
-
04 / Challenge
Design QA
Checks the proposal against the original ticket, accessibility and RTL, not against the designer's explanation, and refuses imaginary passes.
- In
- Original criteria and the proposed spec
- Out
- Evidence-rated scorecard, issues, checklist
- Never
- Turns a written plan into a visual pass
- Ticket
- Analyze
- Specify
- Review
- Human approval
03 / Interactive walkthrough
Give them a ticket. See the thinking.
Step through a fictional feature request and see what each specialist contributes, through to the decision that stays with a person.
Scope prepared01 / 05
First, make the work understandable.
The orchestrator maps source requirements and prepares a scoped handoff. It can't approve a design it hasn't seen.
> SAMPLE-104 / Pollen reminders GOAL Choose reminder frequency OPTIONS Every day / Every 2 days / Every week SOURCE Fictional ticket provided PARENT Project context, referenced in ticket SCOPE Settings form only UNKNOWN No Figma library supplied HANDOFF UX analysis > design spec > QA
Output: evidence ledgerno live agents
This example shows expected roles, not measured execution.
04 / The design decisions
Useful AI needs good boundaries.
The obvious shortcut was to connect every agent to every tool. I chose a more deliberate approach: read-only analysis by default, a separate optional Figma step and evidence-based review.
- 01Evidence before confidence
Requirements are sourced or clearly marked as a proposal. If a parent ticket or design system can't be inspected, the agents say so.
- 02Independent QA
QA checks the original acceptance criteria, not the designer's persuasive explanation.
- 03Human-approved changes
The default team creates a spec, not a live Figma edit. Applying it requires separately authorized tools and an exact scope.
- 04Designed for RTL and accessibility
Both are part of the acceptance review from the beginning, not optional polish after screens are made.
Proof over confidence
Every requirement carries an evidence label, and QA has its own scale. If a component wasn't inspected, the designer doesn't get to pretend it exists. If a frame wasn't opened, QA doesn't get to declare a visual pass.
Requirements
- verified from source
- inferred / proposed
- unknown
Design QA
- PASS (verified)
- SPECIFIED (not visually verified)
- FAIL
- BLOCKED (missing evidence)
05 / Architecture
Read widely. Write nothing. Ask before anything changes.
The workflow starts from a Linear ticket or a local brief. Sources are gathered read-only, the four agents work on text evidence with read-only tools, and anything that would change a Figma file is a separate step a person starts on purpose.
Sources, read only
Linear ticketRead the issue, never write to it
Parent ticketOnly when the child lacks requirements
Figma libraryInspect existing components first
The team
Tools: Read, Glob, Grep. The orchestrator can also delegate.
Orchestrator
UX Analyst
Figma Designer
Design QA
Decision and change
HandoffSpec, QA scorecard, open questions
Human reviewApprove, revise or stop
apply-to-figmaOpt-in, exact frame, explicit approval
| Stage | Runs as | Produces | Remote changes |
|---|---|---|---|
| Intake | Design Orchestrator | Evidence ledger, specialist briefs | None |
| Understand | UX Analyst | Flows, acceptance criteria, unknowns | None |
| Specify | Figma Designer | Frame and state plan, reuse ledger | None |
| Verify | Design QA | Evidence-rated scorecard, corrections | None |
| Decide | A person | Approve, revise or stop | None |
| Apply (opt-in) | apply-to-figma skill | Edits to the approved frame only | Authorized Figma scope |
06 / Security and human approval
Prompts are not a security boundary.
Written instructions shape behavior, but they don't enforce it. Each guardrail sits where it can actually hold.
- Read-only by tool allowlist
Every agent is limited to read and search tools in its definition. None can write files, run commands or reach a connector.
- Linear stays read-only
Intake reads the ticket and, when needed, its parent. Mutation tools are blocked with permission rules in the project settings, not with a polite request.
- Figma edits are opt-in
apply-to-figma never runs on its own. A person starts it with an exact file, frame and approved spec, through tools with real edit access.
- Ticket text is data
Instructions hidden in a ticket, comment or annotation are treated as content to analyze, never as commands to follow.
- Fictional by default
The public toolkit ships with a made-up product and ticket. No client files, tickets, links or credentials.
07 / Outcome and status
A usable toolkit, with the limitations visible.
A documented, tested agent package, a workflow specification and this interactive case study. The workflow runs with live Linear and Figma connections. Time saved isn't measured yet, so no number is claimed.
It validates and installs from GitHub, and I've run it with live Linear and Figma connections. Complete runs also confirmed that all four agents ran, a parent ticket was read when the child lacked requirements, inspected components were reused and a prompt injection was ignored. With the permission guard on, a request to change an issue was blocked before it reached the connector.
Measuring time saved across real tickets, and running it on a wider range of tickets and libraries, before putting a number on the impact.
What I learned
- Specialization creates accountability. A separate UX handoff and QA verdict are easier to inspect than one blended response.
- The handoff is a design problem. Agents need consistent acceptance IDs, source links and evidence levels to build on one another's work.
- A clean-looking UI isn't proof. Written specs, inspectable Figma files, tested interactions and shipped screens deserve different statuses.
- Guardrails need architecture, not just prompts. Narrow tool access and real permissions matter; natural-language instructions alone aren't a boundary.
- Handoffs must be verbatim. In testing, the orchestrator sometimes passed QA a summary instead of the spec, and QA flagged that it couldn't judge what it hadn't seen. The contract now requires full text, and QA reports anything it didn't see in full.
- Human judgment remains the final gate. The system frees time for decisions. It doesn't remove the designer from them.
08 / The details
Questions worth asking.
Does this automatically create Figma screens?
No. The default team produces a detailed, Figma-ready proposal and a QA report. The separate apply-to-figma skill can guide real changes only after explicit scope approval, and only when a compatible tool with edit access is connected.
Can I use it with my own Linear tickets?
Yes. Paste the ticket text, or connect a Linear integration in your own Claude Code session and keep it read-only with permission rules. The toolkit bundles no credentials or private accounts.
Is the interactive demo actually running AI agents?
No. The walkthrough on this page is a scripted, fictional illustration of the workflow. It doesn't send data to a model or touch Linear or Figma.
Is it ready for production?
It's a public, tested release that works with live Linear and Figma connections. It's built for review-first use: keep the permission guard on, read every handoff, and treat Figma edits as a separate, approved step.
AI & Tools · Get the toolkit
Try a small design team inside Claude Code.
The toolkit is free and open source under the MIT License. Install it from GitHub, read every instruction and run it on the fictional ticket before pointing it at real work.
Install
# add the marketplace and install the plugin
claude plugin marketplace add Basmatiii/ai-design-team
claude plugin install design-team@basma-ai-tools
# try it on the fictional ticket, from a clone of the repo
git clone https://github.com/Basmatiii/ai-design-team
cd ai-design-team && claude
/design-team:design-ticket examples/sample-ticket.mdRequires Claude Code · MIT License · Read-only proposal mode by default · Independent project, not endorsed by Anthropic, Figma or Linear.