| name | rapid-prototyping |
| description | Build rough but working UI/app prototypes by proposing a few concrete options, implementing selected options in separate `.worktrees` git worktrees, and landing the chosen direction back in the current worktree. Use proactively for prototypes, proofs of concept, quick demos, clickable mocks, MVP slices, or design direction comparisons.
Examples:
- user: "Build a quick demo of a dashboard for tracking shipments" → propose options, create worktrees for the selected ones, and implement each prototype separately
- user: "I need a clickable onboarding flow today" → offer flow options, ask whether to use subagents, then build each chosen option in its own worktree
- user: "Scaffold an MVP slice for booking appointments" → write short option specs, hand them to subagents or implement directly, then land the selected slice in the main worktree
- user: "Turn this rough feature idea into something I can show" → convert vague requirements into competing prototype options and help the user choose one to land |
Rapid Prototyping
Use this skill when speed of learning matters more than production polish and comparing a few concrete directions is more useful than debating abstractly.
Workflow
- Present 2-4 options
- Translate the request into a small set of distinct prototype directions.
- Keep options concrete and implementation-shaped, not abstract design language.
- Describe each option briefly so the user can choose what to prototype.
- Let the user choose options to prototype
- Ask the user which option numbers or names to build.
- Ask whether to implement all selected options simultaneously with subagents or with the current agent.
- If a missing product decision blocks useful options, ask one short clarifying question.
- Create one worktree per selected option
- Create a separate git worktree for each selected option under
.worktrees/.
- Use descriptive names that map cleanly to the option labels.
- Use the directory pattern
.worktrees/prototype-<slug> where <slug> is a short lowercase hyphen-case version of the option name.
- Create each worktree from the current branch with
git worktree add .worktrees/prototype-<slug> -b prototype-<slug>.
- Keep the current worktree clean; prototype exploration happens in the option worktrees.
- Run
npm install in each worktree
- Write a quick spec per option
- In each selected option worktree, add
prototype-spec.md describing the goal, happy path, assumptions, mocked data, and explicit shortcuts.
- Keep the spec short and implementation-ready.
- If subagents are used, hand the spec and worktree path to the subagent.
Use this spec template:
# <Option Name>
## Goal
## Happy Path
## Assumptions
## Mocked Data / Integrations
## Explicit Shortcuts
## Deliverable
- Implement prototypes
- If the user chose subagents, launch one subagent per selected option so implementation can happen in parallel.
- If the user chose the current agent, implement the selected option worktrees one at a time.
- Stay inside the repo's existing stack, file structure, components, and styling patterns.
- Prefer local state, hard-coded fixtures, placeholder copy, and mocked data unless real integration is the point of the prototype.
- Implement one happy path first and skip edge cases unless requested.
- Report completion and wait for selection
- Once all option implementations finish, inform the user that the prototypes are ready.
- Do not merge anything yet.
- Ask the user if you should launch the dev servers of the prototypes. If yes, run the
pnpm dev command an report back the URL where the prototype is available
- Wait for the user to manually inspect the worktrees and choose one option.
- Land the chosen option in the current worktree
- Implement the selected option in the current worktree at the repo root (
dle.dev).
- Rebuild the chosen direction cleanly rather than trying to preserve every prototype shortcut.
- Run the smallest relevant verification for the landed change.
- Clean up exploration state
- Delete all temporary option worktrees under
.worktrees after the chosen option is landed.
- Remove each worktree with
git worktree remove .worktrees/prototype-<slug>.
- If the temporary branch is no longer needed, delete it with
git branch -D prototype-<slug> only after the worktree has been removed.
- Inform the user that the selected option is now implemented in the main worktree.
- Ask whether they want any further changes.
Default Choices
- Options: 2-4 distinct directions unless the user asks for more or fewer.
- Scope: one screen or one end-to-end happy path before anything broader.
- Data: static fixtures or in-memory state before real APIs or persistence.
- Components: existing primitives before new component systems.
- Architecture: inline or local code before reusable layers.
- Styling: minimal changes that support the concept, not a full design pass.
- Verification: favor quick functional verification before authoring new tests.
- Specs: one
prototype-spec.md per selected option worktree.
- Execution: subagents for parallel option builds, current agent for sequential builds.
When Not To Use This Skill
- The user explicitly wants production-ready architecture, migrations, or long-term maintainability.
- The core value depends on real integrations, exact performance, or exhaustive edge-case handling.
- The task is mostly cleanup, refactoring, or documentation rather than building a demonstrable slice.
- The user wants only one direct implementation with no option exploration.
Finish Pattern
Use this structure when reporting completed prototype work:
- Options built: the completed prototype worktrees that are ready for review
- Selected option: the direction the user chose after reviewing
- Landed in main worktree: the implementation now present in
dle.dev
- Mocked: data, services, or states that are intentionally fake or incomplete
- Assumptions: defaults chosen to keep momentum
- Next hardening steps: the smallest steps to productionize the prototype
- Once everything is complete, kill all subagents relating to the prototypes
