audit-board

Pull the full board and open issue list with the gh CLI using an explicit high limit, then run per-issue obsolescence checks: merged PRs naming the issue, cited files that no longer exist, closed blockers, and drifted measurements. Verify each claim against the repo before proposing closures.

Group issues by shared fix site, shared gate, or shared decision rather than subject matter, and record membership as a cluster label so it survives between runs. Read every open issue body in one pass, since clustering depends on what one body says about another.

The gh CLI defaults to a limit of 30 and truncates silently, dropping real backlog items with no error. Always pass an explicit --limit well above the board size and confirm the returned count is below the limit before trusting downstream counts.

No. It proposes actions and applies only what the lead approves, using gh issue commands for closes, comments, and labels. Merging duplicates is explicitly delegated to a separate merge-issues skill, and it never edits code or creates branches.

The audit cannot make prioritization or doctrine decisions, which remain the lead's responsibility, and it cannot judge merge candidates that require semantic comparison. It also depends on accurate issue bodies and may miss work on branches nobody has fetched.