| name | personal-pr-triage |
| description | Automates the weekly PR triage for Flutter teams, following the standards in docs/triage/README.md. |
PR Triage Skill
This skill automates the weekly PR triage for Flutter teams, following the standards in docs/triage/README.md.
Workflow
1. Identify Team and Retrieve PR Lists
- Locate the team's PR queries in
docs/triage/README.md.
- Retrieve ALL open, non-draft PRs for the primary repository and any owned packages.
- For large volumes (e.g., >20 PRs), first fetch numbers to a file to avoid API timeouts:
gh pr list --search "[QUERY] -is:draft" --limit 200 --json number --jq '.[].number' > pr_numbers.txt
2. Fetch Detailed Audit Data
For each PR number, fetch comprehensive JSON. For large volumes, use a script to fetch individually or in smaller batches to avoid 502 errors.
- Required fields:
number,title,author,authorAssociation,isDraft,reviews,comments,reviewRequests,statusCheckRollup,updatedAt,reviewDecision,labels,url,commits.
- For smaller sets, a loop is fine:
echo "[" > audit_data.json
first=true
for num in $(cat pr_numbers.txt); do
if [ "$first" = true ]; then first=false; else echo "," >> audit_data.json; fi
gh pr view $num --json number,title,author,authorAssociation,isDraft,reviews,comments,reviewRequests,statusCheckRollup,updatedAt,reviewDecision,labels,url,commits >> audit_data.json
done
echo "]" >> audit_data.json
- For larger sets (>50 PRs), prefer a Python fetcher script.
3. Generate the Report
Run the bundled triage script to process the data and generate triage_report_pr_[TEAM].md.
python3 .agents/skills/personal-pr-triage/scripts/generate_triage_report.py [TEAM_NAME]
⚠️ Critical Verification Mandate (Zero-Trust)
- Succinct Formatting & Zero Redundancy: Keep reports extremely concise. Omit redundant bullet points where the section header already explains the action (e.g., under
Needs Initial Reviewer or Fix Review Feedback, do not repeat **To-do**: Assign reviewer or **To-do**: Author to address comments). Merge status and actions into a single bullet point per PR. Truncate long lists of failing CI checks (>3 checks) to keep reports scannable.
- Action Precision & Grouping:
- Author Actions Grouping: Group Author Actions (Action Required) into specific granular categories based on the action required:
🛑 Action Required: Fix Review Feedback (Changes requested by reviewers)
📝 Action Required: Sign CLA (Failing CLA check cla/google)
⚠️ Action Required: Fix CI (Failing functional CI checks, excluding CLA and freeze)
❄️ Action Required: Address Code Freeze Check (Failing code freeze checks)
💬 Action Required: Ping Author (Idle 14+ Days) (Idle, needs a first ping)
🔒 Action Required: Close PR (Idle 28+ Days) (Idle >28 days, needs closure)
⏳ Waiting on Author (Already Pinged) (Idle, already pinged)
- Google testing fail -> "Googler to assist".
- Stale + last comment is member ping -> Omit redundant todo bullets.
- Approved + Blocked CI -> "To-do: Nudge author (approved by @user)".
- Stale calculation: If the last activity was a member pinging the author, calculate the "stale days" from that ping.
- CI Requirement for Landing: Only list PRs in "Ready to Land" if CI is completely green.
- Deterministic Logic: Always use the provided Python script to ensure consistency across triage sessions.
- Embedded Link & Heading Standards: Heading level 3 (
###) must be the highest-level heading in the report (used for the title and main groups). Subgroups must use heading level 4 (####) with embedded links for section counts: #### [TITLE] ([COUNT](LINK)).
🛠 Useful Scripts
Fetch detailed state:
gh pr view [NUMBER] --json number,title,author,authorAssociation,isDraft,reviews,comments,reviewRequests,statusCheckRollup,updatedAt,reviewDecision,labels,url,commits