git:20261010.f8ac4d7 to git:20261010.6d49f0d

- surface_hash: sha256:fd94b69bab128b4c

- measured_tokens: 3578

- <repo> → target GitHub repository in `owner/name` form (default: <upstream>)

- Substitute these before running any `gh` command below. -->

- open-PR backlog right now". Primary output is a **dashboard** with five

- sections:

-

- | Section | What it shows | Maintainer use |

- |---|---|---|

- | **Hero cards** | Health rating, total open, ready-for-review count, untriaged-non-drafts (with >4w callout) | At-a-glance status |

- | **What needs attention** | Prioritised action recommendations (high/medium/low) with the exact slash command to run | Decide what to spend the next hour on |

- | **Closure velocity** | Per-week merged/closed bars over the last 6 weeks, plus avg/peak | Spot slowdowns or burst weeks |

- | **Pressure by area** | `area:*` ranking by weighted untriaged-old PR count | Pick a focused triage / review session |

- | **Triage funnel** | Triage coverage %, author response rate %, stalest bucket, this-week velocity | See whether the funnel is healthy end-to-end |

-

- The two original tables (**Triaged final-state since cutoff** and **Triaged still-open by area**) are kept as a *collapsible details section* at the bottom of the dashboard for maintainers who want the raw per-area numbers.

-

- The skill is the statistical complement of [`pr-management-triage`](../pr-triage/SKILL.md) — same repo, same classification logic, no mutations. Running the two in sequence (stats → triage → stats) lets a maintainer measure a sweep's effect; the dashboard's recommendations link directly back to specific `pr-management-triage` invocations.

- Detail files:

- | File | Purpose |

- |---|---|

- | [`fetch.md`](fetch.md) | GraphQL templates for open-PR list and closed/merged-since-cutoff list. |

- | [`classify.md`](classify.md) | Triage-status detection (waiting vs. responded vs. never-triaged) — reuses the `Pull Request quality criteria` marker from `pr-management-triage`. Also defines the per-PR `pressure_weight`. |

- | [`aggregate.md`](aggregate.md) | Area grouping, age buckets, totals, percentage rules. Also defines weekly velocity buckets, area pressure scores, and the health-rating thresholds. |

- | [`render.md`](render.md) | The dashboard layout (hero / actions / trends / hotspots / details) plus the underlying tables, colour scheme, and recommendation rules. |

- **Golden rule 1 — no mutations, ever.** This skill only reads. It must not post comments, add labels, close, rebase, or approve anything. If the maintainer asks for stats and also wants an action, decline the mutation and redirect to `pr-management-triage`.

- **Golden rule 2 — reuse pr-management-triage's triage-detection.** The "triaged" count and "responded" count depend on the same `Pull Request quality criteria` marker string and the same collaborator set (`OWNER`/`MEMBER`/`COLLABORATOR`) that drive the triage-marker rows (3–4, `already_triaged`) of `pr-management-triage` — one implementation, [`tools/pr-management` → Shared rules](../../../../tools/pr-management/README.md#shared-rules). Don't invent a second definition — both skills must agree on "is this PR triaged".

- Golden rules 3–9 move to the sibling that applies them — rule 3 in [`fetch.md`](fetch.md), rules 4–8 in [`render.md`](render.md), rule 9 in [`classify.md`](classify.md); read them before Steps 5a–6.

- Optional selectors the maintainer may pass:

-

- | Selector | Resolves to |

- | *(no args)* | default — all open PRs on `<upstream>`, closed/merged since the configured cutoff |

- | `repo:<owner>/<name>` | override the target repo |

- | `since:YYYY-MM-DD` | override the closed-since cutoff (default: 6 weeks ago) |

- | `clear-cache` | invalidate the scratch cache before fetching |

- ## Step 0 — Pre-flight

-

- 1. `gh auth status` must succeed; capture the viewer login (needed for the triage-marker check in step 2).

- 2. Run one GraphQL query that asks both for `viewer { login }` and for `repository(owner, name) { name }` to confirm the repo is reachable. `viewerPermission` is NOT required (this skill doesn't mutate) — skip the write-check that `pr-management-triage` does.

- 3. Read or initialise the scratch cache at `/tmp/pr-management-stats-cache-<repo-slug>.json` (see [`aggregate.md#cache`](aggregate.md#cache)). The cache stores the viewer login and a map of `pr_number → (head_sha, triage_status)` so a re-run inside the same session skips the per-PR enrichment.

-

- A failure at step 1 is a **stop**. Steps 2 and 3 degrade with warnings.

-

- ---

-

- ## Step 1 — Fetch open PRs

-

- Use the query template in [`fetch.md#open-prs`](fetch.md#open-prs) to get every open PR with the fields needed for classification (labels, `isDraft`, `authorAssociation`, `createdAt`, last commit `committedDate`, last 10 comments for the triage-marker scan).

-

- Paginate until `pageInfo.hasNextPage == false`. Batch size of 50 is safe (the open-PR selection set is lighter than `pr-management-triage`'s — no `statusCheckRollup`, no `reviewThreads`, no `latestReviews`). For a 300-PR backlog that's six GraphQL calls.

-

- ---

-

- ## Step 2 — Classify triage status per PR

-

- For each open PR, determine:

-

- - `is_triaged_waiting` — viewer's (or any collaborator's) comment contains the `Pull Request quality criteria` marker, the comment post-dates the PR's last commit, AND the author has NOT commented after it.

- - `is_triaged_responded` — same marker found, but the author HAS commented after it.

- - `is_drafted_by_triager` — the PR was converted to draft by the viewer at or after the triage comment (from the `ConvertToDraftEvent` timeline, optional — see [`classify.md#drafted-by-triager`](classify.md#drafted-by-triager) for the cheaper heuristic).

- - `last_author_interaction_at` — most recent `commit.committedDate` OR author comment `createdAt`, whichever is later.

-

- Cache these per `(pr_number, head_sha)` so a subsequent run skips the scan.

-

- ---

-

- ## Step 3 — Fetch closed / merged triaged PRs since cutoff

-

- The second table is a separate search. Fetch closed or merged PRs whose comment history contains the triage marker since the configured cutoff date. Use the template in [`fetch.md#closed-merged-triaged-prs`](fetch.md#closed-merged-triaged-prs).

-

- Cutoff defaults to `today - 6 weeks`. The cutoff should be configurable because a maintainer asking "how did last week's sweep do" wants `since:today-7d`, while a monthly report wants `since:today-30d`.

- ---

- ## Step 4 — Aggregate by area

- Group each PR by every `area:*` label it carries. A PR with `area:UI` and `area:scheduler` contributes to both groups. A PR with no `area:*` labels lands in a pseudo-area `(no area)`.

- Per area, compute the counters in [`aggregate.md#counters-per-area`](aggregate.md#counters-per-area): total, drafts, non-drafts, contributors, triaged-waiting, triaged-responded, ready-for-review, drafted-by-triager, plus age-bucket histograms.

- Also compute a `TOTAL` row where each PR is counted exactly once (NOT the sum of per-area counters — PRs with multiple `area:*` labels would double-count).

- ---

- Steps 5a–5h — health rating + action recommendations, weekly velocity buckets, opened-vs-closed weekly buckets, ready-for-review trend by top areas, closed-by-triage-reason buckets, area pressure scores, trend snapshots, and CODEOWNERS responsibility — are computed per [`compute.md`](compute.md).

- Step 6 renders the dashboard per the layout, colour scheme, and recommendation rules in [`render.md`](render.md).

- ---

- ## Step 7 — Publish the dashboard (always)

- Every stats run ends by publishing the HTML dashboard to a **secret

- GitHub gist** and returning the `gistpreview.github.io` URL. This is not

- optional and not behind a flag — see [`export.md`](export.md) for the

- full contract (stable per-repo gist id, in-place `PATCH` updates, the

- `dry-run` / no-`gist`-scope fallbacks, and the mandatory data-integrity

- caveats for the 1000-result Search cap).

- The published dashboard is the single canonical export format; it

- replaces any earlier "render inline only" behaviour so a maintainer's

- dashboards are directly comparable across days at a stable URL. The

- inline terminal/markdown render is still emitted for the in-session read;

- the gist is the durable, shareable artefact.

- - **No long-term historical trends.** The closure-velocity panel covers the last 6 weeks computed from the closed-since-cutoff fetch (one snapshot at fetch time). There is no persistent time-series store; tracking month-over-month is the maintainer's job — re-run the skill at a different `since:` date if needed.

- ## Budget discipline

-

- Typical session against `<upstream>`:

-

- - 1 pre-flight query (viewer + repo)

- - ~6 paginated GraphQL calls for ~300 open PRs (50 per page)

- - ~2 paginated calls for closed/merged-since-cutoff (typically 20–80 PRs per week of cutoff)

- - No per-PR REST calls — the comment scan for triage markers is done from the `comments(last: 10)` subfield in the open-PR query

-

- Total budget: ~10 GraphQL calls regardless of repo size. Well under 5% of the hourly budget.