| 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.
