Monitor Stack Reviews

---
description: Monitor a Graphite PR stack through Greptile 5/5, ready-for-ci labeling, and CI.
argument-hint: [pr-or-range-or-branch]
---

# Monitor Stack Reviews

Usage: `/monitor-stack-reviews <pr-or-range-or-branch>`

Arguments:

```text
$ARGUMENTS

Goal

Monitor every PR in an existing Graphite stack, inspect Greptile feedback, fix actionable review findings, add the ready-for-ci label only after Greptile is 5/5, and keep monitoring CI until every non-deferred stack PR is ready for final human review.

Rules

• Use Graphite for stack operations. If gt is missing or unauthenticated, stop and report the blocker instead of falling back to raw branch surgery.
• Use gh for GitHub PR metadata, checks, draft/ready state, and review comments. Run gh auth status before network operations. If gh is missing or unauthenticated, stop and report the blocker instead of treating GitHub command failures as PR state.
• Never merge PRs unless the requester explicitly asks.
• Do not create worktrees, create implementation branches, open new feature PRs, or convert draft PRs to ready. This command is for monitoring and fixing an existing PR/stack. Use /worktree-pr-monitor for the implementation stage.
• Do not add ready-for-ci before the latest trusted Greptile review for that PR is 5/5. There is no command-level override for this gate.
• If the ready-for-ci label is missing from the repository, stop and report the blocker instead of creating a label silently.
• Never force-push over remote work outside Graphite-managed stack branches unless the requester explicitly approves that exact risk. Graphite restacks necessarily rewrite stack branch SHAs; they are permitted only after verifying the branch is part of the requested stack and the remote head still matches the head observed before editing/submitting.
• Keep fixes in the relevant stack layer. If a finding belongs to a lower PR, check out that branch, patch there, amend or commit with Graphite, then restack descendants.
• Treat unresolved human review threads, Codex review comments, and Greptile findings as blockers until fixed, acknowledged, or explicitly deferred.
• Do not repeatedly ping Greptile. Wait for new reviews triggered by pushed commits and poll status/comments instead.
• Do not stage unrelated files. Run git status --short --branch before every staging operation.

Workflow

1. Resolve the stack.

   • If $ARGUMENTS contains a PR number/range, inspect those PRs with gh pr view.
   • If $ARGUMENTS contains a branch, use gt log short and gh pr list --head.
   • If no arguments are provided, use the current branch and gt log short.
   • Produce an ordered list of PR number, branch, base, draft state, and URL.

2. Validate reviewability.

   • If any PR is still draft, report that Greptile may not run for that PR until a human or a separate explicit action marks it ready. Do not convert it from this command. Continue monitoring and fixing the remaining non-draft PRs in stack order; keep each draft PR listed as a blocker in the final status.
   • Always keep the PR order intact, regardless of draft state. Do not alter bases manually unless Graphite reports the stack is malformed.

3. Monitor Greptile and reviews first.

   • Inspect PR review threads with a thread-aware GitHub workflow, not only flat issue comments.
   • Inspect Greptile comments/status. Record the latest trusted Greptile rating per PR, especially whether it is 5/5.
   • Audit existing ready-for-ci labels before any fixes. For each monitored PR, compare the label state with the latest Greptile review and current headRefOid; also inspect unresolved human review threads, unresolved Codex review comments, and unresolved actionable issue comments. Remove ready-for-ci immediately if the PR is draft, if the label is not backed by a current-head 5/5 review, or if any unresolved review blocker is present: gh pr edit <number> --remove-label "ready-for-ci".
   • Do not treat CI as the primary gate until Greptile has reached 5/5 for the PR. If CI is already running, record status but keep Greptile first.
   • Before each edit/submit iteration, snapshot the current remote head for every PR that could be rewritten by the next Graphite submit: gh pr view <number> --json headRefOid,headRefName. Keep this baseline with the branch list for the Step 4 conflict check.

4. Fix actionable feedback.

   • Cluster findings by branch and behavior.
   • Before editing any file, verify the checked-out branch matches the PR branch that owns the fix: run git branch --show-current and compare it to the target PR's headRefName. If it differs, run gt checkout <target-branch> and re-check the branch before editing.
   • For code behavior changes, add or adjust a focused failing regression before the implementation change. Do not edit behavior code until the regression exists. For docs-only fixes, keep the edit scoped to the reviewed workflow.
   • Before any edit that will lead to a new push for a PR that currently has ready-for-ci, remove the label from that PR and every descendant PR whose head will be rewritten by the next gt submit --stack: gh pr edit <number> --remove-label "ready-for-ci". Re-add labels only after fresh current-head Greptile reviews return 5/5.
   • Run the narrow relevant tests after the fix. Before staging or committing, also run git diff --check, bun run typecheck, bun run check:patterns, and bun run test. If an external outage or existing repo-wide blocker makes a mandatory gate impossible to complete, stop and report the exact blocker instead of committing or submitting.
   • If any React .tsx or .jsx file changed, run this gate before staging or committing: npx react-doctor@latest <project-dir> for