pr-pipeline: tidy a lane's diff inside resolve-issue before its one push

Problem (P2)

Owner (relayed by GitHub Support, 2026-10-19): simplify, doc cleanup and ai-slop should run on every PR before AI review, "save review till all the dust is settled". Two gaps, verified by GitHub Support (inventory: operator checkout .work/gh-monitor/quality-skills-placement.md):

Lane PRs get no refine: pr-refine.yml:24-31 skips pull_request events from the lanes App or another bot (18 of the last 30 runs skipped).
Refine races review: fix-docs and both review lanes start on the same event, so reviews judge the pre-refine head and the refine push restarts both.

Proposal

Inside resolve-issue, before it commits: deterministic format and lint; simplify on the diff; dissolve-comments on added lines; doc hygiene and ai-slop on changed markdown; re-run the deterministic checks; then one push. No extra push, review run or token mint. Wide-scope audits stay scheduled sweeps that open their own small PRs.

Needs

The runner allows an activity a declared list of skills (today --allowedTools "Skill(<plugin>:<skill>)", one skill per run; pr-run-activity.md around line 322). Widening what a lane may invoke is a lane-power change: owner approval per change (GitHub Support is asking).
A diff-scoped tidy entry point: batch-simplify has no base-ref scope and its branch mode breaks on a lane's detached head.
Turn budget: tidy steps spend turns inside the feat(pr-pipeline): budget issue runs by issue fields and resume capped runs #8281 issue-field budgets; give tidy its own bounded share so it never starves the fix, and skip tidy for docs-only changes beyond the markdown passes.
Measure first: GitHub Support's baseline (rounds per PR, re-verifications per PR, minutes per merged PR), before and after.
With tidy in-run, the pr-refine skip for lane PRs (gap 1) can stay; refine then covers human PRs only.

🤖 Generated with Claude Code

Proposed work class: work-class: structural
Basis: automated intake triage; the lanes App applied this class.

Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none

Understood: run diff-scoped tidy (format/lint, simplify, dissolve-comments, markdown hygiene and ai-slop, re-check) inside resolve-issue before its single push, with a bounded turn share. PR #10224 merged with Refs:, so some work landed, but the issue stays open. The remaining acceptance criteria need a check against what that PR delivered.

The newest decision comment (#8485 (comment)) settles the earlier open questions: cutoffs, turn share and a new diff-scoped skill. I'm asking nothing new. No duplicates found.

_{Automated triage, applied by the lanes App.}

Decision recorded.

Question: should the implementing lane (work-resolve-issue) run a named list of quality skills before its single push, so every lane PR reaches review already tidied? Order: deterministic format and lint, simplify on the diff, dissolve-comments on added lines, doc hygiene and ai-slop on changed markdown, then re-run the deterministic checks. Options: (a) yes; widens what this one lane may invoke, limited to these quality skills; (b) no; tidy runs as a separate step after the PR opens, at the cost of an extra push and review round per PR.
Answer (owner, 2026-10-19): "Was recommended", which is (a).

Scope stays as written in this issue: tidy gets a bounded share of the turn budget, docs-only changes run only the markdown passes, and baseline metrics are taken before and after.

Owner addition (2026-10-19), verbatim: "some of those quality skills may need their own agent runs if it's a large sweep. Otherwise, it depends on the size and scope of the PR, right? How many files change, lines of code, the impact, the different areas. Nothing is ever black and white."

Design consequence (GitHub Support's proposal):

Route tidying by diff size and spread, measured before the commit: files changed, lines changed, number of plugins or areas touched, and whether it touches shared or high-impact paths.
A small, single-area diff runs the tidy passes inside the resolve-issue run, as decided.
A large or multi-area diff gets separate tidy runs, one per area, after the PR opens. The AI review waits until those finish, so review still sees the final code.
Set the thresholds from the loop baseline (rounds per PR, pushes after open, minutes per PR), not by guess, and revisit them after the first week.

Owner confirmed in the Automation Lanes session (2026-10-19): build it. Phase 1 builds the small single-area in-run path; per-area tidy runs for large or multi-area diffs follow once GitHub Support's baseline sets the thresholds.

Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.

To hold this issue again, add needs-human (or status: needs-decision) and say why in a comment.

Decision recorded. The owner answered in the Issue Triage session (2026-10-25), accepting the recommended answers below:

go with whatever the facts/data/metrics + /discovery:research says and ensure we're aligned with SOLID, DRY/SSOT principles

AND whatever is aligned with my overall goal of lowest friction, highest throughput (within our environmental, github, rate limit, etc. constraints)

Question asked: For Phase 1, do you accept the recommended small single-area cutoffs, a tidy share of about 25% of the turns, and a new diff-scoped tidy skill?

Already decided: #8485 (comment) (2026-10-19: (a) resolve-issue runs the named quality skills before its one push)
Already decided: #8485 (comment) (2026-10-19: build Phase 1, the small single-area in-run path, first)

What numeric cutoffs make a diff small and single-area for the in-run path (files, lines, areas, shared paths)?
Accepted: At most 10 files, 300 changed lines, one plugin or area, and no shared or high-impact path, held in one named config value so the baseline can retune it. Larger diffs skip in-run tidy until the later phase. Basis: judgment (kept); your 17:53Z confirmation leaves thresholds to the baseline only for the large-diff phase, so Phase 1 needs a starting value.
How big is tidy's turn share, and what happens at the cap?
Accepted: About 25% of the activity's --max-turns. At the cap, skip the remaining tidy passes and push the fix; never fail the run for tidy. Basis: docs/conventions/pr-pipeline/pr-run-activity.md:376-377 (--max-turns comes from the models profile) and the body's "never starves the fix"; the 25% is judgment (kept).
Trust boundary (widens what the lane may invoke). Is the diff-scoped entry point a new skill or a mode on batch-simplify?
Accepted: A new diff-scoped skill that takes a file and line list, added to the lane's allowed list as one of the quality skills decision (a) allows. batch-simplify's scopes are a time window, a branch or the repository, and its branch mode requires a non-default branch, which a lane's detached head is not. Basis: plugins/code-tidying/skills/batch-simplify/SKILL.md:5 and :168 on origin/main 4ab8989 (kept; replaced the refinement's judgment basis).

Acceptance criteria:

Inside resolve-issue, before it commits: deterministic format and lint; simplify on the diff; dissolve-comments on added lines; doc hygiene and ai-slop on changed markdown; re-run the deterministic checks; then one push.
No extra push, review run or token mint.
The lane's allowed skills widen only to these quality skills.
In-run tidy runs only on a diff within the small single-area cutoffs, held in one named config value.
Tidy uses at most its bounded turn share; at the cap the remaining tidy passes are skipped and the fix is pushed.
Docs-only changes run only the markdown passes.
The diff-scoped tidy entry point works on a lane's detached head.
The pr-refine skip for lane PRs stays.

Checks a person runs:

Baseline metrics (rounds per PR, re-verifications per PR, minutes per merged PR) taken before and after.

The triage sweep dispatched intake triage for this issue (attempt 1 of 2).

The lanes App's pull request #10224 merged with Refs:, so this issue stays open and nothing starts the lane on it again. work-unblock removed status: ready and agent-ready, so the hourly triage sweep sends it back to intake triage, which decides what work is left and admits it again.

The work-resolve-issue lane stopped partway through this issue and needs a person.

Why, in the run's own words:

Phase 1 of ＃8485 is already on main, so this run changed nothing. A person should close the issue or reshape it. Each acceptance criterion in the 2026-10-26 recorded decision already holds on main: docs/conventions/pr-pipeline.yaml:331-356 sets work-resolve-issue's tidy block (entry code-tidying:tidy-diff; passes docs-hygiene:write-for-agents, docs-hygiene:write-for-humans and ai-slop:audit; turn-share 25; cutoffs of 10 files, 300 lines, 1 area and the shared paths, all in one named config value). .github/actions/collect-base-activity/action.yml:634-656 allows only those skills and writes the cutoffs and the tidy turn budget into the preamble. plugins/code-tidying/skills/tidy-diff/SKILL.md takes a file-and-line list with no branch or base ref, so it runs on a detached head; it runs only the markdown passes on a markdown-only change and skips the passes left at its --turns budget. plugins/work-items/skills/work/SKILL.md CI mode step 4 measures the change, tidies it only within the cutoffs, then runs every check again before the one patch. This run's own system prompt carried those Tidy cutoffs, which shows the path works. Two things remain, and neither can be built here. (1) The large or multi-area diff path: per-area tidy runs after the PR opens, with review waiting for them. The owner put this after Phase 1, with thresholds set from GitHub Support's baseline, so it needs that baseline before it can be built and should become its own issue. (2) The before-and-after baseline metrics, which the recorded decision lists as a check a person runs. One finding for whoever closes the issue: the criterion 'the pr-refine skip for lane PRs stays' no longer matches main. .github/workflows/pr-refine.yml:8-11 now dispatches fix-docs for any ready PR that changes markdown, whoever opened it, except Dependabot, the release App and the standards-sync App, so lane PRs get fix-docs too (the restore that ＃9332 refers to). This run did not touch that workflow, which is a protected path.

What the run says it did not do:

Per-area tidy runs after the PR opens for a large or multi-area diff (the owner's later phase): not built, because its thresholds come from GitHub Support's baseline, which does not exist yet
Baseline metrics (rounds per PR, re-verifications per PR, minutes per merged PR) before and after: the recorded decision lists them as a check a person runs
tidy, review, verify and checks steps skipped: there is no diff to tidy, review, build or lint
git status lists untracked dotfiles at the checkout root (.bashrc, .gitconfig, .mcp.json, .idea, .vscode and others). This run did not create them: they come from the runner environment and should stay out of any patch

Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/40638026671

To retry, remove needs-human and add agent-ready again.

Navigation Menu

Repository navigation

pr-pipeline: tidy a lane's diff inside resolve-issue before its one push #8485

Problem (P2)

Proposal

Needs

4 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

pr-pipeline: tidy a lane's diff inside resolve-issue before its one push #8485

Description

Problem (P2)

Proposal

Needs

Activity

github-actions commented on Oct 19, 2026

kyle-sexton commented on Oct 19, 2026

kyle-sexton commented on Oct 19, 2026

kyle-sexton commented on Oct 19, 2026

kyle-sexton commented on Oct 24, 2026

4 remaining items

kyle-sexton commented on Oct 26, 2026

github-actions commented on Oct 26, 2026

melodic-automation-lanes commented on Oct 28, 2026

melodic-automation-lanes commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions