--- name: skill-design-review-round type: skill description: >- Run a design review round from a design tool's comments to agreed, ticketable work — capture every Figma (or other design-tool) comment of a review round into one dated Linear document with its text, the element it sits on and its permalink, triage the table with the Owner to an agreed approach per comment, raise tickets only from the agreed approach through the normal capture, refine, ready path, and keep the document as the round's status by linking each row to its ticket or its not-changed note. Use this whenever a client or the Owner has left review comments in Figma, a prototype or a design file that need to become work, or when asked to collate, triage or close out a review round. Never lifts a comment straight into a ticket and never promotes a ticket to ready; the round document is where an observation becomes a decision. Owned on the Sonar and Pixel side; the triage step is held with the Owner. license: CC BY-NC-SA 4.0 --- # design-review-round The intake path from a design tool's review comments to work. A Figma comment is an observation, not a decision; this skill is where it becomes one. It exists because the alternative — lifting each comment into its own ticket with a line of assessment and a routing verdict — produces tickets that read as refined and are not: on the A1-294 round, 18 comments became 14 leaves, none carrying acceptance criteria or a definition of done, six promoted to Todo within ten minutes, four created straight into In Review, and every one that reached a builder cost a cycle (APP-743). The round document fixes that at the source, and it also gives the Owner the whole round in one table rather than comment by comment. Follows `convention-ticket` (for the tickets it produces), `convention-linear` (for the document), `convention-comms-owner` (for the triage session), and the gate policy — the Owner promotes, never this skill. Owned on the Sonar and Pixel side: Sonar where the round is discovery or service feedback, Pixel where it is visual or interaction feedback; the triage step is held with the Owner either way. ## Trigger A review round has happened — a client, a stakeholder or the Owner has left comments in Figma, on a prototype, or in another design tool — and they need to become work. Also on request: "collate the Figma comments", "triage the review round", "close out the round". Not for a single ad-hoc comment that is already a decision (that is a normal capture); the skill is for a *round*, a batch left in one sitting or against one version. ## Behaviour Four steps, in order. Nothing is ticketed before step 3. ### 1. Capture into a document first Create one Linear document per round, dated, in the client or venture project: `.design-review.YYYY-MM-DD` (naming per `convention-linear`, *Documents*). It holds one table with a row per comment, in the tool's own order, with these columns: | # | Comment (verbatim) | Element / pin | Permalink | Approach | Status | | -- | -- | -- | -- | -- | -- | - **Comment** — the text exactly as written, with the author and date. Never paraphrased at capture. - **Element / pin** — what the comment is attached to: the frame, component or region, named as the file names it. Where the pin is ambiguous, say so rather than guess; a mis-attached comment mis-scopes every ticket downstream (A1-298 sat on the wrong element for weeks). - **Permalink** — the per-comment Figma URL, one click back to the pin. Load-bearing context, on a par with the text; a frame link on the parent is not a substitute. - **Approach** and **Status** — empty at capture. Filled in steps 2 and 4. Where the tool exposes replies or resolution state, capture those on the row too. Where a comment is an image or a marked-up screenshot, extract it and attach it to the row (`convention-linear`, extracting an image in a comment). ### 2. Review and triage the table Before anything is ticketed, the table is triaged **with the Owner** — in session, or by the Owner marking the document. For each row, agree one approach: - **Change the design** — the comment is accepted; work follows. - **Do not change, with a note** — the comment is declined or already addressed; the reason is written on the row. - **Needs discussion** — the comment is a question, a feel judgement, or a conflict with a logged decision; it stays open on the row until resolved, and where it turns on feel it is routed to `playbook-prototype-config-panel` rather than to a value guess. Group rows that are one change described three times, and say so on each. Check every "change" row against the project's decision log before agreeing it — a comment that contradicts a Locked decision is a *needs discussion* row, not a ticket (`convention-ticket`, the mirror collision). Write the approach on the row in one line. The triage session follows `convention-comms-owner`: recommendation first per row, the whole round visible at once. ### 3. Tickets only from the agreed approach For each row agreed as *change the design*, raise work — and only then. The ticket follows `convention-ticket` in full: the standard shape, instantiated from its `type:` template (bug, task or story, whichever the change is), with `## Acceptance criteria` written by the author against the states the change must hold in, and `## Definition of done` from the type. It lands **captured** (Backlog) and goes through capture → refine → ready like any other; it is never created straight into Todo or In Review, and never carries a routing verdict in its body. The ticket's body cites the round document and the row, and carries the permalink; it does not restate the comment as its specification. Several rows that are one change become one ticket; one row that is several changes becomes a typed parent with sub-issues split by dependency. ### 4. Tickets are the status on the review document Fill each row's **Status**: the ticket link for a change row, the reason for a not-changed row, "open" for a discussion row. The document then shows that every comment was considered and how it was acted on, and it stays the round's status until every row is closed — a change row closes when its ticket is Done, a discussion row when it becomes one of the other two. Where the tool supports it, reply on the original comment with the row's outcome and permalink back to the document, so the client sees the loop close where they left the comment. ## Guardrails - **Never comment-to-ticket directly.** A comment reaches a ticket only through a triaged row with an agreed approach. This is the rule the A1-294 round broke, and it holds however clear a comment reads. - **Never promote.** Tickets land captured; the Owner moves them to ready (`convention-ticket`). - **Never paraphrase at capture.** The verbatim text and the permalink are the evidence; interpretation goes in the Approach column, after triage, not in the Comment column. - **The triage is the Owner's.** This skill prepares and records the triage; it does not agree an approach on his behalf. Where he has delegated a round to the venture's operator, the operator holds the triage within mandate. - **One document per round.** A second round on the same file is a second dated document, not an edit to the first; the earlier document keeps its status as the record of that round. - **Feel is not a value guess.** A row that turns on how something feels in motion goes to a config-panel prototype (`playbook-prototype-config-panel`), not to a ticket with a guessed duration. ## Setup Cowork or a working session with the Figma connector (read the comments, resolve permalinks) and Linear (the document and the tickets). Invoked by `skill-dispatch-run` on a `SO-N4R` or `P1-XEL` ticket whose deliverable is a review-round collation, or on request. The triage step (2) needs the Owner or the venture operator present, in session or asynchronously on the document. On finish, run `skill-ops-retro` capture on this run's friction: search the Pulse queue first and add the evidence to a same-root note if one exists, otherwise file a new FRICTION note for the drain pass to assess.