u/ojanti

One click component documentation with history and drift detection in Figma. Also supports & preserves custom content

You've seen a bunch of specs plugins. Hear me out on this one 😄

I took some time to create Ogiso Docs for Figma. Select a component, generate full documentation in one click. No (complex) setup. No AI.

✔️ A documentation suite, not one-off frames with drift detection.

It has a registry that tracks every component you've documented in the file. No hunting scattered frames. It detects drift when a component API changes so you know when docs might be stale
It also has a history timeline (created, updated, recreated) gives you a full audit trail per component.

✔️ Built for real component complexity

People created components in different ways. This really tries to work with how you work:

  • Simple components and component sets with props
  • Components with embedded masters and nested structure
  • Inner props that surface at the outer API
  • Related-but-separate pieces (Button/Primary, Button/Secondary as different sets, not one mega-set). Family docs tie those together without pretending they're one fictitious component.

✔️ Prop logic and dependencies

It surfaces non-obvious rules automatically. e.g. "secondary action only applies when primary action is enabled." The doc reflects how the API actually behaves, not just a flat property list.

✔️ Lock in your manual work across regenerations

Extend or rewrite any section, rename the layer with ::lock and that subtree survives updates. AI prose + human polish? Update refreshes what's unlocked. Recreate when you want a full reset.

✔️ Other hits/features worth knowing

  • Two profiles: Standard (overview, anatomy, properties, prop logic, showcases) and Minimal (overview + properties)
  • Showcases: visual grids over enum axes and boolean toggles, not just tables. Responsive layout adapts to component size
  • Export: Markdown and JSON when you need the same truth outside Figma
  • Quick nav: jump from registry to docs frame or back to the source component in one click
  • Privacy-friendly: runs against your file, no external API required

The core engine is pure TypeScript with zero Figma coupling. So the same analysis logic can power a CLI, codegen, or MCP hooks later.

Try it here: https://www.figma.com/community/plugin/1628339309563064946
It's free. Let me know your feedback, happy to go deeper on any part of it. 🙌

u/ojanti — 8 days ago

How I handled component anatomy generation while customising my storybook setup

One of the issues I have with Storybook is that it felt... bare. No docusitey polish, no anatomy diagrams, none of that Zeroheight or Supernova feel. While setting up DS documentation not so long ago, I decided to supercharge and transform my Storybook, with minimal change needed to existing components and done in a scalable way. Not touching the core or SB so I can update it safely in the future. 🧩

I'll get into the other customisations and automation separately, but one part I enjoyed was component anatomy.

Why bother?

To know the key constituent parts, where the affordance lives, what's optional chrome versus core structure. The goal wasn't decoration. It was shared mental models between design and engineering.

The old ways

  1. Static diagrams that go stale the moment the component changes
  2. A parallel metadata sheet of coordinates, labels, and relationships stored next to the UI instead of grounded in it

The approach

Stamp data-slot or data-part attributes directly onto the live DOM. Two ways to get there depending on your setup:

  • You own the component code. Wire the attributes in internally, proceed with core anatomy code.
  • You don't (third party lib, or you'd rather not "pollute" component code with doc metadata). This was my case. What I did was have a patcherRegistry maps each component to a small function that walks the DOM of the *live component instance rendered in Storybook*, and patches the slots in e.g. "the label is the second child of the first child of the button." It writes data-slot attributes onto the right nodes, runs on mount, and a MutationObserver keeps it live for anything that portals outside the specimen container.

Once slots are stamped, layout kicks in. ✅

  • Measure each labelled element's bounding box
  • Compute which side of the component it sits on
  • Position a numbered pill in the gutter (top, bottom, left, or right)
  • Stitch each pill back to its element with an SVG L-path connector

Everything remeasures on resize and font load, batched through requestAnimationFrame.

The escape hatch 🎯

Anatomy layout is half-algorithm, half-taste. Pills overlap. Things land awkwardly for certain component shapes. Rather than chasing every edge case algorithmically, there's a secret URL parameter. Hit it and every pill becomes draggable. Drop it where it looks right, offsets POST to a local dev endpoint, get saved to JSON, and production reads them back automatically. Reset button if you want a clean slate.

It means the diagrams can always look intentional, without the layout algorithm needing to be perfect. 😊

u/ojanti — 14 days ago

While working with an engineering team recently, I built a Figma plugin for syncing Figma variables with tokens (of opinionated different formats) in GitHub.

Main issue I was dealing with was keeping things aligned without breaking aliases, modes, or accidentally overwriting stuff.

Another issue was engineering using specific token structures. e.g Tailwind / shadcn / Tamagui where token formats don’t really match Figma variable structure and naming well.

What helped was mapping tokens > variables, tracking drift, and showing diffs before updating so changes aren’t blind.

reddit.com
u/ojanti — 22 days ago
▲ 46 r/FigmaDesign+1 crossposts

Hi! I built a plugin for Figma that connects variables to token files in GitHub.

Main problem I was trying to solve: keeping variables aligned with repo tokens without breaking aliases, modes, or overwriting things blindly.

The plugin maps tokens -> variables, tracks drift, and shows diffs before you update, so you can control what changes.

It’s been useful in setups where the repo is the source of truth, but I’m curious how others are handling this.

Would love feedback from anyone working this way. Sharing the plugin if anyone’s curious

u/ojanti — 22 days ago