Purpose
Break a tangled, logic-heavy product surface into its constituent components, states, flows, decision trees, and dependencies — surfacing hidden edge cases and conditional branches before a single frame is designed. Solves the problem of staring at a feature so interdependent that you can't tell where a component ends, which states exist, or what breaks when a variable changes.
When to Use
Invoke this skill when the user asks to:
- Break down a complex, multi-dependency feature area before designing it
- Map all the states and conditional logic of a data-rich surface (dashboards, configurators, permissioned flows, rules engines)
- Untangle a feature with many interacting rules, roles, or data inputs
- Enumerate edge cases and empty/error/loading states they might be missing
- Produce a decomposition brief to align design and engineering on scope
- Turn a vague "this area is really complex" concern into a structured spec
Inputs Required
Before starting, collect:
- Product surface: The feature area, screen, or flow being decomposed (name + 2–3 sentence description)
- Primary user goals: What the user is trying to accomplish on this surface (1–3 goals)
- Known rules and logic: Business rules, conditional behaviors, or constraints already known (list, even if incomplete)
- Data inputs and sources: What data feeds this surface — objects, fields, external systems, real-time vs. cached
- User roles / permission variations: Different actors who see different things (if applicable)
- Known constraints: Platform (web/mobile/both), performance limits, technical or compliance boundaries
- Current pain: Where things feel most tangled or where past designs broke down
If roles or constraints aren't provided, assume a single primary role and standard web platform, and flag those assumptions in the output.
Instructions
Step 1: Component Inventory
Break the surface into discrete, nameable components — the atomic and composite building blocks.
- List each component with a stable name (e.g., "Filter Bar," "Record Detail Panel," "Bulk Action Toolbar")
- Classify each as Atomic (single-purpose, no children of consequence), Composite (contains meaningful sub-components), or Container (layout/orchestration only)
- For each component, note its responsibility in one sentence and the data it depends on
- Flag any component that appears to be doing more than one job — these are decomposition candidates
Step 2: State Matrix
For each meaningful component, enumerate every state it can occupy. Do not skip the unglamorous ones.
- Cover the standard state families: Empty, Loading, Partial/Skeleton, Populated, Error, Disabled, Read-only, Overflow (too much data), Success/Confirmation
- Add domain-specific states surfaced by the known rules (e.g., "Pending approval," "Locked by another user," "Stale data")
- Present as a table: Component | State | Trigger condition | What the user sees | What actions are available
- Explicitly mark states the user hasn't mentioned but that logically must exist ("⚠ likely missing")
Step 3: Flow Map
Map the primary and alternate paths a user takes through the surface.
- Identify the happy path first — the shortest route to each primary goal
- Enumerate branch points: any moment the path forks based on data, role, or a prior choice
- For each branch, name the condition and both outcomes
- Note entry points (how users arrive) and exit points (where they go, including dead ends and error exits)
- Represent as an indented step outline with branch conditions in bold — readable without a diagramming tool
Step 4: Decision Trees
Convert the conditional business logic into explicit decision trees.
- For each significant rule cluster, build a tree: root condition → branches → leaf outcomes
- Use nested bullets with the condition question at each node and the resulting behavior at each leaf
- Cover permission logic, data-availability logic, and validation/gating logic separately if they don't share a root
- At each leaf, specify the concrete UI consequence (what shows, hides, enables, or blocks)
- Call out any node where two rules could conflict — these are the highest-risk design decisions
Step 5: Dependency Graph
Expose what depends on what — the source of most complexity.
- List dependencies as directed relationships: A depends on B (A can't render/function correctly until B resolves)
- Cover three dependency types: Data dependencies (needs a value/object loaded), State dependencies (behaves differently based on another component's state), Sequence dependencies (must happen after another action)
- Flag circular or tight coupling — where changing one thing forces changes in several others
- Identify the critical path: the chain of dependencies that, if any link fails, breaks the primary goal
Step 6: Edge-Case & Failure Register
Systematically hunt for the cases that break designs after launch.
- Walk through each of these lenses and record what happens: empty data, single item, maximum/overflow data, slow/failed network, concurrent edits, permission changes mid-session, invalid input, partial data, timezone/locale/units, expired or stale data
- For each edge case found: describe the scenario, the risk if unhandled, and a recommended handling approach
- Rank each as Must-handle, Should-handle, or Acceptable-to-defer with brief reasoning
Step 7: Decomposition Summary & Design Sequencing
Synthesize the analysis into an actionable path forward.
- State the true complexity drivers in 2–4 bullets — what actually makes this hard
- Recommend a build/design order: which components and states to design first based on the dependency graph (design foundational dependencies before dependents)
- Identify the top 3 open questions that must be answered before design can safely proceed
- Note any scope-reduction opportunities — logic that could be simplified or deferred to cut complexity
Output Format
- Structure: Seven labeled sections in order, mixing tables (State Matrix, Edge-Case Register) with structured outlines (Flow Map, Decision Trees, Dependency Graph)
- Length: 1,200–1,800 words
- Format: Structured document — tables where enumeration matters, nested outlines where hierarchy matters, prose only in the summary
- Sections: Component Inventory → State Matrix → Flow Map → Decision Trees → Dependency Graph → Edge-Case & Failure Register → Decomposition Summary & Design Sequencing
- Tone: Staff-designer analytical — precise, systems-oriented, willing to name what's under-specified; no filler, no reassurance
Quality Checklist
Before delivering output, verify:
- [ ] Every component in the inventory has a responsibility statement and its data dependency listed
- [ ] The State Matrix covers all standard state families and flags at least the empty, loading, and error states for every meaningful component
- [ ] At least one "⚠ likely missing" state or edge case is surfaced beyond what the user provided
- [ ] Every decision tree leaf specifies a concrete UI consequence — not just an abstract outcome
- [ ] The dependency graph identifies the critical path and any circular/tight coupling
- [ ] The Edge-Case Register ranks each case (Must / Should / Defer) with reasoning
- [ ] The summary names a specific design/build sequence and 3 open questions — no hedging
Notes
- Most launch-day design failures live in the State Matrix and Edge-Case Register — the happy path is rarely where things break, so spend disproportionate effort there
- If the known rules are sparse, the highest-value output is often the list of "likely missing" states and the open questions — a good decomposition exposes gaps as much as it maps knowns
- Decision trees and dependency graphs frequently reveal that two "components" are actually one, or that one is secretly three — revisit the Component Inventory after Steps 4 and 5 if the logic suggests a cleaner cut
- Design foundational dependencies before their dependents; designing a dependent component against an unresolved dependency guarantees rework
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills