Design
Is this final? Asked for the fourth time this month
A completeness check before build starts, so the question is answered before it is asked.
What the worker does
An AI worker runs the completeness check that sits between design and build. Using the Figma, Google Drive and Linear connections, it lists which frames are marked ready by your team's convention, which exported assets are present in the shared folder, what the ticket references but nobody produced, and the spacing and colour values pulled into a written spec. An engineer still asks whatever the check did not cover.
- Trigger
- When handoff is assigned
- Connections
- Figma, Google Drive, Linear
- Output
- Ready or not-ready, itemised
Handoff fails on the small things
The design is finished. The icon set was never exported at two times, the empty state exists only in a comment, and the hover colour is in the file but not in the ticket. Each of these is a two-minute fix and each one costs a half-day round trip, because the engineer discovers it at the point of needing it and the designer is in a workshop.
The check that would catch all three is mechanical. Nobody runs it because running it is boring and the failure is somebody else's afternoon.
The handoff check, in order
- 1
Confirm what is marked ready
By your team's convention, whatever it is: a page named Ready for dev, a status field, a frame prefix. Write the convention into the SKILL.md so the check is exact rather than interpretive.
- 2
Match frames against the ticket
Every state the ticket references, checked for a corresponding frame. Empty states, error states and loading states are the three that go missing, in that order.
- 3
Check the exports
Assets referenced by the design, checked against what is actually in the shared Google Drive folder, at the sizes the ticket asks for.
- 4
Write the spec values
Spacing, type sizes and colour values pulled from the file into written text in the comment, so an engineer can read them without opening the design tool.
- 5
Deliver a verdict with a list
Ready, or not ready with the specific missing items named. A verdict without the list is a status; the list is what makes it fixable in five minutes.
The three states that go missing
Worth checking explicitly, because they are complete in the designer's head and absent from the file.
| State | How it usually goes missing | What the check asks |
|---|---|---|
| Empty | Designed once in a different file, never linked | Is there a frame for zero items? |
| Error | Discussed in a comment thread, never drawn | Is there a frame for the failure case? |
| Loading | Assumed to be the standard spinner | Does the ticket say which loading treatment? |
Questions people ask
+Can the worker export assets itself?
No. It reports which referenced assets are missing from the shared folder, and exporting stays with the designer. Delivery in Polaris is a comment on the task, which can carry generated documents such as the written spec.
+What does it do about responsive breakpoints?
It checks for whatever your ticket template asks for. If the template names three breakpoints and the file has one, that appears in the not-ready list. If the template says nothing, neither will the check, which is a template problem worth fixing once.
+Who runs the check, the designer or the engineer?
Usually the designer assigns it before marking the ticket ready, which is the point where the fix is cheapest. Some teams assign it on the engineering side as a gate, which works but produces more back-and-forth.
+Does this need a Figma seat for the worker?
It uses the Figma connection from the Polaris catalog, authorised once for the organisation. Credentials are verified at connect time and stored server-side, so workers use them and browsers cannot read them back.
Related
Design work an AI teammate can take, and the part it cannot
Five jobs around the work, none of them the work itself. Taste stays where it belongs.
Twenty minutes of every design review goes on finding the file
The agenda written the day before, with last review's unresolved threads at the top.
Six open pull requests and nobody knows whose turn it is
The review queue, ordered by age and named by who is blocking it, posted every morning.
Connect Figma to Polaris
A Figma token belongs to a person, and Polaris shows you which person it verified, which is the detail worth checking before you store it.
Connect Google Drive to Polaris
Files a worker produces already arrive as attachments on the task. Files your team already keeps in Drive are the part still waiting.
Connect Linear to Polaris
A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.
Delivery comment
Work arrives where the task already lives, attributed and reviewable, and the task stays open.