Skill

widget-decomposition

Auto-activates when the user is working on Flutter widgets and needs help decomposing them into the Atomic Design hierarchy. Triggers on: "decompose this widget", "this widget is too big", "refactor into atoms", "split this into molecules", "extract reusable widget", "widget is monolithic", "too many responsibilities", "move to core/widgets", "create atom from this", "Widgetbook entry". Do NOT trigger for: design system comparisons (use design-system-analyzer), full codebase audits (use /audit command), or non-Flutter code.

Install

npx claudepluginhub dojocodinglabs/atomic-design-toolkit --plugin atomic-design-toolkit

Tool Access

This skill uses the workspace's default tool permissions.

Preview

You detected that the user is working on a Flutter widget that needs decomposition into the Atomic Design hierarchy.

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.1k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

claude-code-plugin-release

1 file

Automates semantic versioning and release workflow for Claude Code plugins: bumps versions in package.json, marketplace.json, plugin.json; verifies builds; creates git tags, GitHub releases, changelogs.

claude-mem

64.7k

Stats

Stars0

Forks0

Last CommitMar 30, 2026

Actions

View Source View Plugin View on GitHub View README

widget-decomposition

Widget Decomposition Advisor

You detected that the user is working on a Flutter widget that needs decomposition into the Atomic Design hierarchy.

Atomic Design Levels

Read ${CLAUDE_PLUGIN_ROOT}/references/atomic-methodology.md for the full methodology.

Quick reference:

Level

Responsibility

State?

Examples

Atom

Single-purpose UI element, no business logic

No (stateless)

Button, Avatar, Badge, TextInput, Icon

Molecule

Atoms composed with local interaction logic

Minimal (form state)

SearchBar, UserChip, RatingStars

Organism

Molecules with data binding and state management

Yes (provider/bloc)

UserList, CommentThread, ProductCard

Template

Page layout structure, slots for organisms

No (layout only)

DashboardTemplate, DetailTemplate

Page

Template bound to route and data providers

Yes (route + DI)

DashboardPage, ProfilePage

When a Widget Needs Decomposition

>150 lines — Too much in one file

Mixing layout + logic + state — Should be separated by level

Used in 2+ features — Should be extracted to core/widgets/

Has setState but is called an "atom" — Misclassified, should be organism

Builds other widgets inline — The inline widgets should be their own files

How To Help

Read the widget the user is working on

Identify which parts are atoms, molecules, and organisms

Propose a decomposition table (same format as /atomic-design-toolkit:generate)

Ask for approval before refactoring

Generate the decomposed files with Widgetbook entries

File Placement Rules

Shared widgets → core/widgets/{atoms|molecules|organisms}/

Feature-specific → features/{feature}/presentation/{templates|pages}/

Widgetbook → {widget_name}.widgetbook.dart alongside the widget

Anti-Patterns

Never hardcode colors — use Theme.of(context).colorScheme

Never hardcode text styles — use Theme.of(context).textTheme

Never skip Widgetbook entries

Never put business logic in atoms or molecules

Never create a page without a template