// Define the structural layer of a product or site before visual design begins. Covers navigation, content hierarchy, page structure, URL patterns, and user flows. Use when user wants to plan site structure, define navigation, map user flows, organize content, or mentions "IA" or "information architecture".
| name | information-architecture |
| description | Define the structural layer of a product or site before visual design begins. Covers navigation, content hierarchy, page structure, URL patterns, and user flows. Use when user wants to plan site structure, define navigation, map user flows, organize content, or mentions "IA" or "information architecture". |
This skill defines the structural skeleton of a product or site. It sits between the design brief and the build. Run this after the brief is written and before tasks are created.
Look for an existing design brief at .design/*/DESIGN_BRIEF.md. If multiple subfolders exist, use the most recently modified one, or ask the user which feature they are working on. If no brief exists, ask the user what they are building and for whom.
Explore the existing codebase to understand what structure already exists:
app/ or pages/ directory, React Router config, Vue Router, SvelteKit routes, or static HTML page filesInterview the user about structural decisions. For each question, provide your recommended answer.
Cover at minimum:
Once you have a shared understanding, produce the IA document using the template below and save it as INFORMATION_ARCHITECTURE.md in the same .design/<feature-slug>/ subfolder as the design brief.
# Information Architecture: [Product/Site Name]
## Site Map
A hierarchical map of every page or view. Use indentation to show nesting. Include the URL pattern for each.
- Home `/`
- Feature A `/feature-a`
- Sub-page `/feature-a/detail`
- Feature B `/feature-b`
- Settings `/settings`
- Profile `/settings/profile`
## Navigation Model
Describe the navigation system:
- **Primary navigation**: What appears in the main nav? Maximum items.
- **Secondary navigation**: Sidebar, tabs, or contextual links within sections.
- **Utility navigation**: Account, settings, help, and anything outside the main content hierarchy.
- **Mobile navigation**: How navigation adapts. Hamburger, bottom tabs, or something else.
## Content Hierarchy
For each major page or view, define the content priority:
### [Page Name]
1. [Highest priority content] -- Why this comes first
2. [Second priority] -- Why this comes second
3. [Third priority] -- Rationale
4. [Below the fold / secondary]
## User Flows
The critical paths through the product. Each flow is a sequence of steps with decision points noted.
### [Flow Name] (e.g., "New user onboarding" or "Create a project")
1. User lands on [page]
2. User sees [content/prompt]
3. User takes action: [action]
- If [condition A] -> [outcome]
- If [condition B] -> [outcome]
4. User arrives at [destination]
## Naming Conventions
A glossary of terms used in the interface. Consistency matters. Pick one word and use it everywhere.
| Concept | Label in UI | Notes |
|---------|-------------|-------|
| [thing] | [what we call it] | [why this word] |
## Component Reuse Map
Which structural components (layouts, containers, navigation elements) are shared across pages.
| Component | Used on | Behavior differences |
|-----------|---------|---------------------|
| [layout/component] | [pages] | [any variations] |
## Content Growth Plan
Which sections of the site will accumulate content over time and how the IA accommodates that growth (pagination, filtering, search, archive patterns).
## URL Strategy
Rules for URL construction:
- Pattern: [e.g., `/section/subsection/item-slug`]
- Dynamic segments: [what is parameterized]
- Query parameters: [filtering, sorting, pagination]
Run the full design-to-build workflow as a guided sequence. Orchestrates all designer skills in order, from grilling through review. Use when user wants to go through the complete design process, start a project from scratch, run the full flow, or mentions "design flow" or "full workflow".
Run a structured design critique against the brief and codebase. Checks visual hierarchy, consistency, responsiveness, accessibility, and aesthetic fidelity. Use when user wants a design review, critique, QA pass, polish pass, or mentions "review" after building.
Create a design brief through an interactive interview, codebase exploration, and experience design decisions. Saved as a markdown file in the project. Use when user wants to write a design brief, plan a new feature or page, define a UI direction, or mentions "brief".
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, challenge an approach, or mentions "grill me".
Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".
Generate a design tokens file (CSS variables or Tailwind config) based on a chosen aesthetic philosophy, with light and dark mode palettes, spacing scale, type ramp, and component-level tokens. Use when starting a new project, establishing a visual system, setting up tokens, or mentions "tokens" or "design system".