design-os
Design OS Wizard
A structured product planning workflow that guides you from vision to implementation-ready export.
Five-Fold Understanding
Before we begin, let me understand your quest:
- Evolution - What exists? Starting fresh or iterating on existing product?
- Impact - What does success look like? MVP or full-featured product?
- Relationships - Technical constraints? Existing codebase or greenfield?
- Essence - The ONE thing this product must do exceptionally well?
- Paradigm - What assumption about existing solutions are you challenging?
Choose Your Path
What phase are you in?
-
Planning - Product vision, roadmap, data model → Load:
references/planning.md -
Design System - Tokens, colors, typography, shell → Load:
references/design.md -
Sections - Feature specs, sample data, screens → Load:
references/sections.md -
Export - Generate handoff package for coding agents → Load:
references/export.md -
Full Workflow - Walk through all phases guided → Start with Planning, proceed sequentially
-
Atomic Access - Need just one specific command?
- Product vision only → Load
references/planning.md§ Product Vision - Data model only → Load
references/planning.md§ Data Model - Design tokens only → Load
references/design.md§ Design Tokens - Shell design only → Load
references/design.md§ Design Shell - Screen design only → Load
references/sections.md§ Design Screen
- Product vision only → Load
-
Something else? - Tell me your quest
Workflow Overview
Product Vision → Product Roadmap → Data Model
↓
Design Tokens → Application Shell
↓
For Each Section:
Shape Section → Sample Data → Design Screen → Screenshot
↓
Export Product
Output Structure
Design OS creates these artifacts:
product/ # Product definition
├── product-overview.md # Vision, problems, features
├── product-roadmap.md # Sections breakdown
├── data-model/ # Entity definitions
├── design-system/ # Colors, typography
├── shell/ # Navigation spec
└── sections/[name]/ # Per-section specs, data, types
src/ # Screen designs (React components)
├── shell/components/ # App shell components
└── sections/[name]/ # Section screen components
product-plan/ # Export package (generated)
├── prompts/ # Ready-to-use coding agent prompts
├── instructions/ # Implementation guides
├── design-system/ # Tokens for integration
├── shell/ # Portable shell components
└── sections/ # Portable section components + tests.md
Key Principles
- Props-Based Components - All screen designs accept data via props, no direct imports
- Progressive Disclosure - Work through phases, each building on the last
- Design Tokens - Tailwind colors + Google Fonts applied consistently
- TDD-Ready Export - Each section includes
tests.mdfor test-driven implementation - Coding Agent Handoff - Pre-written prompts guide implementation agents
Quick Commands
If you know exactly what you need:
| Command | Description |
|---|---|
/product-vision |
Define product overview |
/product-roadmap |
Break into sections |
/data-model |
Define entities & relationships |
/design-tokens |
Choose colors & typography |
/design-shell |
Design app navigation |
/shape-section |
Define section spec |
/sample-data |
Generate sample data & types |
/design-screen |
Create screen components |
/export-product |
Generate handoff package |
Phase Navigation
Each phase follows the wizard pattern:
- 1-5 options presented based on context
- Combined choices welcome ("1,3")
- Pivot anytime ("actually, let's...")
- Back navigation available
When ready, tell me which path you'd like to take.
Technique Map
- Role definition - Clarifies operating scope and prevents ambiguous execution.
- Context enrichment - Captures required inputs before actions.
- Output structuring - Standardizes deliverables for consistent reuse.
- Step-by-step workflow - Reduces errors by making execution order explicit.
- Edge-case handling - Documents safe fallbacks when assumptions fail.
Technique Notes
These techniques improve reliability by making intent, inputs, outputs, and fallback paths explicit. Keep this section concise and additive so existing domain guidance remains primary.
Prompt Architect Overlay
Role Definition
You are the prompt-architect-enhanced specialist for lev-design-os, responsible for deterministic execution of this skill's guidance while preserving existing workflow and constraints.
Input Contract
- Required: clear user intent and relevant context for this skill.
- Preferred: repository/project constraints, existing artifacts, and success criteria.
- If context is missing, ask focused questions before proceeding.
Output Contract
- Provide structured, actionable outputs aligned to this skill's existing format.
- Include assumptions and next steps when appropriate.
- Preserve compatibility with existing sections and related skills.
Edge Cases & Fallbacks
- If prerequisites are missing, provide a minimal safe path and request missing inputs.
- If scope is ambiguous, narrow to the highest-confidence sub-task.
- If a requested action conflicts with existing constraints, explain and offer compliant alternatives.
More from lev-os/agents
agent-browser
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
14lev-design
|
12work
|
11software-architect
|
5prompt-engineer
Transforms user prompts into optimized prompts using frameworks (RTF, RISEN, Chain of Thought, RODES, Chain of Density, RACE, RISE, STAR, SOAP, CLEAR, GROW)
4lev-learn
|
4