v3.17.0 — Runs on your team's tools

Ten days, 13 releases of fig and 16 of pm. The through-line is that both
plugins stopped assuming the tools, the conventions and the machine were ours.

The tracker is yours, and so are its rules

• Adapters are open: trackers/<type>.md and sources/<type>.md hold the
  calls, the config picks the file, and a type nobody bundled still runs.
  Chat and calendar are adapters too
• A ticket's sections come from the tracker's published template, in its
  order — not from this workflow's preference
• Where the tracker is governed by a written rules document, task.policy.doc
  is read before the first write of a session, and the rules win
• A task with no parent is a legitimate answer

A ticket now says when the work is finished

• Done conditions and a QA checklist, drafted from the spec entry and the
  design before anything is asked, and contract.level puts them on the
  ticket where review actually happens
• Every QA step traces to a done condition; a condition no step reaches is
  the gap the section exists to close
• A ticket filed before its requirement exists says so, rather than filing
  a confident placeholder
• One already-filed ticket can be brought to the template — one preview,
  one "go", never a batch

Handing over is a step with a gate

• /fig:handoff — lint is the gate, the person picks the sections, and the
  handover pins a Figma named version so every link carries &version-id=
• Violations come back blocking or warning. A gate that stops
  everything stops being a gate
• /fig:lint reads component sets, catching variants stacked invisibly on
  one another

A shared config knows its own age

• --origin reports symlink, work tree, commits behind, last fetch, and a
  SessionStart hook says so only when a copy has fallen behind
• --need stops a skill on a null it cannot run without; --authored
  stops one about to write on a value no config of yours mentions
• proto_publish declares its six keys rather than naming them in a comment

Starting from nothing

• /fig:setup and /pm:setup run as onboarding — what it produces first,
  a named ladder, questions in your words, "leave it blank" on every one
• Preflight leads with a verdict in plain words, and requires whatever tool
  your config names
• A starter path for a team with no conventions yet

v3.4.0 — Setup checks the machine first

Setting these up used to mean checking four things by hand and hoping. Now the setup step checks them for you and names what is absent.

fig 3.4.0 · pm 0.6.0

The failure that never announced itself

The README already carried the warning: a skill cannot call a tool it was never given, and it does not fail loudly when one is missing — the run simply comes back thin, and that reads as the skill having found nothing to do. It was listed under troubleshooting, which is to say you met it after losing the time.

/fig:setup and /pm:setup now open with a preflight. It reports python3 and PyYAML, node, and which connectors actually answer, then stops if something required is absent rather than running on.

An optional connector that isn't connected comes back as absent rather than a failure — it only matters once a config key points at it, and the report says which key that would be. Claude in Chrome comes back unknown: it is a browser extension rather than an MCP server, so the shell genuinely cannot see it, and guessing would be worse than saying so.

Getting started branches

The install step has always offered pm as optional, and then every step after it was written for fig. If you installed pm alone, the guide ran out.

Step 2 is now a fork — fig, pm, or a deck template — with each path carried through to its own end. /fig:deck-setup, which has to run before /fig:deck and was mentioned twice in passing further down the page, sits in that table.

Both plugin READMEs also say what the setup step checks before it runs, and the Korean and English READMEs stay line-for-line aligned.

---

Full documentation: README · 한국어

v3.3.1 — What each skill declares

A maintenance release. Nothing changes in what the skills do; what changed is what they say about themselves.

fig 3.3.1 · pm 0.5.3

allowed-tools matches what the skill actually calls

Three skills named none of the MCP tools they reach for. /fig:deck creates a Slides file and uploads images, /fig:deck-setup measures a template through the Plugin API, and /pm:prd writes to Notion when prd.target is notion — while the other sixteen listed theirs. They do now.

Skill came out of allowed-tools in the same pass. Eight skills tell you to load figma-use first and only one of them had listed it; across twenty skills in other marketplaces, none do. All nineteen agree now.

Two skills state their prerequisite

/fig:deck-setup and /fig:proto both run use_figma, and neither said to load figma-use before it — the line the other eight carry.

From the README

• A dependency table under the prerequisites: what each skill needs beyond plugin:figma — Chrome, Notion, Slack, GitHub
• The scope wording covers the work before the drawing as well as after it

---

Full documentation: README · 한국어

v3.3.0 — English release

First tagged release. Both plugins are now fully in English, and the repo carries a getting-started path and a troubleshooting section.

fig 3.3.0 · pm 0.2.0

Everything is in English now

All fourteen skill bodies (fig 13, pm 1), the script comments, the manifests and the repo tooling were translated. Two things stayed in Korean on purpose:

• Trigger phrases in each skill's description: — they are what makes a Korean sentence route to the right skill
• Detection patterns in draft-conventions.py and verify.py — section names are written in the team's own language, so dropping them would narrow what the probe can find

Your output language does not change with this. meta.language decides it: auto follows whatever language you are talking in, and a tag like ko pins it. English skill bodies, Korean reports.

Getting started and troubleshooting

The README now opens the install path as prerequisites → install → point it at a file → judge the first audit, and closes with eleven troubleshooting entries — every one of them a failure actually hit in use, not a guess. Among them:

• A report that says it ran on defaults means the config is not being read at all
• An installed plugin is pinned by version in the cache, so editing a skill changes nothing until the version is bumped
• A 401 from Figma covers "no token", "expired" and "invalid" alike

Fixes

• The link to conventions.example.yaml in both READMEs pointed at a path that does not exist
• verify.py reported qa.environments.<name> as an unknown key. It is a map whose keys the user names, like files.<fileKey>, so schema membership does not apply — both are exempt now

---

Full documentation: README · 한국어