
Wireframe Spec
Produce annotated low-to-mid fidelity wireframe specs so you and your agent agree on hierarchy, blocks, and behavior before pixels or code.
Overview
Wireframe Spec is an agent skill most often used in Validate (also Build) that specifies gray-scale wireframes with content priority, placement, and behavior annotations before visual design.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill wireframe-specWhat is this skill?
- Defines content blocks: headers, hero, sections, forms, footers
- Annotations for priority order, click/hover behavior, dynamic and responsive notes
- Four fidelity levels: Sketch, Low-fi, Mid-fi, and Annotated mid-fi
- Gray-scale conventions: X-box images, wavy text, real nav/button labels
- Content specs: heading hierarchy, text length, image aspect ratios, CMS vs API sources
- 4 fidelity levels: Sketch, Low-fi, Mid-fi, Annotated
Adoption & trust: 598 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what the page should do but lack a shared, implementation-ready map of blocks, order, and interactions.
Who is it for?
Solo builders scoping landing pages, dashboards, or flows who want structure and copy placement agreed before Figma or code.
Skip if: Teams that already have approved high-fidelity mocks or only need pixel-perfect visual design tokens.
When should I use this skill?
You need wireframe layouts with content priority, component placement, behavior annotations, and responsive considerations before visual design.
What do I get? / Deliverables
You get an annotated wireframe spec with fidelity level and content rules ready for UI design or frontend breakdown.
- Annotated wireframe specification
- Content block and annotation list
- Fidelity level and convention notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Wireframe specs belong on the validate shelf because they lock layout and content priority before visual design or implementation commits. Prototype is where solo builders sketch structure, interaction notes, and fidelity level without color or final UI polish.
Where it fits
Sketch hero, feature grid, and signup form with priority numbers before building a waitlist page.
Document required vs optional blocks and CMS-sourced regions so scope matches what marketing promised.
Hand the agent section order and interaction notes so React components mirror the agreed wireframe.
Attach annotated mid-fi specs to internal docs so future you knows why the footer nav was deprioritized.
How it compares
Use for hierarchy and behavior specs, not as a replacement for visual design or a component library.
Common Questions / FAQ
Who is wireframe-spec for?
Indie and solo builders—plus small product/design pairs—who need fast, agent-generated wireframe documentation before committing to UI or frontend work.
When should I use wireframe-spec?
During validate when prototyping page structure; during build when breaking a screen into sections for frontend implementation; anytime you need priority numbers and interaction notes without color decisions.
Is wireframe-spec safe to install?
It is documentation-oriented layout guidance; review the Security Audits panel on this Prism page before installing from any third-party skills repo.
SKILL.md
READMESKILL.md - Wireframe Spec
# 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