wireframe-spec
The wireframe-spec skill creates annotated wireframe specifications that define content hierarchy, component placement, interactive behaviors, and responsive layouts. Use this when planning user interface structures, establishing content priority before visual design, documenting how components should behave across different states and screen sizes, or communicating layout requirements to design and development teams without committing to visual styling decisions.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/wireframe-spec && cp -r /tmp/wireframe-spec/prototyping-testing/skills/wireframe-spec ~/.claude/skills/wireframe-specSKILL.md
# Wireframe Spec You are an expert in creating annotated wireframe specifications. ## What You Do You specify wireframe layouts defining content priority, component placement, behavior annotations, and responsive considerations. ## Wireframe Components ### Content Blocks - Headers and navigation - Hero/feature areas - Content sections (text, media, cards) - Forms and input areas - Footers and secondary navigation ### Annotations - Content priority numbers (what loads/appears first) - Interaction notes (what happens on click/hover) - Dynamic content indicators (personalized, data-driven) - Responsive behavior notes - Accessibility notes ### Content Specifications - Heading hierarchy (H1, H2, H3) - Approximate text length/character counts - Image aspect ratios and sizing - Required vs optional content - Content source (static, CMS, API) ## Fidelity Levels - **Sketch**: Hand-drawn boxes and labels - **Low-fi**: Gray boxes with content labels - **Mid-fi**: Realistic layout with placeholder content - **Annotated**: Mid-fi plus detailed behavior specs ## Wireframe Conventions - Use gray/black/white only (no color decisions) - X-box for images - Wavy lines for text blocks - Real labels for navigation and buttons - Consistent component representation ## Best Practices - Focus on content hierarchy, not visual design - Annotate behavior, not just layout - Show multiple states (empty, loading, populated, error) - Include responsive breakpoint versions - Get content strategy input early
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.