mcpField
F
flutter-design-system

flutter-design-system

github.com/musabekisakov-imjDesign & UI448 installsUpdated 14w ago
Repository

About flutter-design-system

A skill for building semantic design systems for Flutter products, grounded in existing project conventions. It emphasizes incremental migration, light and dark themes, and component behavior as well as appearance.

Key features

  1. 01Inventory existing themes and shared components
  2. 02Define semantic color, type, and spacing roles
  3. 03Map roles to Flutter theme structures
  4. 04Support light, dark, and platform behavior
  5. 05Test scaling, RTL, and component states

Use cases

  1. 01Organize design tokens for an existing Flutter product
  2. 02Migrate theme and component conventions incrementally
  3. 03Check theme transitions and text scaling

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/musabekisakov-imj/flutter-design-engineer --skill flutter-design-system

After installing, type/flutter-design-systemin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
assets/starter/
adaptive_scaffold.dart
app_theme.dart
design_tokens.dart
references/
connected-product-workflows.md
layout-and-density.md
typography-and-color.md
visual-direction.md

Details

From the project README

Flutter Design System

Build a semantic system that serves the product; do not impose a generic component library.

Process

  1. Inventory existing ThemeData, extensions, constants, text styles, colors, radii, spacing, shared widgets, and package dependencies.
  2. Identify visual language and product constraints. Read references/visual-direction.md, references/typography-and-color.md, and references/layout-and-density.md.
  3. Define semantic roles before values:
    • surfaces, content, borders, accents, status, and interaction states;
    • display, title, body, label, and numeric typography roles;
    • spacing, radius, elevation, icon size, control height, and motion roles. For products spanning multiple domains, read references/connected-product-workflows.md; give domains semantic accents without fragmenting the shared system.
  4. Map roles into ColorScheme, TextTheme, component themes, and narrowly scoped ThemeExtensions.
  5. Support light/dark contrast and platform behavior without duplicating raw values throughout widgets.
  6. Define component contracts for behavior and states, not only appearance.
  7. Migrate incrementally. Avoid replacing mature project primitives unless the new system resolves a documented issue.

Rules

  • Prefer semantic names such as surfaceRaised over color names such as gray100 in widget code.
  • Keep domain meaning out of universal primitives when a local component is clearer.
  • Avoid excessive token granularity that makes ordinary UI changes require system archaeology.
  • Test text scaling, RTL, disabled/error states, and theme transitions.
  • Keep package APIs stable when modifying a library.

Use starter assets in assets/starter/ as adaptation examples, not mandatory architecture.

Deliver

Document token decisions, migration boundaries, component contracts, theme coverage, and verification performed. State intentional exceptions.

Comments

Markdown supported