builder-os

Use when the user is building or refactoring UI in their product codebase and wants designer-quality frontend code — not just functional code. Triggers on phrases like "design better", "make this UI feel more designed", "elevate the design quality", "build this with design best practices", "follow UX heuristics", "make this feel professional", "apply design polish", "review this for craft", or any request to apply UX/UI craft heuristics to code generation or review. Pairs with `docs/design.md` when it exists — the design system file owns **style** (colors, typography, spacing tokens, components), this skill owns **craft** (hierarchy, interaction, accessibility, motion, polish). Reference `docs/design.md` tokens by name for every visual decision; apply the 50-item heuristics catalogue and the Laws of UX catalogue below for every craft decision. When `docs/design.md` is absent, fall back to the codebase's existing design conventions and recommend the **Design System** skill. When a heuristic implies a token the

Translates an image (or a set of image references — screenshots, mockups, Figma URLs, live websites) into two mirrored design-system artifacts: `docs/design.md` (YAML tokens + prose, following Google's open [design.md](https://github.com/google-labs-code/design.md) format, for the coding agent) and `docs/design.html` (a self-contained, token-driven style guide rendering every token and component live, for the human to read). Reads the imagery, asks targeted clarifying questions, derives the design tokens (colors, typography, spacing, rounded, components), and writes both files. Fully standalone — requires no other document or skill. Use when the founder says "create a design system", "design from image", "translate image to design", "create design.md", "image to design system", "extract design tokens", or shares an image with no other clear intent.

Vision intake conversation followed by generation of three product documents — `docs/product-vision.md` (strategy and brand), `docs/prd.md` (technical spec for coding agents), and `docs/product-roadmap.md` (phased build plan with task checkboxes). Also captures the founder's answers as `docs/VISION.md`. Use when the founder says "plan my product", "plan a product", "define my vision", "generate a PRD", "create a roadmap", "spec out my idea", "help me build something", or wants to convert an idea into shippable spec documents.

Use inside a product repository when the user wants the full MVP built from their BuilderOS spec documents. Triggers on phrases like "build my MVP", "build the app", "execute the roadmap", "start the build", "work through the whole roadmap", "build everything", or any request to implement the entire plan rather than a single task or phase. Requires `docs/prd.md` and `docs/product-roadmap.md` (plus `docs/product-vision.md` and `docs/design.md` for context). Works through every roadmap task in order — implementing, testing, and verifying each before moving on, marking checkboxes and updating the status line — and runs until all tasks are complete and the magic moment works end to end, then initializes git with an initial commit and offers to connect a remote repo.

Guided discovery of a product idea by mining what the founder already knows or already does — covers source selection (business vs. expertise), context capture, pattern synthesis, candidate scorecard, and writes `docs/product-idea.md`. Use when the founder says "generate an idea", "help me find an idea", "what should I build", "product idea from my business", "product idea from my expertise", or otherwise needs to discover a product concept worth building.

Pressure-tests a product idea before the founder invests in planning, building, or launching. Surfaces fatal flaws, tests whether the problem is real, maps real competition (including current behavior), plans first 10 customers, defines a 2-week MVP test, returns a strong/weak/pivot verdict, then sharpens `docs/product-idea.md` based on the founder's direction calls. Use when the founder says "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "stress test my idea", or otherwise wants to evaluate an idea before committing.

Use when building features with **Claude Code** in any codebase and the work should go through a disciplined build → review → test → fix loop. Triggers on "run the build loop", "build the next task", "continue the plan", "build this feature properly", or any request to implement work from a plan file or a direct feature prompt. Builds from the plan (or the prompt if no plan exists), runs Claude Code's `/review` (plus `/security-review` for sensitive surfaces) and fixes every issue found, tests and verifies the feature end to end, fixes anything testing surfaces, and reports back once complete. Repeats until all plan tasks are checked off.

Use when building features with **Codex** (OpenAI Codex CLI) in any codebase and the work should go through a disciplined build → review → test → fix loop. Triggers on "run the build loop", "build the next task", "continue the plan", "build this feature properly", or any request to implement work from a plan file or a direct feature prompt. Builds from the plan (or the prompt if no plan exists), runs Codex's `/review` on uncommitted changes and fixes every issue found, tests and verifies the feature end to end, fixes anything testing surfaces, and reports back once complete. Repeats until all plan tasks are checked off.

Use when building features with **Cursor** in any codebase and the work should go through a disciplined build → review → test → fix loop. Triggers on "run the build loop", "build the next task", "continue the plan", "build this feature properly", or any request to implement work from a plan file or a direct feature prompt. Builds from the plan (or the prompt if no plan exists), runs Cursor's `/review` and fixes every issue found, tests and verifies the feature end to end, fixes anything testing surfaces, and reports back once complete. Repeats until all plan tasks are checked off.

Use when the user's product is built (or nearly built) and they want to get it live and accessible to customers. Triggers on phrases like "create my launch checklist", "how do I deploy this", "help me launch", "get this live", "put this in production", "ship it to customers", "what do I need to do to go live", or any request for a step-by-step path from working code to a product customers can use. Audits the current codebase — stack, services, environment variables, payments, deploy config — then writes a plain-English, step-by-step launch guide to `docs/launch-checklist.md`. Every step is marked as something the user must do themselves, something their coding agent can do, or both together, and all technical terms are explained for non-technical founders.