plugins/powerups/skills/give-me-five/SKILL.md
Generate 5 meaningfully distinct UI/UX variants of the same screen in parallel (one subagent each), reachable via ?style=1...5, so the user can compare and pick. Calling again on a chosen style refines within that direction.
npx skillsauth add jackyliang/powerups give-me-fiveInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The user is not a designer but knows good design when they see it. Instead of generating one design and asking "what do you think?", produce five meaningfully distinct variants at once so they can compare and pick. Each variant lives at the same URL with a different ?style=N parameter (1–5).
This skill is an orchestration layer on top of frontend-design:frontend-design. The main agent brainstorms directions and dispatches; five parallel subagents each build one variant; the main agent assembles the result and hands off URLs.
Do NOT use when:
Defer to powerups:best-practices — branch before any work. Five experimental variants on main is risky; a branch lets you delete the four losers cleanly after the user picks, and reverts cleanly if you abandon the exploration.
git checkout -b feat/{description}-give-me-five
powerups:user-research BEFORE brainstorming directionsAll five variants must solve the SAME user problem — they vary on aesthetics and
layout, not on what job the screen does. Run powerups:user-research first to
produce the discovery brief: problem statement, jobs-to-be-done, core flow, and
the decision matrix. This research happens ONCE up front and anchors every
variant; without it, five pretty screens can each quietly answer a different
question. Get the requester's answers to the hand-off questions before dispatching.
Skip only when discovery is already done (e.g. give-me-five was called straight out of a PDD plan that already ran user-research) or the screen is a pure restyle of an existing, well-understood flow.
Generating 5 designs that are all the same vibe with different button colors is useless. Before launching any subagent, name the 5 directions on different axes. Good axes to vary on:
A strong set of 5 spans at least 3–4 of these axes — go wide on the first call. Name each direction in one phrase before dispatching:
Style 1: Editorial magazine — serif display, generous whitespace, narrative hierarchy Style 2: Dense ops console — monospace, tight grid, terminal aesthetic, data-rich Style 3: Soft glassmorphism — frosted panels, gradient backdrops, hover motion Style 4: Brutalist — heavy borders, raw monospace + display, black/white + one accent Style 5: Playful — rounded shapes, big illustrations, pastel palette, bouncy micro-interactions
Output this list to the user before dispatching. (No approval needed unless they redirect.)
Each variant is built by its own general-purpose subagent. All 5 launched in a single message with 5 Task tool calls in parallel — sequential dispatch is 5× slower for no gain. The main agent's job is brainstorming, dispatch, and assembly; the subagents do the design work.
The main agent does NOT design. It writes index.tsx (the router) and orchestrates. Letting a subagent own the router risks two agents editing the same file.
File layout:
components/MyPage/
├── index.tsx # router: reads ?style, dispatches to Style1..Style5 (main agent writes)
├── Style1.tsx # subagent 1
├── Style2.tsx # subagent 2
├── Style3.tsx # subagent 3
├── Style4.tsx # subagent 4
└── Style5.tsx # subagent 5
Each subagent prompt must be self-contained — subagents don't see the main conversation. Include:
components/MyPage/Style3.tsx)frontend-design:frontend-design before writing codeExample subagent prompt:
Build Style 3 of a 5-variant comparison set for the user dashboard page.
Direction: Soft glassmorphism — frosted panels with backdrop-blur, subtle
gradient backdrops, generous hover motion, rounded-2xl, pastel accent palette.
Write to: components/UserDashboard/Style3.tsx
Props (same across all 5 variants):
{ user: User, stats: Stats, recentActivity: Activity[] }
Content to render (same across all 5): [paste exact copy + data here]
Quality requirements:
- Invoke `frontend-design:frontend-design` before writing code
- Production-grade — distinctive, not generic AI aesthetic
- Full, polished design — no half-built stubs
- Self-contained in Style3.tsx — do NOT modify other Style*.tsx or index.tsx
Return: the file path and a 1-line summary of the key design choices.
Main agent's sequence:
index.tsx (router that reads ?style and dispatches to Style1..Style5, defaulting to 1)Present the URLs in a numbered list with the one-phrase name of each style:
Style 1 (Editorial magazine): http://localhost:3000/page?style=1
Style 2 (Dense ops console): http://localhost:3000/page?style=2
Style 3 (Soft glassmorphism): http://localhost:3000/page?style=3
Style 4 (Brutalist): http://localhost:3000/page?style=4
Style 5 (Playful): http://localhost:3000/page?style=5
The user clicks through, compares, picks.
When the user picks one and asks for more variants (e.g., "give me five in the style of #2"):
Style1.tsx..Style5.tsx with the new variants — don't accumulate. The URL pattern stays ?style=1..5. If the user wants to keep the previous winner around, save it as StyleN-vN.tsx or commit it on a git tag; otherwise let it go.Iteration is convergent — each cycle narrows the design space. The first call explores; subsequent calls refine.
frontend-design:frontend-design — variants need to be polished, not just varied.style=4 defeats the purpose. Verify each file exists after subagents return.| Mistake | Fix |
|---------|-----|
| Generating 5 variants that are basically the same design with different colors | Vary on 3–4 design axes, not 1. Name the directions before dispatching. |
| Dispatching subagents sequentially instead of in parallel | All 5 Task tool calls go in a single message. Sequential is 5× slower and there's no dependency between variants. |
| Subagent prompt that says "see above" or "same approach as before" | Each subagent is fresh — paste the direction, file path, props, content, quality bar, and constraints into every prompt. No references to context they can't see. |
| Letting a subagent write the router | The router (index.tsx) is the main agent's job. Subagents only produce their assigned variant file. Two agents editing the router = merge conflicts. |
| Main agent doing design work | Main agent brainstorms directions and orchestrates; subagents design. If the main agent is writing CSS, something is wrong. |
| Skipping frontend-design in subagent prompts | Every subagent invokes it — variants need to be polished, not just varied. |
| Half-implementing some variants (e.g., only the hero) | Every variant is a full, polished design. Otherwise the comparison is unfair. |
| Trusting subagent summaries without verifying files exist | After all 5 return, check each file on disk. Summaries describe intent, not reality. |
| Not telling the user how to switch between them | Always hand off the numbered URLs with the variant names, and make sure the dev server is running. |
| Iterating without anchoring to the chosen style | In iteration mode, the aesthetic/typography/palette are FIXED. Paste the anchor into every subagent prompt this round. |
| Keeping previous variants around after iteration | Replace 1–5 each cycle. Past variants are noise unless the user explicitly asks to keep one. |
| Skipping the feature branch | Defer to powerups:best-practices. Five experimental variants on main is asking for a mess. |
development
Run PM-grade discovery before building any user-facing feature — problem statement, jobs-to-be-done, core flow, decision matrix. Output is a short brief with open decisions surfaced as explicit questions. Invoked by plan-driven-development and give-me-five.
testing
Ultra-short replies — answer a quick question, draft a short text/social post, or draft a short email. No preamble, no offers to elaborate, drafts under 480 characters (280 for X), never em-dashes.
development
Reconcile shipped code with the plan in both directions — additive drift (unplanned work that landed) and subtractive drift (dead files, stale TODOs, completed deferred items). Run as part of PDD's post-completion audit, before /simplify.
development
Use when building any feature (small or large), fixing bugs, or refactoring — always write failing tests first against real infrastructure