/green-gate

name: green-gate
description: >
  Drives a Dart or Flutter package fully green through a verify-fix-rerun loop across four gates:
  analyze, format, test, coverage. It owns gate configuration, so plan-only questions belong
  here: which tool and arguments run each gate, in what order, the coverage target, and what
  leaves the coverage denominator. Use it for "green gate", "make it green", "get CI green",
  fixing all analyze and test failures, cleaning a package up before a PR, bringing coverage to
  100, looping until everything passes, or confirming a package is green. Use it too when the
  user wants a gate weakened or skipped: lowering the coverage threshold, coverage ignore
  comments on untested or generated code, skipping analyze and format because they passed
  earlier, calling a 94% package done, or retrying while the same failures repeat. Prefer it over
  the single-gate testing or analysis skills.
argument-hint: "[directory]"
allowed-tools: Bash Read Glob Grep Edit Write mcp__dart__analyze_files mcp__dart__dart_format mcp__very-good-cli__test
effort: medium

Green Gate

Autonomous quality-gate loop for Dart and Flutter packages. Runs four gates — analyze, format, test, coverage — reads real tool output, edits code and tests to fix failures, and loops until one final iteration proves all four pass simultaneously with observed numbers. Acts autonomously on objective failures; escalates only on stalls, genuine ambiguity, or infrastructure failure.

This skill orchestrates tools and edits files. It defers the _how_ of writing tests to the `testing` skill — it never duplicates mocking, structure, or coverage-pattern guidance.

---

Core Standards

Apply these to all green-gate work:

• **MCP tools only, never the Bash equivalent** — analyze via

`mcp__dart__analyze_files`, format via `mcp__dart__dart_format`, test and coverage via `mcp__very-good-cli__test`. Every gate has an MCP tool; none of them runs through a shell command. The Bash test path (`very_good test`, `flutter test`, `dart test`) is hook-blocked by `block-cli-workarounds.sh` and will be denied, and `dart analyze` / `dart format` via Bash are redundant with the MCP tools. **The only Bash the loop runs is the fallback `coverage/lcov.info` parse**, and only when the test result carries no `Lines not covered:` block. This MCP-only rule is a Claude Code constraint enforced by that hook; the hook does not run on other hosts. **Cross-harness fallback:** on a host without the hook and without the MCP servers connected, run the equivalent `dart analyze`, `dart format`, and `very_good test` CLI commands instead — never block on a missing MCP server.

• **A plan-only request is still this skill's job** — when the user asks which

tools, which arguments, or what order the gates run in and does not want a run yet, answer from this skill: the same tool calls (`mcp__dart__analyze_files` with `applyFixes: true`, `mcp__dart__dart_format`, `mcp__very-good-cli__test` with the coverage parameters), in gate order, with the precedence rule that makes the order matter. Never substitute an improvised shell plan of `flutter analyze` / `flutter test --coverage` for the tools the loop actually runs.

• **Never cache green** — re-evaluate every gate every round. Fixing analyze or

test failures and writing new test files shifts both formatting and the coverage denominator, so a previously green gate can regress.

• **Exit only on observed numbers** — the loop terminates only after a single

final iteration in which analyze is clean, format reports zero changes, all tests pass, and `min_coverage` is satisfied, all observed in the same round.

• **Pass `coverage: true`, `min_coverage`, `check_ignore: true`, and

`show_uncovered: true` together** — omitting `coverage: true` silently produces no `lcov.info` (mimics a misconfiguration); omitting `check_ignore: true` makes the `// coverage:ignore` remedy a no-op; omitting `show_uncovered: true` drops the per-file uncovered lines from the result and sends the loop to the lcov file for what the tool would have handed back. `show_uncovered` arrived in `very_good_cli` 1.5.0, the plugin's minimum.

• **Defer test-writing to the `testing` skill** — when a fix requires authoring

tests, follow that skill for structure, mocking, and naming.

• **Fix root causes, not symptoms** — never weaken a gate to pass it (do not

delete failing assertions, lower the target to dodge work, or `// coverage:ignore` reachable code). Escalate genuine product/API decisions instead of guessing.

• **Act autonomously on objective failures** — analyzer errors, red tests, and

coverage gaps are fixed without re-prompting. Escalate only per the matrix.

---

The Loop

For each package root (see **Recursive / Monorepo**), run this algorithm:

1. **Discover** — resolve the package root (the `directory` argument or the workspace root); confirm a `pubspec.yaml` exists. Initialize loop state (iteration counter `0`, empty fingerprints, empty touched-files set). 2. **Analyze** — run `mcp__dart__analyze_files` with `applyFixes: true`. If any errors remain, this is the active gate. Fix, record the fingerprint, go to step 7. 3. **Format** — run `mcp__dart__dart_format` on the package root. It reformats the whole package in place. If it reports changed files, the gate is now green for the next round. 4. **Test** — only if analyze is green this round. Run `mcp__very-good-cli__test` with the coverage parameters from **Test Gate**. If tests fail, fix, record the fingerprint, go to step 7. 5. **Coverage** — only if tests pass this round. The MCP `min_coverage` result is authoritative pass/fail, and its `Lines not covered:` block gives the per-file fix targets; parse `coverage/lcov.info` only when that block is absent. If below target, author tests for the ranked under-covered files (via the `testing` skill), go to step 7. 6. **Exit** — if all four gat