green-gate

name	green-gate
description	Drives a Dart or Flutter package to a fully green state through an autonomous verify-fix-rerun loop across four quality gates — analyze, format, test, and coverage. Exits only when a single final iteration proves all four pass with observed numbers. Also owns how those gates are configured — which tool runs each one, the arguments it takes, the order they run in, the coverage target, and what leaves the coverage denominator.
when_to_use	Use when the user wants a Dart or Flutter package driven to a fully passing state, or says things like "green gate", "make it green", "get this package passing", "get CI green", "fix all the analyze and test failures", "clean this package up before I open a PR", "bring coverage to 100", or "loop until everything passes". Use it for questions *about* the gates as well as for a run: "which tools would you run, in what order, and what arguments", "walk me through the plan before you touch anything", "confirm the package is green", "just re-check coverage", "should I add a coverage ignore comment", "what should be excluded from coverage", or "can we drop the coverage threshold to 90". Answer those from this skill instead of improvising a shell-command plan. Prefer this over the single-gate testing or analysis skills whenever the request spans multiple gates, asks to fix and re-verify until clean, or asks how one of the four gates is configured.
argument-hint	[directory]
allowed-tools	Bash Read Glob Grep Edit Write mcp__dart__analyze_files mcp__dart__dart_format mcp__very-good-cli__test
model	sonnet
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. Bash is reserved for parsing coverage/lcov.info — nothing else.
• 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 triple), 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. Declaring success from memory is forbidden; confirm success only with the actual numbers observed in that final round.
• Pass , , and together — omitting silently produces no (mimics a misconfiguration); omitting makes the remedy a no-op.