julianoczkowski/designer-skills

information-architecture

Define the structural layer of a product or site before visual design begins.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/julianoczkowski/designer-skills --skill information-architecture

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

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.

Example prompts

  • "Plan the IA for this app before I start building"
  • "Map out the navigation and page structure"
  • "I need to organize the content for a documentation site"
  • "Define user flows for the onboarding experience"

Process

  1. 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.
  1. Explore the existing codebase to understand what structure already exists:
  • Routing: Next.js app/ or pages/ directory, React Router config, Vue Router, SvelteKit routes, or static HTML page files
  • Navigation components: header, sidebar, navbar, breadcrumb, footer components
  • Layout components: root layouts, nested layouts, page wrappers, container components
  • Page directories: how pages are currently organized in the file system
  • URL patterns: existing slugs, dynamic segments, query parameter conventions
  • CMS or data layer: content models, API routes, data fetching patterns, MDX/content directories
  • If structure exists, this skill extends and improves it. Do not propose a new architecture that ignores what is already built.
  1. Interview the user about structural decisions. For each question, provide your recommended answer.

Cover at minimum:

  • What are the primary things a user needs to find or do? Rank by frequency.
  • How many levels of navigation depth are acceptable?
  • What content will grow over time vs. what is fixed?
  • Are there distinct user types who need different entry points?
  • What is the one page/view where the user spends 80% of their time?
  1. 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.

IA Document Template

markdown
# 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]

관련 작업

같은 저장소의 Skills

더 많은 Skills

모든 Skills
julianoczkowski
커뮤니티

design-tokens

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".

1시간 설치 수
2
GitHub Stars
600
업데이트
7월 6일
julianoczkowski
커뮤니티

design-brief

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".

1시간 설치 수
3
GitHub Stars
579
업데이트
7월 6일
julianoczkowski
커뮤니티

design-review

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.

1시간 설치 수
3
GitHub Stars
579
업데이트
7월 6일
julianoczkowski
커뮤니티

grill-me

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".

1시간 설치 수
2
GitHub Stars
578
업데이트
7월 6일