fix-pr-checks

name	fix-pr-checks
description	Fix PR metadata issues flagged by Danger (labels, milestones). Use when a PR fails danger/pr-check due to missing labels or milestones. Can be invoked standalone or by ci-monitor when it detects Danger failures.
allowed-tools	Bash(gh pr view *), Bash(gh pr checks *), Bash(gh api *), Bash(gh label list *), Bash(gh pr diff *), Read, Grep, Glob

Fix PR Checks

Automatically fix PR metadata issues flagged by Danger.

Prerequisites

Read agents/gh-reference.md for auth setup and token overrides before running any gh commands.

Arguments

$ARGUMENTS — one of:

• A PR URL: https://github.com/<owner>/<repo>/pull/<number>
• <owner>/<repo>#<number> or <owner>/<repo> <number>
• Just <number> (requires --repo context or current repo)

Step 1: Parse input

Extract owner/repo and PR number from $ARGUMENTS. If only a number is given, detect the repo from the current git remote.

Step 2: Fetch PR state and Danger feedback

Run in parallel:

• gh pr view <number> --repo <owner/repo> --json title,labels,milestone,baseRefName,body
• gh pr checks <number> --repo <owner/repo> to see if danger/pr-check failed
• gh api repos/<owner/repo>/issues/<number>/comments to read the Danger comment

Parse the Danger comment for actionable items. Known fixable issues:

• "PR requires at least one label"
• "PR is not assigned to a milestone"

Known non-fixable issues (report but skip):

• "This PR is larger than N lines" — mention it, move on

If there are no fixable issues, report that and stop.

Step 3: Determine the right label

Fetch available labels:

gh label list --repo <owner/repo> --limit 100 --json name --jq '.[].name'

Infer the label from the PR title, body, and diff:

• Project/build file changes → [Type] Tooling
• Bug fixes (title contains "fix", "bug", "crash") → [Type] Bug
• New features → [Type] Feature or [Type] Enhancement
• Dependency updates → Dependencies
• Documentation changes → documentation
• Refactoring → refactoring

If unsure, list the top 3 candidates and ask the user to pick.

Step 4: Determine the right milestone

Use the gh-infer-milestone script (on PATH via scripts/):

gh-infer-milestone <owner/repo> <base-branch>

Output is tab-separated: <milestone_number>\t<milestone_title>. Exit code 2 means ambiguous — ask the user.

If the script is unavailable, fall back to manual logic:

• Fetch open milestones: gh api repos/<owner/repo>/milestones?direction=asc&sort=due_date
• If the base branch is trunk/main/develop: pick the next open milestone with a due date (skip any milestone marked with frozen indicators like ❄️ or "frozen" in the title).
• If the base branch is release/*: pick the milestone matching the release version.
• If unsure, ask the user.

Step 5: Apply fixes

Use the GitHub API directly (not gh pr edit, which fails on repos with classic Projects):

Add label:

gh api repos/<owner/repo>/issues/<number>/labels -f "labels[]=<label>" --method POST

Set milestone:

gh api repos/<owner/repo>/issues/<number> -f milestone=<milestone_number> --method PATCH

Run both in parallel if both are needed.

Step 6: Verify

Fetch the PR state again to confirm:

gh api repos/<owner/repo>/issues/<number> --jq '{milestone: .milestone.title, labels: [.labels[].name]}'

Step 7: Report

Summarize what was fixed:

PR #42 — Add widget support

Fixed:
  label: [Type] Enhancement
  milestone: 1.2

Skipped:
  - Large diff warning (not fixable)

Danger should pass on next CI run.

Why gh api instead of gh pr edit

gh pr edit uses a GraphQL mutation that queries projectCards (classic Projects). Repos that ever had classic Projects enabled will fail:

Projects (classic) is being deprecated...

The REST API (gh api repos/.../issues/...) avoids this entirely.

Permissions

The label and milestone API calls are allowlisted in gh-api-guard.sh. No additional settings.json entries are needed beyond the existing Bash(gh api *).