// Generate multiple design explorations for a UI feature, each inspired by a different company's design language. Spawns parallel agents that research a company's style, then implement a standalone HTML prototype. Use when asked to "explore designs", "design options", "compare UI approaches", or "design sprint".
Audit and improve marketing copy aimed at engineers — READMEs, landing pages, feature pages, tweets, launch posts. Based on Michael Seibel's YC pitch framework adapted for developer tools. Use when asked to "review copy", "audit the homepage", "improve the README", "check the marketing", or when writing new marketing content for a dev tool.
Review code changes, a plan, a live page (running dev server), or a local HTML file with crit inline comments. Use when asked to review code, a plan, a diff, or a running web app, when you want structured human feedback on your work, or when authoring crit comments programmatically. Covers the interactive review loop plus crit comment, crit share, and GitHub PR sync.
Write or rewrite transactional and growth emails (invitations, onboarding, referrals, re-engagement) using startup email copy principles from YC/Airbnb. Use when asked to "write an email", "rewrite this email", "invitation email", "onboarding email", or when reviewing email copy for conversion.
Use when validating a feature request, user feedback, or product idea. Generates Mom Test-style questions that ask about past behavior instead of hypothetical futures. Use when asked to "validate this idea", "mom test questions", "interview questions for this feature", or given a feature request to evaluate.
| name | design-explore |
| description | Generate multiple design explorations for a UI feature, each inspired by a different company's design language. Spawns parallel agents that research a company's style, then implement a standalone HTML prototype. Use when asked to "explore designs", "design options", "compare UI approaches", or "design sprint". |
Generate multiple competing design prototypes for a UI feature, each inspired by a different company's design language. Each prototype is an independent standalone HTML file, created by a separate agent with no knowledge of the others.
The user picks a winner; you adapt it to the actual codebase.
When invoked, parse the user's request for:
Examples of how this skill is invoked:
explore designs for the comment thread component in src/Comments.jsx
design options for the file tree, companies: Stripe, Figma, Notion, Arc
design sprint on the theme picker, companies: GitHub, Raycast
If the feature isn't clear from the request, ask:
Read the current implementation. Identify:
Build a standalone HTML file that reproduces the current component in isolation:
/* THIS IS THE PART TO REDESIGN */ and /* END REDESIGN ZONE */Save to: .design-exploration/{feature-slug}/base.html
Show the user the base HTML path and ask them to open it in a browser to verify it matches the current implementation before proceeding.
Before dispatching agents, present:
The briefs should be open-ended — describe the company's design philosophy and ask the agent to research and apply it. Do NOT prescribe specific UI patterns (no "add an icon", "use a left border", etc.). Let each agent discover the right UX through research.
Spawn one agent per company, all in parallel, each with run_in_background: true if the harness supports it.
Each agent gets the same prompt structure:
You are a world-class designer. Your task is to redesign [FEATURE DESCRIPTION] in [PRODUCT CONTEXT].
**Context**: [2-3 sentences explaining what the feature does, what problem it solves, who uses it]
**Starting point**: Copy the file at [BASE HTML PATH] to a new file at [OUTPUT PATH]. The base file contains the current implementation with theme toggle (dark/light). The section between `/* THIS IS THE PART TO REDESIGN */` and `/* END REDESIGN ZONE */` is what you're reimagining — but you're free to change any part of the component if the UX calls for it.
**The current theme palette**: [LIST KEY COLORS FROM BOTH DARK AND LIGHT THEMES — backgrounds, text, accents, borders, warnings]. You can extend the palette with new CSS variables if your design calls for it — define them for both dark and light themes.
**Constraints**: Single HTML file, vanilla CSS/JS only, must work in both themes. [ANY ADDITIONAL CONSTRAINTS — e.g., XSS safety, accessibility requirements]. Beyond that, be creative with both the visual design AND the interaction design.
You are a world-class designer at **[COMPANY]**. Research [COMPANY]'s design philosophy — [OPEN-ENDED BRIEF ABOUT THE COMPANY'S AESTHETIC AND APPROACH]. Study how [COMPANY] handles [RELEVANT PATTERN]. Then apply that thinking to this feature. [OPEN-ENDED QUESTION ABOUT THE KEY DESIGN TENSION].
Output paths: .design-exploration/{feature-slug}/{company-slug}.html
The company-specific brief must:
As each agent completes, briefly report:
When all agents are done, present a comparison table:
| File | Key UX idea |
|-------------------|------------------------------------------------|
| github.html | [one-line summary] |
| linear.html | [one-line summary] |
| ... | ... |
Tell the user: "Open these from .design-exploration/{feature-slug}/ — each has a dark/light toggle. Pick the one you like and I'll adapt it to the actual codebase."
When the user picks a design:
Do NOT blindly copy the standalone HTML into the codebase. The standalone file may have simplified the theme, used different variable names, or changed non-redesign-zone code. Adapt intelligently.
The .design-exploration/ directory and its files are ephemeral — they exist for comparison only. The dot-prefix signals "local working files, don't commit." If the project doesn't already ignore it, add .design-exploration/ to .gitignore. Don't clean them up automatically (the user may want to reference past explorations later).