check-everything

check-everything

checkwriteshands-on

Use this when: you want a full health sweep of your current change

Problem it solves — After a big change you can't tell what is clean. This is the catch-all: it runs the relevant check- skills in one natural order — reason, align docs, record learnings, fix code, test, conform, tidy — pausing after each so you can steer.

Check everything

The umbrella over the check- family: one command to answer "are we clean and golden?". You pick by category; it runs by a fixed natural order. Skills can't invoke each other, so this is a runbook the agent works through — invoking each in-scope check- skill in turn (Skill tool). It never bypasses a sub-gate; every change happens inside that sub-skill's own surface-then-confirm step.

Pick by category — the checkboxes

Pre-flight is a 4-option AskUserQuestion multi-select (exactly the tool's cap). Tick the categories to include:

• 🔨 Work — build-pr-feedback, optimise-code, qa-tests, find-vulns, qa-code, qa-ui, qa-prompts, optimise-prompts, find-untracked-work
• 🧭 Thinking / Planning — check-reasoning
• 🧠 Brain — qa-philosophy, qa-wiki, find-learnings, qa-skills, optimise-context
• 🧹 Housekeeping — optimise-ci, janitor

Run in this fixed order — this is the skill

Selection groups by category; execution follows one workflow order, not category order, so each step builds on the last. Run the in-scope checks in exactly this sequence, skipping any that doesn't apply:

#	Check	Why here
1	check-reasoning	red-team the thinking first, before evaluating anything built on it
2	qa-philosophy	align the foundational docs with reality
3	qa-wiki	propagate that doc reconciliation to the public wiki's hand-authored pages
4	find-learnings	record lessons now — so a freshly-graduated rule is in place before code is judged
5	qa-skills	audit the tooling — prune / add / tweak skills first
6	optimise-context	trim the now-settled docs and skills token footprint
7	find-untracked-work	see what work isn't tracked
8	build-pr-feedback	apply the review-driven code changes
9	optimise-code	optimise the now-changed code (perf/efficiency)
10	qa-tests	test the now-changed, optimised code
11	find-vulns	security discovery sweep — systemic vulns in settled code, before the conformance pass sees the diff
12	qa-code	conformance pass on the fully settled diff (security lens now covers per-diff regressions only)
13	qa-ui	UI quality + coverage on the settled diff — after the code conforms, before prompts
14	qa-prompts	judge the AI prompt bodies on the settled diff
15	optimise-prompts	optimise the now-judged prompts
16	optimise-ci	tidy the pipeline
17	janitor	sweep clutter — branches, junk files, stale issues, logs

Applicability still gates each step: no plan/risky diff → skip 1; no harness change that touches a skill/agent/pillar/threshold → skip 3 (qa-wiki); nothing learned → skip 4; no review comments → skip 8; no diff → skip 9, 10, 11, 12; no UI/frontend diff (resources/js/** or a UI route) → skip 13; no prompt changes → skip 14, 15. (5, 6, 16, 17 are always runnable — skip if there's nothing heavy/cluttered to act on.) find-vulns defaults to working-set scope in a sweep; use --full only for a deliberate deep audit (go-live, epic boundary).

Workflow

1. Pre-flight — pick categories. Present Work / Thinking-Planning / Brain / Housekeeping as an AskUserQuestion multi-select (four options, exactly the tool's cap). Resolve the ticked categories into the in-scope checks.
2. Run the pipeline in the fixed order above, skipping any check that doesn't apply (say so). Read-only steps fork their heavy gathers where their skill's direct-vs-fork contract allows (e.g. qa-skills lens 1–2, qa-harness pillars) so the sweep's window lasts; acting steps stay in-thread — confirms can't leave it. Pause after every step before the next: a read-only check reports its findings, then asks "carry on, or anything to dig into / change?"; an acting check proposes → you pick → it applies. Either way the next check only runs on your go-ahead — and acting checks land before it, so a downstream check (notably qa-code) sees the settled result.
3. Final verdict — a consolidated "clean & golden ✨", or a recap of what was actioned and what was left, step by step.

Confirmation flow — pause between every step

The checks run as a pipeline, and every step pauses before the next so you can steer:

• a read-only check (e.g. check-reasoning) reports its findings, then asks "carry on, or anything to dig into / change?" — the checkpoint for the back-and-forth you might want after it challenges something. The next check runs only on your go-ahead.
• an acting check proposes its changes, you pick which to apply, it applies them — that confirm is its checkpoint — then the next check runs against the result.

So you checkpoint per step, in order — never a silent jump to the next skill, and never a write you didn't pick. The orchestrator writes nothing itself. (Dependency note: qa-code runs last, so fixes from earlier acting steps have landed before it judges the diff.)

Where it sits

• The umbrella over the check- family. For one area (just the docs, just the tests), invoke that skill directly — don't run the whole sweep.
• Read-only orchestrator — it reports; it is never the thing that writes. That stays with the sub-skills.
• Good cadence: before opening or merging a milestone/release PR, and at the start or end of a phase.

How this gets triggered

Invoke directly — "full check", "is everything golden", "run all the checks". Description-driven, not hook-fired (a full sweep is something you reach for, not something that should fire on a tool event). Context-heavy — prefer a fresh session; invoked late in a long one it can overflow the window mid-sweep.