ci-pipeline-and-gates

Configures pinned Flutter GitHub Actions CI with format, analyze, freshness, and grep-based policy gates.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/zakariaf/NearlyStop --skill ci-pipeline-and-gates-zakariaf
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ci-pipeline-and-gates
Source: https://github.com/zakariaf/NearlyStop/tree/main/.claude/skills/ci-pipeline-and-gates
Command: npx skills add https://github.com/zakariaf/NearlyStop --skill ci-pipeline-and-gates-zakariaf

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Flutter CI pipelines often drift into gate-sprawl, floating toolchains, and coverage thresholds that lie, so green builds stop meaning anything. This Skill enforces a lean single-workflow CI where every gate maps to one named release-blocking contract and nothing is silently blessed or mutated. ## Core Features & Use Cases - Pinned single-file workflow: Provides a copy-paste ci.yml skeleton with pinned ubuntu-24.04 runner, subosito/flutter-action@v2, explicit flutter-version, and VERIFY markers on unconfirmed action majors. - Freshness and static gates: Runs build_runner and drift schema dumps followed by git diff --exit-code, plus comment-stripped, structure-anchored banned-import greps that accumulate offenders and fail once. - Honest coverage and goldens policy: Fixes the upward coverage lie by including untested files, strips generated code from lcov, publishes coverage as a report never a gate, and forbids --update-goldens in CI. - Use Case: When adding a new job to .github/workflows/ci.yml or writing a policy test under test/policy, use this Skill to ensure the gate is pinned, contract-backed, and reproducible locally via scripts/ci-gates.sh before opening a PR. ## Quick Start Ask the assistant to review or generate the GitHub Actions workflow for the Flutter app so every gate is pinned, contract-backed, and reproducible locally.

Frequently Asked Questions about ci-pipeline-and-gates

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up a Flutter CI pipeline with GitHub Actions?

Use a single ci.yml with a verify job on a pinned ubuntu-24.04 runner and subosito/flutter-action@v2 with an explicit flutter-version. Run dart format --set-exit-if-changed, flutter analyze --fatal-infos, and flutter test with a randomized ordering seed as blocking gates.

How do I check generated code is up to date in CI?

Run dart run build_runner build --delete-conflicting-outputs, then git diff --exit-code over *.g.dart, *.freezed.dart, and *.drift.dart files. A nonzero diff fails the build with a message telling the author to regenerate and commit.

Should I add a code coverage percentage threshold to CI?

No. Coverage should be a published report, never a gate, because a covered line that asserts nothing is worthless. First fix the upward lie by including untested files in the denominator, then strip generated code from lcov.info.

Why do Flutter database tests fail on Linux CI runners?

flutter test runs in a plain Dart VM where sqlite3_flutter_libs does nothing, so suites opening a real database fail without the host library. Install libsqlite3-dev on the runner before running the test suite.

Can CI update golden files automatically?

No. CI must only compare goldens on the pinned runner and never run --update-goldens, because a gate that fixes the thing it checks asserts nothing. Regeneration is a local, human-reviewed act.

When is a grep-based policy gate appropriate?

Only when the invariant is textually decidable, silent when broken, and one line to break, such as a banned import URI. Strip comments first, anchor to a structure, accumulate all offenders, and fail once with a clear reason.