reqwise-figma-mcp: Skill for Claude Code

/figma-erd — What we store, and how it joins

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 an ERD.

Goal

Make the data model reviewable by people who will not read a migration. Tables, the columns that matter, and — the part that is usually wrong — which column joins to which, and how many of each side.

Output: one Figma frame ERD · <title>, plus the model problems it exposed.

Constraints

Hard rules — never violate

• Name the columns on every relation. fromField and toField are what make the line attach to the row that actually implements the relationship, and what lets a reader check the picture against the schema. A relation without them is a decorative line.
• Every table gets a primary key unless it is external: true (a table another system owns). The tool reports the ones that do not.
• Use the real names. loan_applications, customer_id — the names in the database or the ones the team has agreed to use. A pretty diagram with invented names is worse than no diagram, because someone will code against it.
• Pick one naming convention and hold it. snake_case or camelCase, not both. Mixing them is reported, and it is reported because it is always a merge of two people's work that nobody reconciled.
• Never invent a column to make a join work. A relation naming a column that does not exist is a finding about the model, not a typo to paper over.

Write it in the compact form

text is a table, then its indented columns, then the relations. Unlike mermaid's erDiagram, the relation line names the columns on both sides — which is the whole point of an ERD line and the thing that makes it checkable against the schema.

users happy / core.auth          # class, and a detail line after "/"
  id uuid pk!                    # ! = NOT NULL
  email varchar(255)!
  created_at timestamptz
bookings
  id uuid pk!
  user_id uuid fk!
  status varchar(16)!
booking_seats                    # the join table, spelled out
  booking_id uuid pfk!
  seat_id uuid pfk!
psp_transactions ext / owned by the payment gateway
  reference varchar(64)!
  booking_id uuid fk!
users.id 1-* bookings.user_id "books"
bookings.id 1-? psp_transactions.booking_id "paid by"    # ? = zero-one, so it is optional
bookings.id 1=+ booking_seats.booking_id "holds"      # = identifying, + one-many