Gate follow-up issue creation with the evaluate-issue rubric and add a sweep that closes low-value agent-filed follow-ups

[justin808]

Motivating miss

In shakacode/control-plane-flow a pr-batch coordinator filed issues 461, 462, 463, 468, and 470 from independent-checker and review-bot findings during one batch. 468 and 470 were pure checker observations (theoretical gaps with no in-tree trigger, low blast radius) and were closed as not planned by the maintainer, who asked for intelligent auto-closing of such issues.

The pack already has the policy (workflows/pr-batch-integration-closeout.md → Follow-Up Tracking Policy: "Follow-up issues are expensive. Default to no new issue") and the rubric (skills/evaluate-issue: close / not planned disposition, "do not create follow-up issues for every skipped idea"). The coordinator bypassed both because a personal CLAUDE.md rule said to always file follow-ups. Two gaps remain even when the coordinator obeys the pack:

1. Filing-time gate is prose. Nothing in pr-batch closeout mechanically runs the evaluate-issue rubric on a candidate follow-up before gh issue create. A checker's LOW/INFO findings should score as close or park and land in the PR decision log, not as issues.
2. No sweep for already-filed follow-ups. plan-issue-triage produces a review-only audit prompt; there is no execution mode that evaluates open Follow-up:-prefixed issues authored by agents and closes the close / not planned ones with the closing-evidence gate.

Proposal

• Add a triage-followups skill (or an execution mode of plan-issue-triage) that: lists open issues carrying the repo's follow_up_prefix (and optionally an agent-filed label), runs the evaluate-issue rubric per issue with the source PR's review record as evidence, and applies dispositions: close / not planned → close with a rationale comment; park / P3 → label parked, no milestone; fix later / P2 and above → keep. Require authorization the same way evaluate-issue does for label changes.
• Add a filing-time gate to pr-batch closeout: a candidate follow-up must pass the Follow-Up Tracking Policy conditions and score at least fix later / P2 under evaluate-issue; otherwise the coordinator records it in the PR decision log only. Emit the rubric result in the handoff so the decision is auditable.
• Document in the personal-instructions guidance that "always file follow-ups" must defer to the pack policy.

Acceptance criteria

• Checker-only LOW/INFO findings never become issues by default
• A one-command sweep closes or parks low-value agent-filed follow-ups with a recorded rationale
• Both paths are replayable in the batch handoff

[justin808]

Proposed refinement: quiet quality candidates, explicitly admitted maintenance

Recording the maintainer's requested direction: optional review suggestions should not automatically become issues that an agent later interprets as an instruction to implement. Separate behavior-preserving quality maintenance from feature delivery and functional bug fixes.

Record selectively in the originating PR

Use the existing PR description/decision log, optionally a collapsible Deferred code quality section. Retain only plausible, worthwhile candidates with:

• Original review-comment link.
• Affected area and one-sentence potential benefit.
• Nonblocking; no implementation commitment.

Leave other nits in their original review comments; do not copy every observation into another queue. The absence of a separate record is acceptable. Avoid issue-per-nit filing, a shared backlog file every PR must edit, a new dashboard, and mandatory bookkeeping for every declined suggestion. The PR record provides provenance without making the idea an assigned task.

For already-filed follow-ups, distinguish an actual defect or valuable improvement from optional polish using evidence and impact, not merely a bot's severity label or the Follow-up: prefix. Under the existing authorized triage process, close or park low-value items with a rationale and retain useful source links. Do not bulk-demote genuine bugs. Resolve consumer labels through repository policy rather than hardcoding labels in portable skills.

Admit an occasional focused quality task

A maintainer may explicitly choose a coherent theme from recorded candidates in merged PRs—for example, one naming inconsistency or a lint-rule migration. At admission, define scope, time/effort budget, and stopping point. Re-evaluate every candidate against the current code: stale, subjective, already-fixed, and low-value suggestions can be discarded. Selecting nothing is a valid outcome.

Keep the resulting change behavior-preserving and validate that claim appropriately for its risk. Functional changes discovered during cleanup need a scope decision. Recording a candidate, its age, or a generic instruction to "fix issues" must not automatically schedule it. No recurring sweep or new worker is requested by this comment.

Scenarios to verify

• An optional nit can be retained in its PR without creating an issue or implementation commitment.
• Later review polish cannot restart the feature's repair cycle; see the first-pass cutoff proposal in Deploy and evaluate the early review stopping rule #392.
• A separately admitted quality pass can select a coherent subset and discard stale/no-value candidates.
• A demonstrated consequential defect retains normal priority and review treatment.

Use the existing follow-up value bar, PR decision log, and task-admission mechanisms first. This is a refinement to this issue's proposal, not a requirement to build another tracking system or to make a broad cleanup sweep a prerequisite for shipping useful work.

[justin808]

Closed as completed by #827 after reconciling the original proposal with the maintainer refinement in this issue.

Evidence on current main (44c9292):

• Checker-only LOW/INFO ideas do not become issues by default. The follow-up policy defaults to no new issue, requires an observed failure or verified defect with a known affected user, and requires an explicit user choice before tracking.
• Optional quality candidates stay in the originating PR or decision log with source, area, benefit, and the explicit disposition “nonblocking; no implementation commitment.” Retention creates no dependency, schedule, or repair-cycle restart.
• The proposed recurring one-command sweep was intentionally superseded by the maintainer direction: no recurring sweep or new worker. An occasional maintenance task instead needs explicit scope, budget, stopping point, current-code evaluation, and canonical launch admission; selecting nothing is valid. Consequential defects keep ordinary priority.
• Replay is preserved through the canonical links among Optional Quality Candidates, Quality Maintenance Admission, Canonical Launch Target Gate, Initial-Pass Optional-Nit Cutoff, and Ordinary PR Closeout.
• Lighter-closeout adoption from Make ordinary PR closeout lightweight #818 is satisfied: Separate optional quality candidates from admitted maintenance #827 reused its completed clean validation, lint, and independent review evidence. This post-merge reconciliation did not rerun unchanged tests or manufacture another audit or receipt.

PR #827 merged as 3c0c6f9, that merge remains an ancestor of current main, and all four changed policy paths remain present. No residual implementation or separate follow-up is needed.