green-gate
FeaturedDrives a Dart or Flutter package fully green through an autonomous verify-fix-rerun loop across four quality gates: analyze, format, test, and coverage, exiting only when one final iteration proves all four pass with observed numbers. It also owns gate configuration, so plan-only questions belong here: which tool and arguments run each gate, in what order, the coverage target, what leaves the coverage denominator, coverage ignore comments, "just re-check coverage", and "confirm the package is green". Use it when the user says "green gate", "make it green", "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", and when a run stalls with the same failures repeating round after round. Prefer it over the single-gate testing or analysis skills when a request spans multiple gates or asks to fix and re-verify until clean.
Install
Quality Score: 90/100
Skill Content
Details
- Author
- VeryGoodOpenSource
- Repository
- VeryGoodOpenSource/vgv-ai-flutter-plugin
- Created
- 6 months ago
- Last Updated
- yesterday
- Language
- Shell
- License
- MIT
Integrates with
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
ci-pipeline-and-gates
Enforces a lean GitHub Actions Flutter CI where every gate maps to one named release-blocking contract — pinned runner + subosito/flutter-action@v2 toolchain, dart format --set-exit-if-changed, flutter analyze --fatal-infos, build_runner and drift schema freshness (git diff --exit-code), flutter test --test-randomize-ordering-seed random, static import/banned-string greps that catch what runtime can't, coverage-as-report-never-a-gate with the upward-lie fixed, verify-never-bless goldens (no --update-goldens in CI), and an honest statement of what CI cannot prove (audio, real fonts, on-device behaviour). Use when editing .github/workflows/*.yml, adding or removing a job or step, wiring a codegen/schema/format/analyze/coverage gate, writing a grep-based policy test or gate script under test/policy or tool/, pinning action versions, or claiming CI proves something it can't.
gating
Build and audit deterministic verification gates — a check that blocks a pipeline and can be shown to go red. Use when writing a calibration gate, CI check, validation script or pre-publication check for a numeric or empirical result; when a plausible-but-wrong value would survive review; when asking whether an existing test, linter rule or check could actually fail; and when a suite passes first try, passes suspiciously often, or was written by whatever produced the thing it checks. Triggers on "can this check fail", "known-bad", "negative control", "calibration gate", "sanity check my results", "is this test actually testing anything".
ci-qa-gate
Designs, reviews, and configures a quality gate in a CI/CD pipeline — what should actually block a merge and a deploy (lint/format/types, unit+integration tests, coverage threshold on the diff, static analysis/SAST, dependencies/SCA, secret-scan, E2E/smoke, migrations, IaC scan), verifying that the gate really fails the build and does not just warn, that feedback is fast and fail-fast, that flaky tests do not block falsely, and that the pipeline itself is secure (script injection, pinned action versions, minimal token permissions). Use when asked "set up a quality gate", "add tests/lint/coverage to CI", "what should block a merge", "review the pipeline for QA gates", "a gate on coverage/security", "pre-merge checks", "make it so red tests can't be merged", "check our CI for holes in the gates" — even without the word "gate", when they say "why do failing tests get into main", "let's tighten the checks before deploy", "set up pre-commit/pre-push". The skill first detects the project's CI system from its config