| name | information-architecture |
| version | 1.0.0 |
| description | Plan the structural and execution architecture of a feature, app, or site — produce both
an `INFORMATION_ARCHITECTURE.md` (site map, navigation, content hierarchy, user flows,
URL strategy, naming conventions, component reuse map) AND a phased `PLAN.md` (phases by
impact/effort/risk, vertical-slice tasks with sub-tasks, dependencies, estimates, and a
detailed task breakdown with Why/How/Impact/Effort). Use this skill whenever the user
wants to plan a product or feature, design site structure, lay out information
architecture, map user flows, organize content, break work into phases, build a roadmap,
plan an implementation order, or hits you with phrases like "plan the IA", "map the
structure", "break this into tasks", "give me a roadmap", "phase out the work", "create
an enhancement plan", or "what should I build first". Also use when reviewing or
refactoring an existing IA or project plan.
|
| license | MIT |
| compatibility | claude-code opencode |
| allowed-tools | ["Read","Write","Edit","Grep","Glob","Agent","AskUserQuestion"] |
| metadata | {"author":"MKAbuMattar"} |
Information Architecture
Plan the structure and the execution. Two artifacts: INFORMATION_ARCHITECTURE.md (the structural skeleton) and PLAN.md (the phased delivery plan with vertical-slice tasks, sub-tasks, dependencies, and estimates).
When to use
- The user wants to plan a product, feature, app, or site before building.
- The user wants to map navigation, content hierarchy, user flows, or URL strategy.
- The user wants a roadmap, an enhancement plan, or "what should I build first".
- A task chain ends in "and break it into phases / tasks I can pick up one at a time".
Output paths
By default, save both documents under <feature-slug>/ at the repo root:
<feature-slug>/
├── INFORMATION_ARCHITECTURE.md # structure: sitemap, nav, flows, conventions
└── PLAN.md # execution: phases → tasks → sub-tasks
If the repo already uses a convention (.design/<slug>/, .plan/<slug>/, docs/specs/<slug>/, etc.) use that instead — never invent a parallel one.
TASKS.md instead of PLAN.md (lightweight mode)
For a small, focused feature — single page, single dialog, focused refactor — produce a flat TASKS.md instead of a phased PLAN.md. Use assets/templates/TASKS.template.md. Same vertical-slice rules and reuse tags (Reuses / Modifies / New component); same five sections (Foundation · Core UI · Interactions & States · Responsive & Polish · Review); no phase numbering, no Detailed Task Breakdown. Promote to PLAN.md only when scope grows past ~10 tasks or estimates / dependency tracking become useful.
Workflow
- Locate or gather context. Look for an existing brief (
*BRIEF*.md, *SPEC*.md, README of the feature folder). If none, ask the user one short paragraph: what is being built, for whom, and what success looks like. Don't conduct a long interview at this step.
- Discover the existing codebase. Spawn a background
Explore subagent to learn what's already there — routing, navigation components, layout shells, existing pages, file-naming conventions, content models, dependencies. Do not propose an architecture that ignores what's already built. Load for the full checklist of what to look for.
