agentsclimarketplace

Flutter design taste

Skill WellDunDun/skills/skills/flutter-design-taste

Small, composable Agent Skills for better agent feedback loops, design judgment, and verification habits.

Install
npx -y skills add WellDunDun/skills --skill flutter-design-taste

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Shapes high-taste Flutter UI implementation using product intent, Material and Cupertino fit, theming, motion, accessibility, performance, and visual QA. Use when designing, redesigning, reviewing, or polishing Flutter and Dart interfaces, Material 3 apps, Cupertino-style flows, interaction feel, theme tokens, component states, or app-specific visual systems.

SKILL.md

5.3 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Flutter Design Taste

Build Flutter interfaces that feel intentional, native where needed, brand-specific where useful, and robust across screen sizes, input modes, text scale, theme mode, and performance constraints.

Quick start

  1. Inspect the existing Flutter app before changing UI: pubspec.yaml, lib/, theme files, design tokens, shared components, and screenshots if present.
  2. Identify the product surface: consumer app, productivity tool, dashboard, commerce, editor, media, onboarding, or settings-heavy utility.
  3. Choose the narrowest reference files below that match the task. Do not load every reference by default.
  4. Preserve existing state management, route patterns, naming, and theme conventions unless the request requires changing them.
  5. Implement real Flutter widgets and states, not static mockup screens.
  6. Verify with Flutter checks and runtime evidence when the UI is user-visible.

Reference map

Workflow

1. Discover the current UI language

Look for:

  • App shell: MaterialApp, CupertinoApp, theme mode, platform stance.
  • Theme layer: ThemeData, ColorScheme, TextTheme, component themes, ThemeExtension, custom token files.
  • Shared UI: buttons, fields, cards, list rows, app bars, empty states, error states, modals.
  • Evidence surfaces: screenshots, golden snapshots if already used, simulator scripts, CI commands.

2. Set a design target

Before changing visuals, name the target in plain terms:

  • User: who needs to scan, decide, create, buy, edit, learn, or recover.
  • Context: one-handed, field use, focus work, repeated operations, expressive browsing, or dense review.
  • Density: sparse, editorial, compact, operational, immersive, or form-heavy.
  • Platform stance: Material-first, Cupertino-first, adaptive native, or strongly branded custom.

3. Implement with Flutter-native structure

  • Put design decisions in theme, tokens, and reusable widgets before scattering one-off styling.
  • Prefer composable StatelessWidget and small StatefulWidget boundaries over helper methods returning widgets.
  • Make all important states real: loading, empty, error, success, disabled, focused, selected, pressed, offline, and permission-denied where relevant.
  • Keep runtime performance visible while polishing motion, shadows, opacity, clipping, and large lists.

4. Verify the experience

For user-visible UI work, run the repo's established checks and capture evidence for changed states. Use the official Flutter skills for responsive layout, routing, widget tests, widget previews, integration tests, and layout-error repair rather than duplicating those workflows here.

Guardrails

  • Do not turn every surface into rounded cards. Use cards for repeated items, contained tools, and modal surfaces, not entire page sections.
  • Do not make a generic gradient-heavy app unless the product explicitly calls for it.
  • Do not hard-code colors, type sizes, and radii throughout feature widgets when the app has or needs a theme layer.
  • Do not rely on screenshots alone for interactive flows; verify taps, focus, keyboard, scroll, loading, and failure states.

Final response

Report:

  • Files changed.
  • Design direction chosen.
  • Flutter checks and runtime evidence captured.
  • Any unverified states, platforms, or accessibility/performance risks.

Gives 0 of the 12 instructions most design systems skills give in ~1.1k tokens

Counted across 528 of the 534 authors here whose files we hold, read 2026-08-06

  • create a custom theme if neededin 54 of 528, across 10 files
  • read the corresponding theme filein 54 of 528, across 10 files
  • ask which theme to applyin 53 of 528, across 9 files
  • show the theme showcasein 53 of 528, across 9 files
  • maintain visual identity across all slidesin 50 of 528, across 6 files
  • apply the specified colors and fontsin 47 of 528, across 3 files
  • get explicit confirmationin 45 of 528, across 1 file
  • Generate a design system before codingin 19 of 528, across 6 files
  • Maintain at least 4.5:1 color contrast ratioin 19 of 528, across 8 files
  • Describe component shapes, colors, shadows, and interaction statesin 18 of 528, across 4 files
  • Check Python installation and install if missingin 17 of 528, across 4 files
  • Default to html-tailwind if stack is unspecifiedin 17 of 528, across 4 files

Said here and by no other author read

  • inspect existing app before changing UI
  • identify the product surface
  • choose the narrowest relevant reference files
  • implement real widgets and states
  • place design decisions in theme and tokens
  • prefer composable widgets over helper methods

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.