Design OS workflow
A workspace for Claude Code: ten commands lead from a product idea to React screens and a handoff package with ready prompts for implementation
- 1,864 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- The commands create and overwrite files in `product/`, `src/` and `product-plan/` inside the cloned project
- It needs `npm install` from the network and a local development server on port 5173, and Playwright MCP for screenshots
- `/export-product` builds the `product-plan.zip` archive with all the design content
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add workflows/design-osDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The commands create and overwrite files in `product/`, `src/` and `product-plan/` inside the cloned project
- It needs `npm install` from the network and a local development server on port 5173, and Playwright MCP for screenshots
- `/export-product` builds the `product-plan.zip` archive with all the design content
This is third-party code. Review the repository files before installing.
What it does
Design OS is a Vite and React project template with Claude Code commands attached from the `.claude/commands/design-os/` folder. You clone the repository, run `npm install` and `npm run dev`, open http://localhost:5173 and start `claude` in the same folder. From there the agent leads a conversation step by step: it asks questions, you answer, and the result lands in files and in the window on localhost. The first phase is planning. `/product-vision` gathers the product description, roadmap sections and data shape, `/design-tokens` picks colors and fonts, `/design-shell` designs navigation and the shared frame. The second phase goes section by section: `/shape-section` writes a spec, five to ten sample records and TypeScript types, `/design-screen` builds React components that take data and callbacks through props, and `/screenshot-design` captures the screens. `/product-roadmap`, `/data-shape` and `/sample-data` edit what already exists. `/export-product` checks that a product overview, a roadmap and at least one finished section exist and builds the `product-plan/` directory: instructions for implementing everything at once or in milestones, two ready prompts for a coding agent, `tokens.css` with Tailwind and font hints, a data type overview, shell and screen components, and test descriptions for each section. All of it is also packed into `product-plan.zip`. You can run the export again as sections are added.
Who it is for. For founders and developers who want to design the product and interface with an agent first and then hand another agent or a team a finished brief for implementation.
Good fit when
- You have a product idea but no requirements or screens and want to walk through them step by step without letting the agent start coding
- You need sample data and TypeScript types so the interface can be designed before a backend exists
- You want to hand implementation to another agent or a team as a package with instructions, prompts and test descriptions
- The product has several sections and each needs separate work: spec first, then the screen
- You need one source of truth for colors, fonts, the app frame and data entities before development starts
Not a fit when
- You need to fix the interface of an existing project: Design OS starts from a clean template and does not attach to your code
- Your agent cannot run custom commands: Design OS works through slash commands, and without them the project is just a template
- You need a Figma design: the output is files and React components in a local app
- Your product already has a design system: the commands create their own colors, fonts and frame from scratch
- You need fine animation and polish: the project builds structure and screens rather than finishing details
Example request
/product-vision I am building an invoicing service for small studios: clients, invoices, payments and reminders. Help me describe the product and its sectionsLimitations
It is a template rather than a package: you clone it, detach the original remote with `git remote remove origin` and work in the copy. It needs Node.js 18 or newer and an assistant that can run custom commands: the author recommends Claude Code and allows Cursor, Windsurf and Codex. Installation instructions live on buildermethods.com/design-os. The receiving project needs React 18 or newer and Tailwind CSS 4 for the finished components.
The result stays in this template: sample data and screens live in `product/` and `src/sections/`, and only what you carry over from `product-plan/` reaches your real project. The commands design the interface and data and do not ask about databases or server logic.
`/screenshot-design` starts the server itself and captures screens through the Playwright MCP: without it the command offers setup instructions. Support, training and community are offered through Builder Methods Pro, and the license is MIT.
How to disable. Delete the cloned project folder as a whole: Design OS installs nothing outside it. If you carried the contents of `product-plan/` into your own project, delete those files separately. The local app stops when you close the `npm run dev` process.
FAQ
In what order do I run the commands?
First `/product-vision`, then `/design-tokens` and `/design-shell`. After that each section goes through `/shape-section` and `/design-screen`, with `/screenshot-design` if you like. `/export-product` runs last. The documentation advises against skipping steps: each builds on the previous result.
What exactly does /shape-section create?
A section spec with an overview, user flows and interface requirements, a sample data file where each entity is described in a `_meta` block, and a TypeScript types file. They live in `product/sections/<id>/`: spec.md, data.json and types.ts.
Why do screens take data through props?
The components that go into the export accept data and callbacks as parameters and import nothing themselves. That lets you carry them into a real project and connect real data. A separate preview wrapper sits beside them for viewing inside Design OS and does not go into the export.
What is inside the product-plan package?
A product overview, instructions as one combined file and as milestones (the shell, then one milestone per section), the one-shot-prompt.md and section-prompt.md prompts, tokens and font hints, data types, shell and screen components and test descriptions. The package is duplicated as the `product-plan.zip` archive.
Can I export before all sections are finished?
Yes. A product overview, a roadmap and one section with finished screens are enough. A missing design tokens file, data shape or shell is flagged with a warning, but the command carries on. The next export refreshes the package.
How do I reuse the template for several projects?
Push your copy to your own repository and mark it as a template in GitHub settings (Template repository). For a new project pick Use this template on GitHub.
Discussion
No questions or reviews yet.
Related
WorkflowsAn open-source Claude Design alternative that builds prototypes, decks, dashboards and video through your local agents
A kit of skills, tokens and rules that turns Claude into a design architect: DTCG tokens, components, accessibility and objective quality gates
designlang
designlang (design-extract)
A CLI and MCP server that reads a live website and pulls out its design system: DTCG tokens, a Tailwind config, Figma variables and a brand book
Awesome Claude Design
awesome-claude-design
A collection of ready DESIGN.md files that Claude Design expands into an interface scaffold: colors, type, components. Take as inspiration
A web-design skill for Claude Code: a DESIGN.md spec first, then code that follows it
DESIGN.md by Google Labs
DESIGN.md
The DESIGN.md format for agents and a CLI: lint contrast and references, diff versions, export tokens to Tailwind and DTCG
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Repository stars | Main difference |
|---|---|---|---|
| Design OS (this entry) | yes | 1,864 | |
| Designer Skills Collection | no | 3,024 | a set of design skills from research to prototypes, without a ready project template or a handoff package |
| Effective HTML | no | 3,717 | six skills that build standalone HTML artifacts: wireframes, prototypes, mockups and plans |
README in short
The English description explains the problem: agents build code fast, but the result misses your intent because product decisions are made on the fly. Next comes a four-stage process: product planning, a design system, section design and export. Installation and documentation live on the Builder Methods site, and docs/ holds pages on getting started, planning, section design, export, usage, requirements and implementing into a codebase. The changelog is kept in CHANGELOG.md. The creator is Brian Casel of Builder Methods.