u/ojanti

# Open to discussion/ideas/learnings

When I was thinking about how to setup an intuitive AI powered DS System, I drew an initial version of this diagram (before any setup)

A lot of the content I see, info from colleagues in the DS space and even my observation within a company I recently worked with, many seem to be using AI to do specific parts of this system in fragmented & isolated ways.

The diagram attached is an example of how I think design systems and AI should work together. A proper stack

The pink boxes are the bet: if the documentation is good enough, AI output should stop looking well... 🫠

I've been building toward this map for a while. A few things I've learned already:

• The brain (ds-brain) sits in the middle - not Storybook, not the component source files
• You maintain docs once - skills, rules, indexes, and Storybook fragments fall out of a generator
• Storybook is a consumer of the brain, not the other way around
• The IDE/Cursor path is where I've shipped and measured the most so far
• AI inside Figma still needs love - I'm exploring options (MCP? CLI?). This should be interesting.

For me it's not enough to say "I designed the system - use it." I'm running tests and tracking metrics:

• Scoring outputs against a rubric
• Counting when agents invent components that don't exist
• Accounting for contamination - Running trials in isolated environments so experiments don’t poison retrials.
• ... and much more

So far, some scores made me proud. Some stung. All of them taught me the same lesson:- Don’t start with the AI box. Start with the documentation package. Everything else is plumbing.

I'll share more of what I'm learning over the next few weeks - the wins, the misses, and what actually moved the needle. If you have any ideas, observations, please feel free to share :)

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. 🙌

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. 😊

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