repo-pincerlisted

Reverse-engineers a codebase by reconciling what it claims to do against what it actually does. Runs two independent passes — top-down from docs/README/manifests/API surface, bottom-up from entry points through the actual implementation — then classifies every claim as Confirmed, Drift (was true, isn't anymore), Aspirational (documented but never built), or Silent (implemented but undocumented). The discrepancy list is the deliverable, not either summary alone. Use this when onboarding onto an unfamiliar codebase, auditing whether documentation matches implementation, evaluating a dependency or vendor repo before committing to it, or when a long-lived project's docs and code have drifted apart. Triggers on "reverse engineer this repo," "does the documentation match the code," "audit this codebase," "onboard me onto this project," or "find where the docs and code disagree." The two-pass methodology is domain-general and works on any codebase, confirmed against a real, unrelated target; the one mechanical accel
Hefrock/agent-skills · ★ 0 · AI & Automation · score 68

Install: claude install-skill Hefrock/agent-skills

# Repo Pincer A system's real behavior is not what it claims about itself — it's the intersection of what it claims and what it does. Most code review reads one direction (docs, or code) and stops. This methodology reads both independently and closes them like a pincer: the discrepancies between the two passes are the actual finding. **The methodology is domain-general; the one mechanical accelerant is not — confirmed against a real, external target (a NixOS dotfiles flake repo, no relationship to this repo's own conventions).** The two-pass discipline, the explicit mandate to hunt Silent findings as their own direction rather than only verifying existing claims, and the outcome-anchored severity rubric below all transferred cleanly and produced real, fixed findings an unstructured "read the docs and check what looks off" pass had already missed. `check_structural_claims.py` (Pass 2 step 0) did not transfer the same way: it's tuned to this repo's own test-count-claim tree-block convention, and reporting "0 claims found" on an unrelated target is a real, expected result — not a failed check, and not evidence the target's docs are clean (see that step's own trust-boundary note and SKILL.md's "What's NOT built here"). If you find yourself wanting this pattern — a narrow, cheap, mechanical check run before any conversational judgment — for a *different* domain (a different kind of drift entirely, not doc-vs-code), that instinct is usually right about the *shape* being worth reu