reqwise-figma-mcp: Skill for Claude Code

/figma-sequence — What is sent, and in what order

Read ../reqwise-diagram-rules.md first — connection gate, the four levels of correct, the findings loop, frame placement, verification. This file carries only what is specific to a sequence diagram.

Goal

Pin down an exchange between systems. This is the diagram for the part of an integration spec that is vague until someone draws it: what is sent, in which order, and what comes back — including on the unhappy path.

Output: one Figma frame Sequence · <title>, plus the contract questions the diagram exposed.

Constraints

Hard rules — never violate

• The order of messages IS the time order. There is no timestamp field and no sorting. The array is the diagram. Reordering the array reorders the picture.
• Every message has an id — fragments reference them, and findings name them.
• Every message has a label that says WHAT is sent, not that something is sent. POST /contracts/{id}/sign-otp and 202 { otpSentAt }, not "gọi API" and "trả về". This is the field people argue about six months later; it is why the diagram exists.
• Order the participants so the exchange mostly flows one way. Arrows crossing back and forth across five columns is a layout problem you fix by reordering the array, not by fiddling with the drawing.
• Never invent a reply. If the spec does not say what comes back, that is the finding.

Write it in the compact form

text is mermaid-shaped on purpose — that is the sequence notation everyone already knows — and it drops the two things that were pure overhead in the array form: message ids, and the messages: ["m3","m4"] list inside each fragment. A block's extent is simply where it is written.

actor       user  "User"
participant api   "Booking API" / booking-svc
db          store "Bookings DB" / postgres
external    psp   "Payment Gateway"
user ->> api: POST /holds { seatIds }        # ->>  a call, and it opens an activation bar
api  ->> store: INSERT booking_seats
store -->> api: ok                            # -->> a reply, and it closes the bar
alt seats free
  api -->> user: 201 { bookingId }
  note: hold lasts 10 minutes
else already booked
  api -->> user: 409 seats_unavailable !err   # !err colours the failure path
end
api --) psp: capture(bookingId)               # --)  fire and forget