agentleFS
jggomezjggomez/expert-ai-developer-skills/skills/flutter-review-checklist/SKILL.md

flutter-review-checklist

Skill30 starsChanged 4 days agoApache-2.0View on GitHub

Use when reviewing a Flutter/Dart pull request or auditing code quality — rebuild scope, const, keys, dispose/leak safety, async BuildContext, DESIGN.md & ADR conformance, and fail-honest <= 50-line verdicts.

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Pure formatting or RenderFlex overflow fixes: Use dart format or flutter-fix-layout-issues.

    line 17
  2. Very specific:

    Non-Flutter backend services: Use code-critic, code-smells-expert, or refactoring-code-expert.

    line 18
  3. Very specific:

    Governance & Design Contracts: Verify alignment with root AGENTS.md (<= 90 lines wired to context/memory/MEMORY.md), official Google root …

    line 36

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Flutter Review Checklist

Overview

Flutter Review Checklist provides a systematic quality, performance, and accessibility audit for Flutter/Dart diffs across Claude Code and Google Antigravity—complementing dart-run-static-analysis and flutter-fix-layout-issues by catching runtime rebuild bloat, .dispose() leaks, async BuildContext hazards, DESIGN.md/ADR drift, and hallucinated test results in a Zero-Fluff (<= 50 lines) report.

When to Use

Trigger Scenarios

  • Reviewing PRs touching lib/** widgets, controllers/blocs/notifiers, routing, or platform channels.
  • Auditing screens for 60/120fps jank, memory leaks, accessibility (a11y), and DESIGN.md / ADR compliance.

When NOT to Use

  • Pure formatting or RenderFlex overflow fixes: Use dart format or flutter-fix-layout-issues.
  • Non-Flutter backend services: Use code-critic, code-smells-expert, or refactoring-code-expert.

Process

flowchart LR
    A["PR Diff"] --> B["Tool Baseline + Audit Script"]
    B --> C["Checklist + DESIGN.md + ADR Audit"]
    C --> D["Verify test-matrix.md & Exit 0"]
    D --> E["<=50-Line Verdict: APPROVED | REJECTED"]

1. Fail-Honest Automated Baseline

Execute automated checks first; if flutter test or integration_test/ cannot run (missing SDK, no simulator/Chrome), report BLOCKED: Not executed — <exact command & terminal error> (or SKIPPED when N/A)—never fabricate PASSED.

2. Walk Checklist, DESIGN.md & ADR Conformance

Audit diffs against references/flutter-review-checklist.md with file:line precision:

  • Rebuild & Lifecycle: Leaf-scoped setState/consumers, const constructors, .dispose()/.cancel() on all controllers/subscriptions, and if (!mounted) return; after every await before using BuildContext.
  • Lists, Images & a11y: ListView.builder/CustomScrollView for dynamic lists, cacheWidth/cacheHeight on images, RepaintBoundary on animations, >= 48x48dp tap targets, and explicit Semantics/tooltips.
  • Governance & Design Contracts: Verify alignment with root AGENTS.md (<= 90 lines wired to context/memory/MEMORY.md), official Google root DESIGN.md (<= 110 lines 2-layer YAML + 8 sections) + optional docs/<feature-name>/design.md (<= 35 lines screen delta), and concise MADR docs/<feature-name>/adr-NNN-*.md (<= 55 lines) / doc/adr/.

3. Zero-Fluff Verdict (<= 50 lines)

Output findings table (file:line, severity, fix) + metrics + verdict (APPROVED | REJECTED) only. Flag any hallucinated test/E2E PASSED claim without exit code 0 or bloated artifacts exceeding line caps (DESIGN.md > 110, design.md > 35, adr > 55, architecture.md > 70, test-matrix.md > 80) as REJECTED.

Usage

python3 ./skills/flutter-review-checklist/scripts/flutter_project_audit.py
dart analyze
dart format --output=none --set-exit-if-changed .
flutter test --coverage

Red Flags

  • Using BuildContext across await without mounted, instantiating controllers in build(), or omitting .dispose() / subscription.cancel().
  • Using ListView(children: [...]) on unbounded lists or omitting Semantics/48x48dp targets on icon controls.
  • Accepting PASSED claims without exit code 0 terminal output, approving ADR/DESIGN.md drift, or writing review reports > 50 lines.

Verification

  • dart analyze, dart format, and python3 ./skills/flutter-review-checklist/scripts/flutter_project_audit.py executed with exit code 0 (or honest BLOCKED error).
  • All async BuildContext usages guarded by mounted and all controllers/subscriptions disposed.
  • Conformance verified against root AGENTS.md, Google root DESIGN.md (<= 110 lines), ADRs (<= 55 lines), and IEEE/ISTQB docs/<feature-name>/test-matrix.md (<= 80 lines).
  • Final review report is <= 50 lines with explicit APPROVED or REJECTED verdict.

References

  • Flutter Comprehensive Review Checklist

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.