skills(running-tend): batch prose-only fixes into one rolling sweep PR

[cargo-affected-bot]

Daily review-runs audit of the 2026-08-19 → 2026-08-20 window. 85 completed tend runs, zero non-success, zero tool errors, one substantive session (nightly 32339793721) — which was correct end to end. The one finding that cleared both gates is about the bot's PR output rate, not any defect in what it produced.

The finding

Nine of the open bot PRs change nothing but documentation prose and code comments. Verified line by line (every changed line is a comment, a doc line, or markdown):

PR	Opened	Diff	File
#29	2026-05-09	+1/-0	CLAUDE.md
#47	2026-06-03	+1/-1	CLAUDE.md
#48	2026-06-05	+7/-4	src/collect.rs
#49	2026-06-08	+10/-3	tests/functional/diff_collect.rs
#50	2026-06-09	+1/-1	README.md
#60	2026-06-24	+1/-1	CLAUDE.md
#61	2026-06-24	+5/-8	tests/functional/workspace.rs
#65	2026-07-21	+8/-6	tests/functional/new_test.rs
#87	2026-08-15	+7/-3	src/shim.rs

41 added and 27 removed lines, spread over nine separate review slots. Four of them (#29, #47, #50, #60) are single-line edits. The oldest has been open 103 days.

Meanwhile the queue as a whole: 23 open bot PRs, all MERGEABLE with green CI, none blocked on conflicts. Bot PRs merged by month — 1 in May, 3 in June, 0 in July, 0 in August; the last was #57 on 2026-06-19. So the queue isn't stuck on CI or on rebases, and the nine prose PRs are a third of it.

Why this is the change to make

The nightly skill's step 8 says "The default action is a PR, not an issue", and review-runs says "Prefer PRs over issues." Both are right in general and neither has an exception for a repo that reviews in batches — so the same conditions produce the same outcome every run. That makes this structural rather than a one-off lapse, and the backlog has been logged as a below-threshold carry-over on the monthly tracker for nineteen consecutive windows without the inflow changing.

Batching is the one lever the bot controls. It doesn't touch the merge rate — only the maintainer does — but it collapses nine review slots into one for the same content, and keeps the fixes alive rather than dropping them into an issue nobody reads.

Last night's nightly reached the same conclusion independently and named two options: batch the prose fixes, or stop opening PRs for them and log to a tracking issue. It declined to pick, correctly — that's a maintainer call. This PR proposes the first option so there's something concrete to accept or reject; closing it is a clear "no" and costs nothing.

Two things worth flagging

This PR is itself another item in the queue. That's the irony, and it's why it's the only PR this run opened — everything else went to the tracker as notes.

It doesn't fold into #80, contrary to the usual dedup rule. running-in-ci says to add to an existing open PR against the same skill, and #80 targets this file. But #80 was confirmed fully superseded by #85 — all three of its recipes now ship in the pinned tend release — so it should be closed, and stacking a live rule onto it would make that closure lossy. Kept separate deliberately.

Nothing here retroactively batches the nine existing PRs; that's a follow-up a maintainer can ask for.

[cargo-affected-bot]

Self-review — posting as a comment since GitHub blocks self-approval.

I spot-checked the premise and it holds: #48, #49, #61, #65 and #87 are all doc-comment-only diffs, so the "nine prose PRs" claim baked into the rule is accurate. Two gaps in the mechanics.

Step 3 breaks on exactly the outcome this PR predicts for itself. The PR body says "closing it is a clear 'no' and costs nothing" — but closing a PR doesn't delete its branch (delete_branch_on_merge: true only fires on merge), so a declined sweep leaves docs/prose-sweep on origin. Step 1 queries --state open, sees nothing, and step 3 branches off main and pushes — a non-fast-forward against the surviving branch, since merges here are squash-only so main never contains the old sweep commits. The fix gets dropped with a push error. This repo already has five such orphans from closed PRs (docs/claude-md-selection-stranded from #36, fix/claude-md-windows-shim from #21, tend/update-workflows ×3), so the branch-survives case is the norm, not an edge. Worth having step 3 look before it branches — and a surviving branch is itself the signal that batching was declined, which is more useful than silently retrying it.

The scope test would sweep up skill edits. The operative test is bolded as "entire diff is prose", and this very PR's entire diff is markdown. The exclusion list covers it only via "changes behavior", which reads as the crate's behavior. A .claude/skills/ edit changes the bot's behavior and should never ride in a docs batch — worth naming, since that's the file a future sweep is most likely to misfile. Same suggestion also names that this rule intentionally overrides the bundled Atomic PRs guidance ("one concern per PR… if one change could be reverted without affecting the other, they belong in separate PRs"), which directly contradicts batching. Repo-over-bundled precedence resolves it, but only for a reader who recalls the precedence rule while holding both texts.

[cargo-affected-bot]

Self-review — comment rather than approve, since GitHub blocks self-approval. Both earlier findings are addressed: the stale-branch guard is in, with the delete_branch_on_merge + squash-only mechanism spelled out (I re-confirmed both on this repo's settings, and there are ~19 orphan branches from closed PRs, so the case is real), and the .claude/skills/ carve-out plus the Atomic PRs override are now named. One gap the carve-out opens up.

The carve-out's own reasoning — markdown whose diff is pure prose but which changes this bot's behavior — applies to part of CLAUDE.md too, and CLAUDE.md is named on the sweepable side twenty lines earlier. Its Architecture and module-summary prose is descriptive and belongs in the sweep; its Principles ("Prefer failing loudly… Do not add fallback paths"), Build and test, and Manual testing sections are instructions every run loads and acts on, and a reworded one changes behavior exactly as a .claude/skills/ edit does. As written the path-based test sends those into a batch. Suggestion below makes the test "does this instruct a future run" rather than "is the path under .claude/skills/", which keeps the descriptive majority of CLAUDE.md sweepable.

Also worth knowing before either merges: #80 appends its own section to this same file at the same anchor, so whichever lands second will need a rebase. Not a duplicate — different content, no reason to close either.