New to Claude Skills? Learn how to install them →

Rposthog on GitHub

Running CI Preflight

Free

Catch CI failures locally before pushing your code.

by posthog37.6k stars on posthog/posthog
1 views
Updated Aug 11, 2026
Get this skill

Free · Opens the source repo

What Running CI Preflight does

Running CI Preflight is a command-line tool designed to help developers identify potential Continuous Integration (CI) failures before they push their code changes. By using the command hogli ci:preflight, developers can run a curated set of checks that are specifically scoped to the files modified in their branch. This tool is particularly useful for catching issues such as formatting errors, linting problems, broken lockfiles, migration conflicts, and other common pitfalls that can lead to CI failures. The pre-push hook automatically triggers these checks, ensuring that developers are alerted to any issues before their code is integrated into the main branch.

The tool operates under a strict mode, which means it only exits with an error on actual failures, allowing developers to focus on resolving critical issues. It also provides advisory messages for potential problems that do not block the push but should be addressed to maintain code quality. For example, if there are changes in the OpenAPI specifications or if the branch is stale, developers receive actionable advisories that guide them on how to resolve these issues before pushing their changes.

This skill is ideal for teams looking to maintain high code quality and minimize CI build failures. By catching errors locally, developers can save time and resources by avoiding unnecessary CI runs triggered by easily fixable issues. It is particularly beneficial in environments where multiple developers are contributing to the same codebase, as it helps ensure that each push is as clean as possible.

However, it is important to note that this tool does not replace a full CI run. While it can catch many common issues, there are certain checks, such as comprehensive type-checking with mypy, that need to be run in a complete CI environment. Therefore, while Running CI Preflight is a valuable addition to a developer's toolkit, it should be used in conjunction with standard CI practices for best results.

When to use it

Use this tool when preparing to push code changes, especially after modifying Python files, migrations, or dependency manifests.

When not to use it

This tool is not suitable for catching all types of errors, particularly those that require a full CI run to identify, such as complex integration issues.

What you can build with it

Pre-push Code Review

Before pushing your code, run `hogli ci:preflight` to catch any potential issues that could break CI.

Fixing Linting Errors

Use the `--fix` option to automatically format and lint your code before it gets pushed.

Handling Migration Conflicts

Run the preflight checks after modifying migrations to ensure no conflicts will arise when merging.

How to install Running CI Preflight

View source

1. Install with the skills CLI

npx skills add posthog/posthog/running-ci-preflight --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by posthog

Running ci:preflight

hogli ci:preflight scopes a curated set of checks to the files your branch touched — each mapped to a CI failure class that has taken master down — plus an always-on branch-freshness check. It is the pre-push counterpart to hogli ci:insights (what is already broken on master).

The pre-push hook runs ci:preflight --strict automatically and blocks the push on failed checks. Never bypass it with --no-verify — fix what it reports instead.

The loop (when the hook blocks, or before reporting done)

hogli ci:preflight --fix
  1. Run with --fix — it formats, lints, and auto-fixes what is safe.
  2. Read each line: ✓ pass, ✗ fail, → advisory (do it yourself), · skipped (capability absent).
  3. Resolve every ✗ fail — these are what --fix could not (real lint error, broken lockfile, migration conflict). These block the push.
  4. Act on every → advisory — e.g. openapi advisory → run hogli build:openapi and commit the drift; staleness advisory → git merge origin/master. Advisories never block, but ignoring them ships the failure to CI. Resolve them before pushing, including drift you didn't introduce — you own the branch state you push.
  5. Re-run until clean, then push.

Notes

  • Strict = failures only. --strict (what the hook runs) exits non-zero only on ✗ fail — advisories are unverifiable-locally classes, so they warn without blocking. A clean exit means "nothing left to fix", not "CI will pass" — CI stays the authoritative gate. Non-blocking is a mechanism limit, not permission to skip.
  • type-check is a nudge, not a run. Only a repo-wide mypy run matches CI (mypy follows imports, so a changed-file subset misses reverse-dependency breakage), and that costs minutes cold — too much to tax every push with. So preflight names the command instead of running it: judge whether your change is type-risky and run it yourself. CI blocks on the same command, so a type error you skip here comes back as a full re-run.
  • Staleness is risk-based. It fires when merging master now would actually break something — textual merge conflicts (computed via git merge-tree, working tree untouched), migrations added on both sides, generated-file inputs changed on both sides, or CI workflows changed on master — plus a behind/age backstop, aggressive by default (5 commits / 2 days; env-tunable via HOGLI_PREFLIGHT_STALE_COMMITS/HOGLI_PREFLIGHT_STALE_DAYS) so we over-warn to start and tune down from telemetry. Merge master in when it fires. Advisory only, never auto-merged.
  • · skipped (needs stack/node) is expected on a bare checkout or sandbox. Start the stack with hogli start to run those, or let CI cover them. No hooks in your environment (no node_modules)? Run the loop yourself before pushing.
  • Flags. --against <ref> diffs against an explicit base; --json emits a machine-readable summary.
  • Kill switch. HOGLI_PREFLIGHT_DISABLED=1 makes the command (and the hook) a no-op with exit 0. It is a rollout/emergency lever — respect it; never unset it to force a run.

Why it matters

Drafts already run a trimmed CI subset; the expensive waste is a ready PR that fails the full matrix on something deterministic, gets fixed, and re-runs the whole matrix. Catching that locally is the cheapest CI saving available.

Frequently asked questions about Running CI Preflight

Similar skills