Ship a Flutter app to both stores in 20 days.

Not another boilerplate. Spec to store listing, with gates that PowerShell, cmd and Git Bash all run the same way.

curl -fsSL https://raw.githubusercontent.com/Jujubalandia/flu-harness/main/scripts/install.sh | sh

Get started in 5 steps See the lifecycle

Fig. 01 - what the wizard already knows

State

Riverpod

Routing

go_router

Backend

Supabase

Local DB

Drift

Design system

material_ui

i18n

gen-l10n

Monetization

RevenueCat

Testing

mocktail

16 dimensions read straight out of pubspec.yaml. It only asks the things it genuinely cannot guess.

Days, spec to store submission

Doctor checks, one command

Knowledge rules, copied by stack

Shells that run the same gates

The whole lifecycle

Writing the code is one sixth of shipping an app.

Every phase gets a doc template, a gate and a day range. Nothing gets to be the part you deal with later.

D1-D301

Spec

Problem, market, competitors, a cut/keep list, the viral loop. Decided before the first line.

01-spec.md

D1-D2002

Plan

Phases, milestones, definitions of done, and the blockers everyone hits anyway.

02-dev-plan.md

D4-D1303

Dev

One MVP feature a day, with knowledge rules loaded per file you touch.

03-quality-gates.md

D13-D1504

Test tiers, a device matrix that assumes you do not own a Mac, golden paths.

04-testing.md

D15-D1705

Store

Assets, metadata, AAB and IPA upload, review checklist, and the lead times nobody budgets for.

05-store-launch.md

D17-D2006

Launch

A D-7 to D+14 calendar, per-platform post templates, and yes, a landing page.

06-marketing.md

Develop

Rules that show up on cue

Twenty knowledge files load by glob. Edit a Supabase call and the RLS and secure-storage rules arrive. No Supabase in the project? You never see them.

Test

26 checks, exit code 1

Doctor reads only: environment, structure, dependencies, security, hooks, and the Windows shell health that nothing else checks. Every FAIL ships with its fix.

Build

Three profiles, three shells

minimal, standard or strict. Pre-commit runs format, analyze and lint; pre-push adds tests and a real debug APK build. Same plan in all three shells.

What is in the box

Six pieces that stop you re-deciding the same things.

Init wizard

Open a directory and type the command. It reads pubspec.yaml across 16 dimensions, shows you the table, and asks only what it cannot infer.

16 dimensionsnew or existing

Doctor

26 health checks on any Flutter project, readable or as JSON for CI. Every FAIL comes with the exact fix. It never edits your files. Checks 22 to 26 are the Windows ones nothing else covers.

bashpowershellcmd

Three shells, one plan

The gate plan lives in gates.def. Three runners parse that same file, so PowerShell, cmd and Git Bash cannot drift apart. The test suite proves it.

gates.defdry-run

Selective rules

Twenty knowledge files: Riverpod, go_router, Supabase, Drift, freezed, gen-l10n, RevenueCat, Windows. Copied only when your stack earns them.

glob-loaded20 files

Destructive-op guard

A declarative denylist plus a runtime hook. flutter pub publish, force push, keytool, DROP TABLE and rm -rf / are stopped before they run.

settings.jsonno python3 needed

Six phase docs

Spec, dev plan, quality gates, testing, store launch, marketing. Pre-filled templates, not empty headings you never reopen.

docs/D1 to D20

Live from the terminal

It talks back.

Two commands do most of the work. One stands a project up; the other tells you, in 26 checks, exactly which part of it is about to embarrass you in front of App Review.

~/projects/my-app

$ /flu-harness:new-flutter-project

-> reading pubspec.yaml ...

   State          Riverpod              [detected]

   Routing        go_router             [detected]

   Backend        Supabase               [detected]

   Local DB       Drift                  [detected]

   Design system  material_ui            [detected]

   Secure storage shared_preferences     [WARNING]

   i18n           (none)                 [WARNING]

? Confirm this stack? (Y/n) y

   ok CLAUDE.md written (no placeholders)

   ok docs/ : 6 phase templates

   ok .githooks/ : profile strict

   ok .githooks/lib/ : quality.sh + .ps1 + .cmd

   ok .claude/rules/ : 11 of 19 rules copied

   ok .claude/settings.json : denylist armed

   Verifying the three shells agree ...

   sh, PowerShell and cmd produced the same plan

Next: /flu-harness:flutter-doctor

Five steps. Roughly nine minutes.

Prereqs: Flutter 3.35+ stable, git, and Claude Code. Windows needs Developer Mode and Git for Windows.

Check your prereqs

Flutter stable, git, Claude Code. On Windows also enable Developer Mode: Flutter needs symlink support, and Git for Windows supplies the sh that runs your hooks.

flutter --version      # need 3.35+ stable
dart --version         # ships with Flutter
start ms-settings:developers   # Windows: symlink support

Install the harness

One command per shell, no SSH key. Git Bash gets install.sh, PowerShell gets install.ps1, cmd gets install.cmd. All three produce the same layout.

# Git Bash, macOS, Linux
curl -fsSL https://raw.githubusercontent.com/\
  Jujubalandia/flu-harness/main/scripts/install.sh | sh

# PowerShell
powershell -ExecutionPolicy Bypass -File scripts\install.ps1

# cmd.exe
scripts\install.cmd

Pick a gate profile

strict is the default and the one you want, because its pre-push build gate is the only thing that catches a Gradle failure before CI does.

# strict (default): everything, including a real APK build
# standard: format + analyze + lint + tests
# minimal: analyze only, for the first fast days
echo strict > .githooks/.profile

Run the wizard

From your project directory. It detects, confirms, then writes CLAUDE.md, docs/, hooks and rules, and proves the three shells agree.

mkdir ~/projects/my-app && cd $_
claude
> /flu-harness:new-flutter-project

Ask the doctor

Baseline on day one. Re-run it after every clone, after every hook that fails without a reason, and before any release build.

> /flu-harness:flutter-doctor
# OK: 26  WARN: 0  FAIL: 0  / 26

View on GitHubPublic repo. Clone it, fork it, open a PR.

It is public now. Come break it.

No SSH key, no access request. Clone it, run the suite, and send the rule or the check you wish had been there. Template changes land in projects created afterwards; existing ones are never touched.

Report a bug Request a check

Clone it

HTTPS, no key. git clone https://github.com/Jujubalandia/flu-harness ~/.flu-harness

Prove it still works

bash tests/test.sh. It asserts the three shells agree on the gate plan, that the guard blocks and allows the right things, and that the hooks are LF.

Try it for real

Run the wizard and the doctor in a throwaway project before you open the PR.