Xakki qa-check
A quality gate you run before declaring a task done. It is project-agnostic: it discovers what changed, maps that to the project's make targets, runs only the relevant ones, and reports Pass/Fail per check.
Git mechanics follow the git-flow core; this skill only adds the gate behaviour below.
How to run
- Scope by the diff.
git diff --name-only(vs the base/last commit) → decide which check sections apply (backend / frontend / infra / docs). Run only the sections touching changed paths. Everything goes throughmake. - Run the project's checks for that scope (lint → type/static analysis → unit → targeted functional/e2e). See ask-on-first-use for the mapping.
- Report Pass/Fail per item. Green = the command exits
0and introduces no new warnings. Red = stop and fix the root cause, then re-run.
Anti-patterns — never do these to make it "pass"
- Do NOT skip or disable lint / type checks.
- Do NOT mark tests skipped (
@pytest.mark.skip,.skip,xfail, commenting out) without a real, stated reason. - Do NOT use
--no-verify, and never silence failures with|| trueor by discarding stderr. - Do NOT run the whole suite (
make test) unless the user asks — use the targeted form (name=<...>) for the modules you touched. - Do NOT auto-merge or auto-push because checks went green.
ask-on-first-use (per project)
On the first run in a project you don't know its commands. Ask the user (don't
guess) and offer to save the answers to the project's .claude/ (a line in
<project>/CLAUDE.md or a config file) so later runs skip the questions:
- Path/module → make targets mapping (which lint + test targets cover which areas, e.g. backend vs frontend).
- The minimal always-run command (e.g.
make lint). - (optional) Coverage gate — threshold and where it's enforced.