taskfile-ci-paritylisted

Wire validation so local == CI by construction: every check is a Taskfile target; CI and hooks invoke it rather than reimplementing it. Use when adding a validation gate, when local/CI disagree, or when a hook duplicates a command.
jamestexas/agents · ★ 2 · Data & Documents · score 61

Install: claude install-skill jamestexas/agents

# /taskfile-ci-parity — Single-source validation across Taskfile, CI, and git hooks ## The principle (one sentence) **Validation logic lives in Taskfile targets; CI workflows and git hooks INVOKE those targets — they never re-implement the underlying command.** When that holds, "passes locally" and "passes CI" cannot disagree, because they run the same definition. The job of this skill is to make that true and keep it true. ## The three layers (and the anti-pattern each one drifts into) | Layer | Should do | Drifts into (the smell) | |---|---|---| | **Taskfile** | own every command (`task test`, `task lint`, `task fmt:check`) | a one-off command that exists nowhere as a target | | **CI workflow** | `run: task <target>` | inlining `go test …` / `gofumpt -l …` / `npm run …` directly in the YAML | | **git hooks** | invoke `task <target>` | `.pre-commit-config.yaml` `entry:` re-implementing the same flags | If CI says `run: go test -race ./...` and the Taskfile says `task test: go test -race ./...`, you have **two copies of the same command** that will drift the first time someone tweaks one. Collapse to one: CI runs `task test`. ## How to make Taskfiles modular (DRY) — composition vs includes These solve **different** problems. Pick by scope: - **Composition** (within one Taskfile, same repo