double-knuthlisted

Generic two-pass "Double-Knuth" review for ANY repo or file set: Pass 1 = correctness/bugs on the change (delegates to /code-review when a git diff exists, agent-based otherwise), Pass 2 = completeness + cross-file/doc consistency — the defect class a diff reviewer structurally cannot see (stale counts/enumerations, docs contradicting changed behavior, dead paths, orphaned files, contract drift). Read-only: returns a ranked BUG/RISK/NIT list with file:line + concrete fixes. Specialized versions take precedence: websites → website-review; this skill covers everything else (skill suites, scripts, tools, configs). Trigger phrases: "double knuth this", "double knuth the code", "double knuth the repo", "two-pass review", "consistency review", "did the docs drift", "review the whole repo, not just the diff".
karero/website-builder · ★ 4 · Code & Development · score 74

Install: claude install-skill karero/website-builder

# Double-Knuth — generic two-pass review The review standard the website suite already uses, generalized. Run it at the END of a work batch, after a multi-file fix wave, or before trusting a new tool — the moments cross-file consistency silently breaks. Read-only: report findings; fix only when asked. ## Pass 1 — correctness (the change itself) - **In a git repo with a diff:** run the host's diff-review command if it has one (Claude Code: `/code-review`, effort `high` after a fix wave or for new analytics, `medium` for routine edits); on hosts without one (e.g. Codex), review the diff yourself in a fresh context with the adversarial BUG/RISK/NIT prompt. Either way it covers correctness bugs + reuse/simplification. - **No repo / no diff:** spawn a read-only agent over the changed files (or, if the host has no sub-agent primitive, review them in a separate fresh session) asking the two killer questions per guard/test/check: *"can this pass while the thing it protects is broken?"* (Rule 9) and *"does anything skip silently?"* (Rule 12) — hunt latent bugs that green tests cannot see. - If the artifact has its own gate (test suite, build, linter), it must be green BEFORE Pass 1 — the review is not a substitute for the gate. ## Pass 2 — completeness + cross-file/doc consistency Hunt what no diff can show. Check the repo against its own claims, verifying every claim against actual file contents (never from memory): - **Counts & enumerations:** "the four modul