--- title: "Dock for Design: design-to-engineering handoff with attributed agent specs" excerpt: "Figma's Dev Mode shows the spec; the implementation ticket lives in Jira or Linear. Dock is the handoff workspace where the agent posts the spec summary, component mapping, edge cases, and engineering questions, with the engineering lead acking before the ticket is taken." author: mei category: Use Cases date: "2026-05-30" --- Design-to-engineering handoff works when three artifacts line up: the visual spec, the implementation ticket, and the interpretation that connects them. Figma's [Dev Mode](https://help.figma.com/hc/en-us/articles/15023124644247-Guide-to-Dev-Mode) carries the spec. Jira or Linear carries the ticket. The interpretation, what changed since last sprint, which component map applies, which edge cases the agent flagged, has historically lived in a Slack thread that nobody can find on Monday. Dock holds that interpretation as a row, attributed and acked, so the ticket leaves the queue with engineering's signature on it. Figma stays the system of record for the canvas itself. The frames, layers, components, and auto-layout rules live there, and Dev Mode is the surface engineers inspect for measurements and tokens. Dock is the system of record for what the agent and the team interpret around the canvas: the spec summary, the variation rationale, the component-mapping decision, the open engineering questions, and the ack timestamp. Each Dock row carries a pointer to the Figma file (`figma_file_key`, `figma_node_id`) and to the downstream ticket (`linear_issue_id` or `jira_issue_key`), plus agent identity, reviewer, decision, and time. The agent re-fetches Figma on demand to confirm current state. Dock is the persistent interpretive layer that survives the handoff. ## The handoff queue | handoff_id | figma_node_id | component_map | edge_cases | linear_issue | spec_author | eng_ack_by | ack_at | |---|---|---|---|---|---|---|---| | HO-318 | 4821:992 | `Button/Primary` -> `` | loading state, RTL, 44px tap target | LIN-2104 | argus | rohit@ | 2026-05-28 09:14 | | HO-319 | 4912:104 | `Card/OrderRow` -> new `` | empty list, 3-line truncation | LIN-2117 | argus | priya@ | 2026-05-28 14:02 | | HO-320 | 5004:71 | `Modal/Confirm` -> existing `` | focus trap, ESC, mobile sheet variant | pending | argus | rohit@ | awaiting ack | ## A worked handoff Mei finalizes a checkout-row redesign in Figma and tags the frame ready-for-dev. Argus, the design-ops agent, reads the frame via the Figma API, drafts row HO-319: a 90-word spec summary, the component-mapping decision (re-use `Card/OrderRow` versus introduce `OrderRowCompact`), three edge cases pulled from the existing [component library audit](/blog/design-component-library), and two open questions for engineering. The row links back to the Figma node and forward to a draft Linear issue. Rohit, the engineering lead, opens HO-319, answers the two questions inline, sets `eng_ack_by` to himself, and acks. Argus then promotes the Linear draft to a real issue with the ack metadata stamped in the description. The ticket enters the sprint with a named author, a named acker, and a timestamp. ## Why it matters Attribution is the first reason. When the build ships and QA finds a regression, the handoff row says which agent wrote the spec, which engineer acked it, and which Figma version was current at ack time. The audit trail is the same one we describe in [agent audit and compliance](/blog/agent-audit-and-compliance), and it is the only reliable way to reconstruct intent six weeks later. Handoff is the second reason. The Slack-thread version of this workflow loses on the Monday after a designer leaves or an engineer rotates off the squad. The Dock row does not. A new engineer opens HO-319 and sees the spec, the questions, the answers, and the ack, with the same pointers to Figma and Linear that the original participants used. Agent identity persists too, which matters because the same drafting agent will be back next sprint; see [agent identity lifecycle](/blog/agent-identity-lifecycle). Design-team daily-driver experience is the third. Designers do not want to leave Figma to file tickets, and engineers do not want to read a 12-tab Figma file to find the one frame that changed. The agent does the translation, the designer confirms in a single row, and the engineer acks in the same row. The handoff stops being a meeting. This is the same pattern the broader [Dock-for-Design pillar](/blog/dock-for-design) applies across briefs, reviews, and production assets, and it is the spec half of the [Figma design-ops workflow](/blog/dock-figma-design-ops). Engineering teams already report that unclear requirements are a top time-sink ([Stack Overflow Developer Survey 2024](https://survey.stackoverflow.co/2024/)). An attributed handoff row is the smallest fix that closes the loop. For irreversible moves like deleting a shared component, the same row participates in a [two-key handshake](/blog/two-key-handshakes-irreversible) before the agent acts. Read the full [Dock-for-Design pillar](/blog/dock-for-design) for the brief, review, and asset-queue surfaces that surround this one. ## FAQ **Where does the spec actually live, Figma or Dock?** The visual spec lives in Figma. Dev Mode is the inspection surface. Dock holds the agent's spec summary, component-mapping decision, edge cases, and the engineering ack. The Dock row points to the Figma node; it does not duplicate the frame. **What does the engineering lead ack, exactly?** The lead acks the spec summary, the component mapping, the edge-case list, and the answers to the agent's open questions. The ack is a row-level decision with a timestamp and an identity. The Linear or Jira ticket is created only after ack. **Can the same agent both draft and ack?** No. Drafting and acking are separate roles on the row. The drafting agent has a named identity. The acking engineer has a named human identity. A two-key pattern applies for any handoff that touches a shared component or a destructive change. **What happens if the Figma frame changes after ack?** The agent re-fetches the frame on the next read and writes a new row that supersedes the old one. The old row stays in the audit trail with its original ack. The new row needs a fresh ack before the ticket is updated.