You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bias triage and batching toward issue types with higher agent-PR merge rates #20
Empirical evidence: autonomous-agent PRs merge at substantially higher rates for some issue types (docs, CI, build, small refactors) than others (bug fixes, performance work). The current template's triage and batching (Phases 1–2) treat all issue types equally and require the agent to make value judgments about issues without surfacing the reasoning.
Where Do AI Coding Agents Fail? 2026 (arXiv:2601.15195): merge rate strongly conditioned on issue type and PR size.
LLMs for Issue Classification (arXiv:2506.00128): LLM triage accuracy 70–85%. Useful as filter, not decision-maker.
Confidence: medium-high for issue-type effects; medium for LLM-triage accuracy.
Proposal
Two changes to Phase 1 (Triage) and Phase 2 (Work selection):
1. Emit triage reasoning
When the agent decides to skip an issue, it must say so explicitly with the reason — either in the PR body of whatever it does pick, or as a comment on the skipped issue. Don't silently filter. This makes the triage auditable without requiring perfect accuracy.
2. Bias batching toward higher-merge-rate types
In Phase 2, when choosing between issues of comparable scope, bias toward (in order): documentation fixes, CI/build fixes, small refactors, then bug fixes, then performance work. Encode as a tiebreaker rule, not a hard exclusion — a clearly-scoped bug fix is still better than no progress.
This is especially important for the first 3–5 cycles after a new dev-loop is generated for a repo, when the agent has minimal prior context.
Acceptance criteria
Phase 1 says explicitly: any issue not picked must have its skip reason recorded
Phase 2 has a tiebreaker rule listing issue-type preference order with one-sentence rationale
Phase 2 marks the "early cycle bias" as a soft preference, not a hard rule
Test plan: run against a repo with a mix of doc/bug/perf issues; observe the picks match the bias
Retrofit
Per CLAUDE.md's promotion rule, retrofit PRs needed for all four child skills.
Activity
Bias triage and batching toward higher-merge-rate issue types (#29)