Shape
Run a structured UX/UI discovery interview and produce a design brief before any implementation code for a new feature.
Overview
Shape is an agent skill most often used in Validate (also Build frontend, Validate prototype) that plans UX and UI through a discovery interview and writes a design brief before any code.
Install
npx skills add https://github.com/pbakaus/impeccable --skill shapeWhat is this skill?
- Mandatory /impeccable Context Gathering Protocol (and /impeccable teach when no design context exists)
- Phase 1 discovery interview with no code or premature design decisions
- Produces a structured design brief for implementation handoff
- Handoff targets /impeccable craft, /impeccable, or other implementation skills
- Philosophy-first: understand user goals before layout patterns like card grids
- Mandatory two-phase flow: discovery interview then design brief (no code in Phase 1)
Adoption & trust: 30.3k installs on skills.sh; 35.9k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to let an agent implement a feature UI without a shared understanding of user goals, constraints, or design strategy.
Who is it for?
Solo builders shaping a new screen, flow, or feature who already use or will adopt the Impeccable stack and want specs before agent implementation.
Skip if: Teams that need pixel-perfect mocks in Figma only, or situations where design is fully approved and you only need code generation with no discovery.
When should I use this skill?
Planning phase for a feature—establish design direction, constraints, and strategy before any code; argument-hint: feature to shape.
What do I get? / Deliverables
You get a structured design brief grounded in discovery that you can hand to /impeccable craft, /impeccable, or another implementation skill instead of coding from guesses.
- Structured design brief artifact
- Documented discovery answers and design constraints
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is validate/scope because the skill explicitly targets the planning phase to lock design direction, constraints, and strategy prior to build. Scope subphase fits feature-level design planning and handoff artifacts that bound what gets built, without writing code.
Where it fits
Interview stakeholders and users via the agent to bound a checkout redesign before estimating build work.
Replace a vague wireframe prompt with a brief that defines states, empty cases, and primary actions for a dashboard prototype.
Hand the brief to craft so component choices align with documented UX goals instead of generic layouts.
Attach the design brief to a feature ticket so scope and UI intent stay aligned for a one-person sprint.
How it compares
Use for interview-driven design briefs before coding, not as a component library or automatic UI code generator.
Common Questions / FAQ
Who is shape for?
Shape is for indie and solo builders using Claude Code, Cursor, or similar agents who want UX/UI direction captured in a brief before implementation, especially within the Impeccable workflow.
When should I use shape?
Use shape during Validate when scoping a feature, before Build frontend work, or when rewriting a prototype whose UX was never questioned. Run it whenever you would otherwise jump straight to “here’s a card grid” without a discovery interview.
Is shape safe to install?
Shape is planning-only and does not write product code by design, but it expects invoking other Impeccable skills. Review the Security Audits panel on this Prism page before installing any skill from the repo.
Workflow Chain
Then invoke: craft
SKILL.md
READMESKILL.md - Shape
## MANDATORY PREPARATION Invoke /impeccable, which contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding. If no design context exists yet, you MUST run /impeccable teach first. --- Shape the UX and UI for a feature before any code is written. This skill produces a **design brief**: a structured artifact that guides implementation through discovery, not guesswork. **Scope**: Design planning only. This skill does NOT write code. It produces the thinking that makes code good. **Output**: A design brief that can be handed off to /impeccable craft, /impeccable, or any other implementation skill. ## Philosophy Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply first, so implementation is precise. ## Phase 1: Discovery Interview **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Purpose & Context - What is this feature for? What problem does it solve? - Who specifically will use it? (Not "users"; be specific: role, context, frequency) - What does success look like? How will you know this feature is working? - What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?) ### Content & Data - What content or data does this feature display or collect? - What are the realistic ranges? (Minimum, typical, maximum, e.g., 0 items, 5 items, 500 items) - What are the edge cases? (Empty state, error state, first-time use, power user) - Is any content dynamic? What changes and how often? ### Design Goals - What's the single most important thing a user should do or understand here? - What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?) - Are there existing patterns in the product this should be consistent with? - Are there specific examples (inside or outside the product) that capture what you're going for? ### Constraints - Are there technical constraints? (Framework, performance budget, browser support) - Are there content constraints? (Localization, dynamic text length, user-generated content) - Mobile/responsive requirements? - Accessibility requirements beyond WCAG AA? ### Anti-Goals - What should this NOT be? What would be a wrong direction? - What's the biggest risk of getting this wrong? ## Phase 2: Design Brief After the interview, synthesize everything into a structured design brief. Present it to the user for confirmation before considering this skill complete. ### Brief Structure **1. Feature Summary** (2-3 sentences) What this is, who it's for, what it needs to accomplish. **2. Primary User Action** The single most important thing a user should do or understand here. **3. Design Direction** How this should feel. What aesthetic approach fits. Reference the project's design context from `.impeccable.md` and explain how this feature should express it. **4. Layout Strategy** High-level spatial approach: what gets emphasis, what's secondary, how information flows. Describe the visual hierarchy and rhythm, not specific CSS. **5. Key States** List every state the feature needs: default, empty, loading, error, success, edge cases. For each, note what th