review-harnesslisted

# review-harness Audit whether the harness still matches reality, and whether it's drifting structurally. **Never edit during review** — produce a report; the user approves changes in a follow-up. This skill is the harness's **slow lane** — it catches what a machine gate can't: stale prose, structural drift, second-source rot. Mechanically checkable invariants (counts, lifecycle moves, link validity) belong in a **deterministic CI / pre-commit gate**, not a periodic human review — so part of this review's job is to spot invariants caught *only* here and **recommend gating them** (derive-from-code + `git diff --exit-code`) so they stop recurring. Run on a cadence (`/schedule`) or after each milestone — output should be issue/PR-ready. *(A project with no gate yet: this review is the primary catch until one exists.)* ## When to invoke - After a milestone / exec-plan / phase · after a major architectural change · on a periodic schedule · when the user types `/review-harness`. - **Default cadence: monthly + after each major line closeout.** Weekly mechanical drift should be a CI cron (e.g. LinkPea's `weekly-harness-check.yml`), not this review — this is the slow lane for what machines can't judge. (2026-07-15 定,文档整治批次 D) ## When NOT to invoke - Mid-task (context still changing) · right after `/bootstrap-harness` (nothing to audit) · a single one-off fix (just make it). --- ## Steps ### 0. Find the previous review report (追账前置) Look for the most recent prior report (conv