OpenDesigner: ship a design system for your project with a few answers

Who it's for

For developers and small teams who already use an AI coding assistant but whose project still lacks one consistent set of visual rules: you may have only a few design mockups or a couple of spoken descriptions, while colors, fonts, and spacing are hard-coded differently in every page; or the project is so new that nobody can spare the time to build a full design system first. This is an add-on for the AI tooling you already use: it turns hard-to-articulate taste into files the code can consume directly, instead of sending you off to another design application; it is a free, MIT-licensed open-source project that does not replace the editor you work in, it only adds a layer of capability to it. Anyone willing to answer a few short questions, to accept results written into the project directory, and to give them one more read before merging is well placed to try it once. If you have just taken over someone else's code and want to get a feel for the visual tone first, you can use it for a quick survey.

Your first attempt in 3 minutes

Check the prerequisite first: you need Python 3.10 or later on your machine. The engine is a single Python file, with no dependencies to install.

Step one, install the skill. The recommended path is the Claude Code plugin marketplace: type /plugin marketplace add ckryptickunal/OpenDesigner in the conversation, press Enter, then type /plugin install opendesigner@opendesigner.

Step two, know where it lands. Tools that support Agent Plugins read the plugin.json file at the root, while clients that read skills take their files from the .agents/skills/ directory by convention; for clients that do not go through the plugin marketplace, you have to copy the skill into your project's .agents/skills/ yourself.

Step three, trigger a low-risk task. Open your project, say "Create a design system for this project." in the conversation, and it will pose at most five short questions, each with a suggested answer and the reasoning behind it, so you confirm or rewrite them one by one. For the first run, pick a clean directory or open a branch first, so the generated tokens do not get mixed in with existing code.

Step four, agree on side effects and confirmation points in advance. The engine writes its results as DESIGN.md, PRODUCT.md, and an opendesigner/ directory holding the tokens, the various exports, and an overview page. Writing to disk directly rewrites repository content, so create a branch or make a commit first; let it write only after you have confirmed the answers.

Step five, watch for observable success signals. The three artifacts above show up in the project, and the self-check reports no errors: text contrast is validated against WCAG 2.2 AA, tap targets are at least 24 px, keyboard focus is visible, and the reduced-motion preference is handled; any error stops the build.

Use cases

Case one: lay down the first version of a design system for a new project. Once the plugin is installed, say the English trigger phrase above in your project, answer the at most five short questions it asks, and you get a complete design system rather than scattered fragments. The first version does not have to be perfect; it is the starting point for your follow-up questions and iterations. From there you can drill down: colors, fonts, spacing, and motion can each be refined with another round of questions, and the output always lands in the same three files and directories. The evidence stops there: the official documentation states that the question cap is five and that the refinement dimensions are these four, but it says nothing about whether the number of questions can be adjusted, and it does not describe the interaction format of each refinement round.

Case two: reuse the same skill in a client without a plugin marketplace. Copy the skill into the project's .agents/skills/ directory, then request a design system in the conversation as usual and answer the questions; the output and the self-check rules are exactly the same as in case one. If the project already has its own token conventions, confirm that the two naming schemes will not collide before you copy. The official documentation only says that these clients read skills from that directory; it does not explain how to update after the copy, and it gives no additional dependency or configuration steps.

Limits of use

The engine has exactly one hard requirement: Python 3.10 or later, with no dependencies to install beyond that. The installation paths are likewise only the ones the official documentation states: outside the plugin marketplace, the skill must be copied by hand, and the project provides no auto-update or verification command for that manual route. At runtime it rewrites project files directly, so make sure a branch or commit exists before you start. The built-in self-check is a hard gate: contrast below WCAG 2.2 AA, tap targets under 24 px, invisible keyboard focus, or an unhandled reduced-motion preference will all stop the build; it does not fix anything for you, so you have to correct the issues and run it again. The five-question format assumes the questions can be answered briefly; when complex business rules come into play, the engine cannot make the judgment call. A design system is not a final product either: the tokens and documents live in the repository, and neither how to merge them with an existing component library nor whether to bring them under version control is described in the official documentation, so you have to decide that yourself. Repository: <https://github.com/ckryptickunal/OpenDesigner >.