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
Data note: Per-run turn/duration/cost metrics from workflow logs were not used in this report. Fetching them via the logs tool only returns ~10 runs per call (~15–60s each), which would require on the order of 100 sequential calls to cover 1,000 PRs — out of budget for a daily run. This analysis relies on PR body/metadata/comments/reviews only, which was sufficient to find a clear, well-evidenced pattern (see below).
Full Analysis Report
General Insights
Most common task type: Cluster 0, "Workflow & agentic feature config" (491 PRs, 49%) — general feature/config work on the gh-aw workflow system itself.
Second largest: Cluster 3, "Go engineering" (388 PRs, 39%) — refactors, hardening, unit tests, formal-spec coverage in pkg/.
Highest merge rate: Cluster 3, Go engineering, at 84.3%.
Lowest merge rate / outlier: Cluster 4, "Stub/abandoned WIP tasks" (70 PRs, 7%) at 51.4% — 25.8 points below the 77.2% overall rate, and the only cluster meeting the outlier threshold (≥15 PRs, ≥10-point gap).
Top Keywords: workflow, md, workflows, github, copilot, agent
Characteristics: The catch-all bucket for feature/config changes to the gh-aw workflow system itself — new safe-outputs, compiler behavior, documentation for workflow authoring, MCP tool wiring.
Top Keywords: pkg, test, coverage, added, error, add
Characteristics: Focused, well-scoped Go code changes — extracting helpers, adding unit tests, hardening exec.Command usage, formal-spec coverage. Smaller diffs than Cluster 0 but more review engagement, and the best success rate of any cluster — narrow, mechanical, code-level tasks convert best.
Top Keywords: (auto-generated placeholder boilerplate — "Thanks for asking me to work on this... I will get started...")
Characteristics: This cluster forms around PRs whose body is still the coding agent's initial auto-generated stub text rather than a filled-in description. Many originate from automated backlog-generation tools (Deep Report intelligence briefings, Avenger audits, "probe" issues, robots.txt/llms.txt requests). The averages above are skewed high by a merged subgroup that did real work but never updated its PR description; the closed subgroup (see root-cause section) never got any code at all.
Top Keywords: job, fix, actions, url, plan, started
Characteristics: Highly templated [WIP] Fix failing GitHub Actions job <name> tasks with the smallest diffs and least discussion of any cluster — these are narrow, single-purpose CI-repair tasks that mostly get merged quickly with little review overhead.
Stratified sample (up to 5 merged + 4 non-merged per cluster, most recent first) — full dataset is 1,000 PRs; this table exists to illustrate cluster themes, not enumerate every task.
[WIP] Fix related runs link rendering issue in footer
C4: Stub/abandoned WIP
Closed
0
0
Key Findings
Narrow, mechanical Go tasks convert best. Cluster 3 (refactors, unit tests, hardening) has the highest merge rate (84.3%) despite being the second-largest cluster — small, well-scoped code-level asks are the safest bet for this agent.
CI-repair tasks are cheap and reliable. Cluster 2's median diff is tiny (1.6 files changed on average) with almost no review back-and-forth (0.8 comments/reviews average), yet merges 81.2% of the time — a good template for low-friction automation.
The lowest-merge cluster is really a "task never started" signature, not a topic. Cluster 4 clusters not by subject matter but by the coding agent's placeholder PR description ("Thanks for asking me to work on this...") still being present — see root-cause section below.
Lowest-Merge Cluster Root Cause
Cluster: C4 — "Stub/abandoned WIP tasks"
Merge Rate Gap: 51.4% vs 77.2% overall (gap: 25.8 points)
Primary Blocker: Task abandoned before any code was written — not CI failure, not review friction, not scope disagreement.
What the data shows: Of the 34 non-merged PRs in this cluster, 28 (82%) share an identical, exact fingerprint: 1 commit, 0 files changed, 0 additions, 0 deletions, 0 comments, 0 reviews. These are PRs where the agent opened the initial stub PR (title often [WIP] ..., body the generic "I will get started on it" placeholder) and then the PR was closed with zero further activity — no reviewer ever engaged, no follow-up commit was ever pushed. By contrast, the 36 merged PRs in the same cluster look nothing like this: they average 7.4 commits, 75.7 files changed, and 4.75 reviews — real work happened, the description just never got refreshed.
Many of the abandoned tasks trace back to auto-generated backlog sources — Deep Report intelligence briefings, Avenger audits, "probe" test issues, and recurring robots.txt/llms.txt requests — several of which appear more than once in the sample (e.g. "Create /llms.txt for the documentation site" recurs at #51616, #52115, #53158, #53760), suggesting duplicate or already-superseded issues get re-queued as new agent tasks.
Identical 1-commit/0-diff/0-comment fingerprint; likely superseded, duplicate, or invalid before any real work began
Review friction (real code, but closed after discussion)
5
15%
e.g. #50744 (16 comments/10 reviews), #51090, #51282, #52137, #53572 — these did get reviewed and rejected/abandoned mid-flight
CI/test failure
0
0%
Not observed as a distinct blocker in this cluster
Other/unknown
1
3%
#53989 — 1 comment, closed with minimal interaction
Recommendations
Double down on narrow, code-level tasks. Cluster 3's pattern (small diff, focused scope, unit-test-style asks) has the best merge rate — prefer decomposing large feature work into this shape when queuing agent tasks.
Keep using the CI-repair template. Cluster 2's [WIP] Fix failing GitHub Actions job <name> format is cheap to run and merges reliably — a good pattern to replicate for other narrow, single-signal fixes.
Screen auto-generated backlog issues for staleness/duplication before assigning to the agent. A meaningful share of Cluster 4's failures are recurring or already-superseded asks (e.g. repeated llms.txt/robots.txt requests) — a dedupe/staleness check before task creation would avoid several dead-on-arrival PRs per week.
Add an early abandonment signal. 28 PRs sat with exactly 1 commit and 0 diff before being closed — instrumenting "PR open >N hours with 0 files changed" as a triage flag would surface these faster than waiting for a human to eventually close them, and would separate "the agent never got a real chance to work" from genuine review rejections in future analyses.
Generated by Prompt Clustering Analysis (Run: 32356081464)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Summary
Analysis Period: 2026-08-03 to 2026-08-20 (most recent 1,000 copilot-authored PRs available)
Total Tasks Analyzed: 1,000
Clusters Identified: 5
Overall Merge Rate: 77.2% (772 merged / 213 closed / 15 open)
Full Analysis Report
General Insights
pkg/.[WIP] Fix failing GitHub Actions job ...tasks, 81.2% merged.Cluster Analysis
Cluster 0: Workflow & agentic feature config
Cluster 3: Go engineering (refactor/tests)
exec.Commandusage, formal-spec coverage. Smaller diffs than Cluster 0 but more review engagement, and the best success rate of any cluster — narrow, mechanical, code-level tasks convert best.Cluster 4: Stub/abandoned WIP tasks (outlier)
Cluster 1: Agent-infra/meta refactoring
update_pull_request#53301, Extend confused deputy protection to pull_request_target #52976, Add anti-probing guidance to submit_pull_request_review tool description #51469, Warn on unsafe pull request target checkouts in non-strict mode #51103Cluster 2: CI job-failure fixes
[WIP] Fix failing GitHub Actions job <name>tasks with the smallest diffs and least discussion of any cluster — these are narrow, single-purpose CI-repair tasks that mostly get merged quickly with little review overhead.Merge Rate by Cluster
Sample Data Table
Stratified sample (up to 5 merged + 4 non-merged per cluster, most recent first) — full dataset is 1,000 PRs; this table exists to illustrate cluster themes, not enumerate every task.
44-row sample across all 5 clusters
Key Findings
Lowest-Merge Cluster Root Cause
What the data shows: Of the 34 non-merged PRs in this cluster, 28 (82%) share an identical, exact fingerprint: 1 commit, 0 files changed, 0 additions, 0 deletions, 0 comments, 0 reviews. These are PRs where the agent opened the initial stub PR (title often
[WIP] ..., body the generic "I will get started on it" placeholder) and then the PR was closed with zero further activity — no reviewer ever engaged, no follow-up commit was ever pushed. By contrast, the 36 merged PRs in the same cluster look nothing like this: they average 7.4 commits, 75.7 files changed, and 4.75 reviews — real work happened, the description just never got refreshed.Many of the abandoned tasks trace back to auto-generated backlog sources — Deep Report intelligence briefings, Avenger audits, "probe" test issues, and recurring
robots.txt/llms.txtrequests — several of which appear more than once in the sample (e.g. "Create /llms.txt for the documentation site" recurs at #51616, #52115, #53158, #53760), suggesting duplicate or already-superseded issues get re-queued as new agent tasks.Recommendations
[WIP] Fix failing GitHub Actions job <name>format is cheap to run and merges reliably — a good pattern to replicate for other narrow, single-signal fixes.llms.txt/robots.txtrequests) — a dedupe/staleness check before task creation would avoid several dead-on-arrival PRs per week.Generated by Prompt Clustering Analysis (Run: 32356081464)
All reactions