review-open-prs

# Review Open PRs — Linear + GitHub Cross-Reference Execute the following steps to generate a comprehensive review of open PRs and their associated Linear issues. This command also forces GitHub's mergeable calculation and validates Greptile review scores. ## Usage ```bash claude /make-no-mistakes:review-open-prs # All repos in the current org claude /make-no-mistakes:review-open-prs my-repo # Filter to a specific repo claude /make-no-mistakes:review-open-prs mine # Only PRs authored by me ``` ## Step 0: Detect Organization and Repositories Detect the GitHub organization dynamically. Try these methods in order: **Method A** — Infer from the current repo: ```bash ORG=$(gh repo view --json owner --jq '.owner.login' 2>/dev/null) ``` **Method B** — Read from `linear-setup.json` if it exists at the repo root: ```bash ORG=$(cat linear-setup.json 2>/dev/null | jq -r '.github.org // empty') ``` **Method C** — If neither works, ask the user which org to scan. Once the org is known, discover repositories: ```bash REPOS=$(gh repo list "$ORG" --limit 50 --json name --jq '.[].name') ``` Also read the issue prefix from `linear-setup.json` if available: ```bash TEAM_PREFIX=$(cat linear-setup.json 2>/dev/null | jq -r '.team.key // empty') ``` If `TEAM_PREFIX` is empty, infer it from the Linear issues fetched in Step 1 (use the most common prefix). Store `ORG`, `REPOS`, and `TEAM_PREFIX` for use in subsequent steps. ## Step 1: Gather Linear Issues Assigned to Me Use the `mcp__linear-server__list_issues` tool to fetch all issues assigned to "me" that are in active states (not Done, not Cancelled). Use `includeArchived: false` and `limit: 100`. Store the results mentally — you'll need issue identifiers (e.g., `{TEAM_PREFIX}-123`), titles, states, priorities, and branch names. ## Step 2: Gather Open PRs Across All Org Repos For each repo discovered in Step 0, run: ```bash for repo in $REPOS; do echo "=== $repo ===" gh pr list --repo "$ORG/$repo" --state open --json title,number,url,headRefName,author,updatedAt,isDraft --limit 50 2>/dev/null done ``` If the user provided arguments, filter by those criteria: - `$ARGUMENTS` may contain a repo name (filter to that repo), a team name (filter Linear issues by team), or "mine" (filter PRs authored by me). ## Step 3: Force Mergeable Calculation on All My PRs GitHub calculates mergeability lazily — it only computes when requested. Force the calculation on ALL my open PRs by querying each one: ```bash # First pass: trigger calculation on all my PRs for pr_number in <list of my PR numbers>; do gh pr view "$pr_number" --repo "$ORG/<repo>" --json number,mergeable --jq '{number, mergeable}' 2>/dev/null & done wait ``` After the first pass, collect any PRs that returned `mergeable: "UNKNOWN"`. Wait 5 seconds, then retry those: ```bash sleep 5 # Second pass: retry UNKNOWN ones for pr_number in <UNKNOWN PR numbers>; do gh pr view "$pr_number" --repo "$ORG/<repo>" --json number,mergeable --jq '{number, mergeable}' 2>/dev/null done ``` If any still return `UNKNOWN` after the second pass, mark them as "calculating" in the report. ## Step 4: Fetch Greptile Scores and Review State for All My PRs For each of my open PRs, extract BOTH the Greptile confidence score AND the review state: **4a. Get the review state** (COMMENTED vs CHANGES_REQUESTED): ```bash for pr_number in <list of my PR numbers>; do state=$(gh api "repos/$ORG/<repo>/pulls/$pr_number/reviews" \ --jq '[.[] | select(.user.login | test("greptile"; "i")) | .state] | last' 2>/dev/null) echo "PR #$pr_number: $state" done ``` **4b. Get the confidence score and Path to 5/5**: ```bash for pr_number in <list of my PR numbers>; do echo "=== PR #$pr_number ===" # Greptile posts as greptile-apps[bot] in issue comments (not PR review comments) gh api "repos/$ORG/<repo>/issues/$pr_number/comments" \ --jq '.[] | select(.user.login | test("greptile"; "i")) | .body' 2>/dev/null done ``` Parse the score from the HTML tag: `<h3>Confidence Score: X/5</h3>` Parse the improvement suggestions from the section: `### Path to 5/5 Confidence` (everything between that heading and the next heading or end of comment). Classify each PR: - **5/5 + COMMENTED** — Greptile fully confident, ready to merge - **4/5 + COMMENTED** — Minor improvements suggested (extract Path to 5/5 items) - **3/5 or below** — Needs significant work (flag prominently) - **Any score + CHANGES_REQUESTED** — Greptile is blocking the PR, must address feedback before merge - **No score** — Greptile hasn't reviewed yet or check is still running ## Step 5: Fetch CI Status for All My PRs For each of my open PRs, get the full check status: ```bash for pr_number in <list of my PR numbers>; do echo "=== PR #$pr_number ===" gh pr view "$pr_number" --repo "$ORG/<repo>" \ --json statusCheckRollup --jq '[.statusCheckRollup[] | select(.name != null) | {name, status, conclusion}]' 2>/dev/null done ``` ## Step 6: Cross-Reference and Correlate Match PRs to Linear issues by: 1. **Branch name matching**: Linear issues often generate branches like `{TEAM_PREFIX}-123-feature-name`, `user/{TEAM_PREFIX}-123-slug`, or `user/{TEAM_PREFIX}-123-impl`. Match the issue identifier pattern (team prefix + number, case-insensitive) in the PR's `headRefName`. 2. **Title matching**: Some PRs reference the Linear issue ID in the title (e.g., "[{TEAM_PREFIX}-123] Fix bug" or "({TEAM_PREFIX}-123)"). Classify each PR into one of these categories: - **Linked to my Linear issue**: PR branch/title matches one of my assigned issues - **My PR, no Linear issue**: PR authored by me but no matching Linear issue found - **Other team PRs**: PRs by other authors (summarize briefly) ## Step 7: For Linked PRs, Get Detailed Issue Context For each PR that matches one of my Linear issues, use `mcp__linear-server__get_issue` to get: - Current state and priority - Labels and project - Any blocking relations (`includeRelations: true`) ## Step 8: Generate the Report Present the report in this format: ### My PRs — Ready to Merge PRs where: all CI green + mergeable=MERGEABLE + Greptile (4/5 or 5/5) + review state is NOT CHANGES_REQUESTED: ``` PR #number — Title Greptile: X/5 (COMMENTED) | Mergeable: MERGEABLE | CI: all green Linear: ISSUE-ID (State, Priority) URL ``` ### My PRs — Greptile Below 5/5 (Action Items) PRs with Greptile score < 5/5 but NOT blocked by other issues. For each, show the "Path to 5/5" items: ``` PR #number — Title — Greptile: X/5 Path to 5/5: - [ ] item 1 from Greptile - [ ] item 2 from Greptile CI: status | Mergeable: status URL ``` ### My PRs — Greptile CHANGES_REQUESTED PRs where Greptile's review state is `CHANGES_REQUESTED` (blocking review). These MUST be addressed before merge regardless of score: ``` PR #number — Title — Greptile: X/5 (CHANGES_REQUESTED) Greptile feedback summary: key concerns from the review URL ``` ### My PRs — Merge Conflicts / Needs Rebase PRs where mergeable=CONFLICTING: ``` PR #number — Title Conflict with: identify likely conflicting PR if possible (e.g., same domain/files) URL ``` ### My PRs — Stale Branches (Drift Risk) PRs where the branch is >5 commits behind base AND has ANY failing CI check. These are likely failing because the base moved (e.g., a test file was moved/renamed in a merged PR but this branch still has the old path). Recommend a preventive rebase BEFORE more CI cycles burn. **Investigate this section BEFORE the "CI Failures" section below** — stale-with-CI-fail is a likely false positive that can be resolved with a 30-second rebase. Pulling apart real test bugs from drift-induced failures is much faster when you've already ruled out drift. For each candidate PR, collect the behind-by count using the GitHub Compare API (one call per PR; do this inside the per-PR loop in Step 5): ```bash # Inside the per-PR loop in Step 5 — after fetching CI status: base_branch=$(gh pr view "$pr_number" --repo "$ORG/<repo>" --json baseRefName --jq '.baseRefName') head_sha=$(gh pr view "$pr_number" --repo "$ORG/<repo>" --json headRefOid --jq '.headRefOid') behind=$(gh api "repos/$ORG/<repo>/compare/${base_branch}...${head_sha}" --jq '.behind_by' 2>/dev/null) ``` A PR qualifies for this section if: - `behind` > 5, AND - At least one CI check has `conclusion=FAILURE` Format: ``` PR #number — Title — {behind} commits behind {base} Failed checks: list of failed check names Suggested: git fetch && git rebase origin/{base} && git push --force-with-lease URL ``` If you can pattern-match the failing test path against files renamed in recent commits to `{base}` (e.g., `gh api repos/$ORG/<repo>/compare/${head_sha}...origin/${base_branch}` and grep `.files[].previous_filename`), call that out as "Likely cause: file renamed in merged PR #X". ### My PRs — CI Failures PRs with any check conclusion=FAILURE that are NOT already listed under "Stale Branches" above: ``` PR #number — Title Failed checks: list of failed check names URL ``` ### My Issues WITHOUT Open PRs List assigned issues that have NO matching open PR (these may need attention): ``` [PRIORITY] ISSUE-ID: Issue Title — State ``` ### Other Open PRs (by repo) Group remaining PRs by repository, showing: ``` repo-name #number — Title (author, updated X ago) — URL ``` **Note:** Do NOT include subtotals next to repo names or a summary dashboard. Keep the report clean and actionable. ## Step 8b: Send Slack Report (automatic) After generating the report, ALWAYS send a summary to the user via Slack MCP using `mcp__claude_ai_Slack__slack_send_message`. This is NOT optional — it happens automatically as part of the command execution. Do NOT ask the user whether to send it. Send the message to the user's configured status channel. If `linear-setup.json` contains a `slack.statusChannel` field, use that channel. Otherwise, ask the user which channel to send to on the first run, then remember it for the session. The message uses the Slack Report Format defined in Step 9 below. Include ALL open PRs across the org (not just mine), grouped by repo, in the section order: Merged > CI Failures > Merge Conflicts. If no PRs were merged this session, omit the Merged section. --- ## Step 9: Suggested Course of Action After generating the report, present a numbered action plan. Each action is a concrete batch operation the user can approve or skip. Use the exact PR numbers and repos from the data collected above. ### Action 1: Merge all ready PRs List every PR from "Ready to Merge" as a batch merge command. Present them in dependency order (if PR A's branch was cut from PR B's branch, merge B first). If no dependencies, order by PR number ascending. ``` The following PRs have all CI green, are mergeable, and Greptile 4/5+: repo#number — Title repo#number — Title ... Shall I merge all of them now? (yes/no/pick) ``` If the user says "yes", execute for each PR: ```bash gh pr merge <number> --repo "$ORG/<repo>" --squash --delete-branch ``` If the user says "pick", ask which ones to merge. **Slack Report Format (sent automatically):** Header: `:github-pr: *Open PR Review - YYYY/MM/DD*` Sections (in this exact order, per repo, separated by `---`): 1. `:github-merged:` *Merged* — PRs that were merged during this session (Action 1 results) 2. `:github-actions-failure:` *CI Failures* — PRs with failing checks 3. `:github-closed:` *Merge Conflicts* — PRs that need rebase Each PR entry uses 3 levels of `-` (regular dash, NOT unicode bullets): ``` - :github-pr: <PR_URL|PRXXX> | <@SLACK_USER_ID> | Title - `branch-name` · :status_emoji: Status | :ci_emoji: CI · :greptile: X/5 - *RECOMMENDATION:* Actionable recommendation ``` Rules: - NO subtotals next to repo names (not "REPO-NAME (5 PRs)") - NO summary dashboard at the bottom - NO "Ready to Merge" section — those should already be merged in Action 1. If any remain unmerged (user declined), list them under a `:github-merge-approved: *Pending merge*` section - Use `:github-merged:` (not `:merged:`) for merge-related headers - Link Linear issues when available: `<https://linear.app/{LINEAR_WORKSPACE}/issue/{ISSUE_ID}|{ISSUE_ID}>` - If unsure who to CC, ask the user - Do NOT use unicode bullet points (no `•`, `◦`, `▪`) — use `-` at all levels ### Action 2a: Rebase stale branches (drift risk) List every PR from "Stale Branches (Drift Risk)". These should be addressed BEFORE Action 3 (CI Failures) because the rebase often resolves the failures for free: ``` The following PRs are >5 commits behind base AND have failing CI. The failures are likely caused by the base moving (e.g., a test file was renamed in a merged PR). A rebase will likely make them go green: repo#number — Title — {N} commits behind {base} ... Shall I rebase them against the base branch? (yes/no/pick) ``` If the user says "yes", for each stale PR: 1. Check out the branch locally or in a worktree 2. `git fetch origin <base>` 3. `git rebase origin/<base>` (auto-resolve trivial conflicts; flag manual ones) 4. `git push --force-with-lease` (with user confirmation) 5. Re-poll CI after a few minutes — if it's now green, the failure was drift; if it's still red, escalate to Action 3. ### Action 2: Fix merge conflicts / rebase List every PR from "Merge Conflicts / Needs Rebase": ``` The following PRs have merge conflicts: repo#number — Title (likely conflicts with #other) ... Shall I rebase them against the base branch? (yes/no/pick) ``` If the user says "yes", for each conflicting PR: 1. Check out the branch locally or in a worktree 2. Rebase against the base branch 3. Resolve conflicts if possible (or flag for manual resolution) 4. Force-push the rebased branch (with user confirmation) **Smart suggestions**: When a conflicting PR also has CI failures, or is part of a dependency chain where another PR has CI failures, proactively suggest "rebase + fix" as a combined option instead of presenting them as separate actions. Example: "PR #X has a merge conflict AND #Y (its dependency) has CI failures. Shall I rebase + fix both? (rebase+fix / rebase-only / skip)" ### Action 3: Fix CI failures List every PR from "CI Failures": ``` The following PRs have failing checks: repo#number — Title Failed: check-name-1, check-name-2 ... Shall I investigate and fix the failures? (yes/no/pick) ``` If the user says "yes", for each PR: 1. Fetch the failing check logs: `gh run view <run-id> --repo "$ORG/<repo>" --log-failed`