agentsclimarketplace

Flutter app

Skill aneebbaig/app-starter-skills/plugins/app-starter/skills/flutter-app

Bootstrap skills for Next.js, Flutter, and FastAPI apps. Current packages, no deprecated APIs, consistent structure. Claude Code plugin + AGENTS.md.

Install
npx -y skills add aneebbaig/app-starter-skills --skill flutter-app

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

Bootstrap a new Flutter mobile app, or audit and retrofit an existing one, with clean architecture, Riverpod or bloc, FVM-pinned SDK, current packages, and no deprecated APIs. Use when the user wants to start, scaffold, or set up a new Flutter app, a cross-platform mobile app, an Android or iOS app in Dart, or asks to "create a new flutter app". ALSO use on an existing Flutter or Dart codebase when the user asks to audit, review, fix, clean up, refactor, modernize, upgrade, harden, or "bring up to standard" the app, fix analyzer issues, remove deprecated APIs, restructure to clean architecture, or migrate state management to Riverpod or bloc. Handles BYOK LLM apps, backend-backed apps, Play Store release setup, and clean-architecture feature structure.

SKILL.md

5.4 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

flutter-app

Build or fix a Flutter app the way this owner builds them: FVM-pinned SDK, clean architecture (feature-first), Riverpod for state, an Either/Failure error model, current stable packages, and the house git and CI workflow with release-please and Play Store delivery.

First read the shared rules (they override anything you remember): ../shared/house-rules.md, ../shared/intake.md, ../shared/no-ai-attribution.md, ../shared/git-and-ci.md, ../shared/docs-and-context.md, ../shared/hardening.md, and (for public repos) ../shared/open-source-docs.md.

Step 0. Detect the mode, run the intake (hard stop)

Follow ../shared/intake.md exactly: detect new-app vs existing-app mode from the directory and the user's words, then ask the matching intake batch. Do not run any scaffolding or editing command until it is answered.

Existing-app mode: skip to ../shared/existing-app.md and follow it, using this skill's references/ as the standard to audit against. Steps 1-5 below are for new-app mode only.

New-app mode: the intake covers brief, app type, visibility, scale, and release target. The only stack variants left to settle, each with a default the app type usually decides (ask ONLY the ones the answers leave ambiguous, in the same batch):

  1. Backend: BYOK (each user supplies their own LLM key, no backend), a custom backend (Dio + JWT auth), or none yet. See references/architecture.md.
  2. State management: Riverpod (default) or bloc (flutter_bloc). If Riverpod, also settle codegen (@riverpod + build_runner, default) vs hand-written providers. If bloc, follow references/bloc-practices.md for everything state-related; the clean architecture stays identical either way.
  3. Local data: Drift, Isar, shared_preferences only, or none yet.
  4. Auth: Google Sign-In, backend-driven, or none.
  5. Release target: Play Store (default), App Store, or both.

If the user already answered something in their prompt, do not re-ask.

Step 1. Pin the SDK with FVM and verify versions

  • Use FVM so the SDK is pinned per project: fvm use stable (or a specific stable). Every command runs through fvm flutter ....
  • Run fvm flutter --version and record the real Flutter and Dart versions in the project docs.
  • Run scripts/check-latest.sh for current stable package versions from pub.dev. Pin those, not versions from memory (../shared/house-rules.md rule 2).
  • Pull current docs for Flutter, Riverpod, and any codegen packages via Context7 before writing code (../shared/docs-and-context.md). Riverpod's provider syntax and codegen naming change between majors; confirm before writing.

Step 2. Scaffold with the official CLI

fvm flutter create --org com.<owner>.<app> --platforms=android,ios <name>

Then add dependencies from references/stack.md and lay out the folders from references/architecture.md.

Step 3. Apply architecture and conventions

  • Clean-architecture layers, feature structure, Either/Failure model, DI, and the non-negotiable conventions (use cases, datasource interface plus impl, custom widgets, extensions, central utils, constants for everything, zero hardcoding): references/architecture.md.
  • Riverpod and Flutter do's and don'ts, and code smells to avoid: references/best-practices.md. If the state answer is bloc, use references/bloc-practices.md for all state-holder patterns instead of the Riverpod sections (the widget and code-smell sections still apply).
  • Dependency set and pinning notes (some packages must be pinned to avoid analyzer conflicts): references/stack.md.
  • Production hardening (obfuscated release builds, no baked-in secrets, no debug symbols in git): ../shared/hardening.md.
  • The no-god-code rule and layer separation: ../shared/house-rules.md rule 8.

Step 4. Git, CI, release, docs, security

  • Git branch model, conventional commits, auto-merge, release-please: ../shared/git-and-ci.md.
  • CI (analyze + test), signing, and Play Store delivery: references/quality-gates.md.
  • Gitignore signing keys, keystore, google-services.json, and .env*. Store them as CI secrets. Provide .env.example.
  • Add docs/ (git-workflow, architecture, release-process) and a README. For a public repo, ship the full open-source docs set per ../shared/open-source-docs.md and run the open-source hard gate in ../shared/no-ai-attribution.md before the first push.

Step 5. Verify before declaring done

Run the gates in references/quality-gates.md: fvm flutter analyze must be zero issues, fvm flutter test green, and the app must build and run. Then run the done gate in ../shared/house-rules.md rule 10 and echo each answer. Report real results.

Gives 0 of the 12 instructions most project setup skills give in ~1.2k tokens

Counted across 999 of the 1,637 authors here whose files we hold, read 2026-08-06

  • ask one question at a timein 29 of 999, across 28 files
  • detect the package manager from lockfilesin 28 of 999, across 9 files
  • present findings to the userin 25 of 999, across 4 files
  • explore current repo statein 24 of 999, across 3 files
  • update the agent skills block in place if it existsin 24 of 999, across 3 files
  • install husky lint-staged and prettierin 23 of 999, across 4 files
  • create the lintstagedrc filein 22 of 999, across 3 files
  • commit all changed filesin 22 of 999, across 3 files
  • run lint-staged to verify it worksin 22 of 999, across 3 files
  • initialize huskyin 21 of 999, across 2 files
  • create the husky pre-commit filein 21 of 999, across 2 files
  • create a prettierrc file if missingin 21 of 999, across 2 files

Said here and by no other author read

  • read the shared house rules files first
  • run the intake and detect new or existing mode
  • ask the matching intake batch before editing
  • pin the SDK using FVM
  • run every command through fvm flutter
  • check current stable package versions

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.