Skaii-Toolkit
Two repositories, one idea. Small single-purpose tools that check work rather than produce it, and the review skills that drive them.
The one sentence everything follows from
A tool that says it cannot determine something is working correctly. One that guesses is not.
That is the whole design brief. Every tool here under-claims where it cannot tell, and cannot-determine is a correct answer rather than a failure to report. It sounds obvious written down. It is not what most checking tools do, because a confident wrong answer is easier to build and reads better in a summary, and it is worse than no answer at all: it spends somebody's trust on a result that has not earned it.
The tools
-
falsify
A falsification harness. It corrupts a subject on purpose, runs the subject's own checks against each corruption, and reports which corruptions the checks failed to notice.
A corruption that survives is a hole in the subject's tests, named and located. It never edits the subject permanently, and it never judges whether a test is good, only whether it noticed. Its own documentation leads with what it does not do, including the one gap that is left to the caller.
-
record-guards
A checker for the ways a feature's spec, plan, decision log and contract documents quietly stop agreeing with each other and with the code.
Four guards: a retired term surviving on a line with no supersession marker, a verification claim whose covered files changed after the date it claims, a citation pointing at a decision that does not exist, and a file under the record root that no glob covers. The guards are lexical by design. They catch named things drifting; they do not read for meaning, they never edit, and every fix stays a human decision. Everything record-specific lives in that record's own directory, so the executable holds no knowledge of any particular record and can be pointed at one in any repository.
-
forge
The implement half of a pair. It carries a change out in an isolated git worktree, gates it on the project's own checks, hands that worktree to a review round, and produces one diff.
The isolation is the feature. Nothing reaches the working tree until something has looked at it, and landing the result is off by default rather than on.
-
gauntlet
The review half. It runs review agents in parallel over a change, records findings in a per-round ledger, validates each one before anything is written against it, and never lets an agent rule on a patch it wrote itself.
Most of its development history is defects in its own isolation, which is the honest thing to say about a tool whose entire value is that a round measures the tree it claims to measure.
Why this is two repositories and not one
A feature's record belongs in the repository whose code it governs. That sounds like filing policy and it is actually the thing that keeps a specification honest: a spec sitting somewhere other than the code it describes drifts, because nothing that changes the code is obliged to walk past it.
So the tools' specifications live with the tools, and only the skills' own records live with the skills. Four feature records were written under an earlier split that kept them apart, and all four were migrated back to the code they govern. The split is retired, and saying so here is cheaper than letting somebody rediscover it.
How it is put together
Two repositories, presented together because they are one body of work. skaii-tools holds the executables: a .NET 10 solution where each tool is self-contained, with its own source, tests, spec record and prompts, and nothing outside its own directory needed to build or run it. There is no CI pipeline, by choice. The tools are run locally by whoever or whatever is doing the work.
skaii-skills holds the skill material: the prompts, specifications, generations, run logs and incident records for the review skills themselves.