From designpowers
Interrupts UI builds at visual checkpoints to show intermediate output and solicit user taste feedback on color, typography, layout, and spacing for early corrections.
npx claudepluginhub owl-listener/designpowers --plugin designpowersThis skill uses the workspace's default tool permissions.
The standard Designpowers pipeline catches taste mismatches at critique — after the full build is done. That's expensive. A wrong colour palette discovered after 8 components are built means rebuilding all 8. This skill interrupts the build at strategic moments to show intermediate output and ask: "Is this heading in the right direction?"
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
The standard Designpowers pipeline catches taste mismatches at critique — after the full build is done. That's expensive. A wrong colour palette discovered after 8 components are built means rebuilding all 8. This skill interrupts the build at strategic moments to show intermediate output and ask: "Is this heading in the right direction?"
design-builder execution, at natural visual checkpointsBefore the build begins, identify 2-4 moments where taste feedback is most valuable. More than 4 interruptions becomes annoying. Choose wisely.
High-value checkpoints:
| Checkpoint | Why It Matters | When to Show |
|---|---|---|
| Colour and typography applied | The foundational visual layer — everything else builds on this | After the first component is styled |
| Layout structure visible | Spatial relationships, density, whitespace | After the primary screen scaffold is built |
| First interaction implemented | How the interface moves and responds | After the first stateful component works |
| Content integrated | How real words look in the design | After content-writer's copy is in place |
Low-value checkpoints (avoid):
| Checkpoint | Why It's Low Value |
|---|---|
| Unstyled HTML structure | Nothing to react to aesthetically |
| Individual component in isolation | Context-free judgement is unreliable |
| After every small change | Interruption fatigue kills the creative flow |
At each checkpoint, capture the current state:
Good taste questions are specific and answerable:
| Bad Question | Good Question |
|---|---|
| "Does this look good?" | "The heading is set in 32px Inter Medium — is that weight right, or do you want bolder/lighter?" |
| "Any feedback?" | "The cards have 16px padding and 8px radius. Does this density feel right, or do you want more breathing room?" |
| "Is this the right direction?" | "I went warm grey (#F5F3F0) for the background instead of pure white. Does this warmth match what you had in mind?" |
Show the user the intermediate state with targeted questions:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TASTE CHECK [1 of 3]
Phase: [e.g., "Colour & Typography"]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Screenshot or detailed visual description]
DECISIONS VISIBLE:
• [Decision 1 — e.g., "Sage green (#8FAE8B) as primary"]
• [Decision 2 — e.g., "Space Grotesk for headings, Inter for body"]
• [Decision 3 — e.g., "Generous padding, low density"]
TASTE QUESTIONS:
1. [Specific question about a visible decision]
2. [Specific question about a visible decision]
Quick responses welcome:
• "Looks right" → continue building
• "Warmer/cooler/bolder/quieter" → adjust and continue
• "Stop — wrong direction" → pause build, discuss
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The user's response determines what happens next:
| Response | Action | Taste Signal |
|---|---|---|
| "Looks right" / "Yes" / "Continue" | Resume building. No changes needed | Moderate positive — note in design-memory as confirmed direction |
| Specific adjustment ("make it warmer") | Apply the adjustment, show confirmation, then continue | Strong — record the adjustment and the direction they moved from/to |
| "Wrong direction" / "Stop" | Pause the build. Ask what feels off. This is the most valuable taste data | Very strong negative — record what was rejected and why |
| Detailed feedback ("I like the type but the colour feels too muted") | Apply partial changes. Acknowledge what works, adjust what doesn't | Mixed signal — record both the positive and negative separately |
| "Skip these checks" | Disable further taste checks for this build. Respect the preference | Meta-preference — they want to review at the end instead |
When the user requests a change:
If the change cascades (e.g., new colour palette affects multiple components already built):
After each checkpoint interaction, update taste signals:
design-memoryAdapt based on user behaviour:
| User Behaviour | Adjust To |
|---|---|
| Approves every checkpoint quickly | Reduce to 1-2 checkpoints — they trust the direction |
| Gives detailed feedback at every checkpoint | Maintain 3-4 — they want to shape the output |
| Says "skip" or seems impatient | Drop to 1 checkpoint or none — ask at the end |
| Requests more checkpoints | Add checkpoints — they want more control |
The system should learn this preference over time via design-memory.
| Mode | Behaviour |
|---|---|
| Direct | Taste checkpoints are shown naturally — they fit the approval flow |
| Auto | Taste checkpoints are disabled by default in auto mode. The user chose speed. If the user opts in ("auto but check my taste"), enable minimal checkpoints (1-2 max) |
design-builder (at visual checkpoints during build), using-designpowers (can be enabled/disabled)design-memory (to record taste signals from feedback)design-state.md (for current decisions)design-memory, ui-composition, designpowers-critique| Pattern | Why It Fails |
|---|---|
| Asking "does this look good?" | Too vague. The user can't give actionable feedback without specific questions |
| Checking after every change | Interruption fatigue. 2-4 checkpoints per build, maximum |
| Showing unstyled output | There's nothing to react to. Wait until visual decisions are visible |
| Ignoring "skip" signals | If the user wants to review at the end, respect that. Don't force mid-flight checks |
| Not recording feedback | Every checkpoint interaction is taste data. If you don't record it, you'll ask the same questions next project |
| Presenting in auto mode without consent | Auto mode means "don't interrupt me." Only show taste checks if the user explicitly opted in |
| Asking about non-visual decisions | "Is this the right React component pattern?" is not a taste question. Keep checks visual and aesthetic |