There is no package to add, no config to write and no build step to wire up. Everything below is a way of putting one folder somewhere a model can read it, and the differences between them are about where you already work.
The first needs no configuration at all. The rest are one line, one paste, or one path.
01Explore real products →Create a design-system project, drop the unzipped contents at its root, and open it. The compiler finds styles.css, the 54 components, the 78 cards and the 8 templates on its own. There is nothing to configure and nothing to run first.
SKILL.md already carries its front matter and AGENTS.md explains how to assemble a screen. Drop the folder into a skills directory and it loads as a skill — the rules arrive before the first component does.
The markdown package is the whole system without the machinery, so it travels anywhere a model reads context. Paste the design guide and the .prompt.md pairs into v0, Lovable, Bolt, Cursor or your own harness. No install, no runtime, no assumption about the stack it will produce.
Every templates/<slug>/ is self-contained but for one line: ds-base.js holds the path back to the system root. Repoint that string and the prototype renders anywhere. Read the matching notes file first — it documents the fixtures and the data model.
None of them are subtle once you know about them, and all four are the same mistake: something moved that the folder expected to find where it was.
02Straight answers →The file was not read. Check it sits at the root rather than a level down, and that the session was started after it landed. A model that never saw the file will produce exactly what it produced before.
tokens/fonts.css resolves the font files relative to the stylesheet. Flatten the tree, or serve styles.css from a different depth, and both faces fail silently to the system stack. Keep the folder shape.
The bundle namespace is derived from the project it was compiled in, so a fresh install gets a different suffix. Resolve it rather than hard-coding it — the lookup is one line, and it is in the setup step above.
Three files are generated and committed on purpose: the bundle, the manifest and the adherence config. Editing them by hand works until the next compile, which silently puts them back. Change the source instead.
What comes up once it is in place: whether it holds, what it costs to keep, and how to get it out again.
03Back to the top →It ships components and tokens, but that is not what you are buying. The product is the rules layer that decides what gets computed, what gets shown and what gets refused — plus the machinery that makes those rules checkable.
It is built for Claude Design users generating business UI. Because the layer is plain markdown loaded as project instructions, anything else that reads a rules file will use it too. There is nothing proprietary to integrate.
The tokens are yours to set and brand fit is a config change. The judgement rules are not configurable, because that is the product. If you want a different opinion about derivation, you want a different product.
The rules are written against behaviour rather than internals, so upstream releases move underneath them. Where a rule does need to change, it changes in one file you can read in an afternoon.
Marginally slower on the first generation. Considerably faster by the fourth, because you are not re-prompting it to fix a total that never tied.
Reckon
Components are the easy part. What you are missing is the layer that decides what gets computed, what gets shown, and what gets refused.