Add maintainer dashboard, trends, and recommendations to pr-stats skill

[potiuk]

Summary

Restructure pr-stats from "two dense tables" to a multi-section maintainer dashboard. Hero cards show repo-health rating; a deterministic recommendation panel surfaces the next slash-command to run; weekly charts cover closure velocity, opened-vs-closed momentum, ready-for-review trend by top areas, and closed-by-triage-reason breakdown; a pressure ranking points at where to focus a triage/review session. Original tables move into collapsible details for maintainers who want raw per-area numbers.

What changed

• SKILL.md — new frontmatter; new Steps 5a–5f (health/actions, weekly velocity, opened-vs-closed buckets, ready-trend, closed-by-reason, pressure score); restructured Step 6 (render dashboard primary, with detailed tables collapsed); new Golden rules 6+7 (deterministic recommendations, actions link to other skills).
• aggregate.md — five new sections: pressure score formula, weekly velocity, opened-vs-closed weekly buckets, ready-for-review trend by top areas, closed-by-triage-reason buckets, plus a health-rating thresholds table.
• classify.md — new pressure_weight helper definition.
• fetch.md — new "Ready-label timeline" section documenting the aliased GraphQL LabeledEvent query needed for the ready-for-review trend chart.
• render.md — full restructure: HTML dashboard becomes primary output (hero cards / action panel / four chart panels / pressure-by-area / triage-funnel / collapsed detailed tables / verbose legend); Rich tables move to a tables-only opt-in. New recommendation-rule table (10 rules), expanded colour scheme covering all chart elements, and a verbose multi-section legend.

Why

Maintainers asked variations of "what should I do today" — a 17-column raw-numbers table requires the maintainer to scan, compare, and infer. The dashboard surfaces those conclusions explicitly with priority colours and one-paste slash-commands. Trend charts (closure velocity, opened-vs-closed momentum, ready-for-review per area) make queue dynamics legible at a glance instead of requiring weekly mental modelling.

The change keeps the skill read-only — every recommendation points at another skill (pr-triage, maintainer-review) for the actual mutation.

Mirror

The same conceptual changes have been mirrored to the pr-management-stats skill in apache/airflow-steward (PR coming separately).

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

[choo121600]

Nice restructure overall — the dashboard sections (hero / recommendations / velocity / pressure / funnel) translate the raw tables into something a maintainer can actually scan in 30 seconds, and keeping the original tables in collapsed <details> is the right call for users who want the raw numbers. Two doc-quality nits worth a follow-up commit before merge:

1. Anchor links drop the fragment in the URL.
   Multiple cross-references write [`render.md#recommendation-rules`](render.md) — the visible text shows an anchor but the URL doesn't include it, so GFM won't actually scroll to that section. Same pattern in 10+ links across SKILL.md (Step 5a-5f bodies, Golden rules 6-7) and inside render.md / aggregate.md. Fix is mechanical: copy the visible anchor into the URL.

2. Some action templates aren't paste-clean.
   The recommendation-rules table in render.md says "The action template must be a literal slash-command the maintainer can paste — never instructions like 'consider running …'". A few rules in the same table don't satisfy that:

   • Rule 1: /pr-triage all PR issues (focus on >4w bucket) — parenthetical
   • Rule 3: /pr-triage stale → sweep 1a — unicode arrow + prose
   • Rule 8: No immediate action — check next week. — not a command at all
   • Rule 10: review /pr-triage stale cadence — too many PRs reaching the sweep — prose

   For rules where there's genuinely no paste-action (rule 8), consider splitting action into two columns (action_command + note) or making action nullable so the renderer can present no-command rules differently (e.g. a different icon).

3. Mirror-PR reference.
   Body says "the same conceptual changes have been mirrored to the pr-management-stats skill in apache/airflow-steward (PR coming separately)". Per AGENTS.md "Tracking issues for deferred work", a link to the mirror PR (or a tracking issue) here would lock in the parity. The two skills are intentionally pinned via .apache-steward.lock in adopter repos, so anyone who adopts the framework version sees the dashboard exactly when both PRs land.

CI is green, the change is well-scoped, no architectural concerns. None of the above is blocking.

---

🤖 This review was drafted by an AI-assisted tool (Claude Opus 4.7) and may contain mistakes. An Apache Airflow maintainer has confirmed the review before posting; please flag anything that looks off.

Drafted-by: Claude Code (Opus 4.7); reviewed by @choo121600 before posting

[potiuk]

Should be resolved @choo121600

[choo121600]

Cool :>)

[github-actions]

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 167d7cc v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.