---
name: implement-pr-comments
description: Fetch unresolved PR review comments, implement code changes, verify with dbt, and reply to reviewers.
disable-model-invocation: true
argument-hint: "<branch_name_or_pr_number>"
---

Implement review comments on a GitHub PR. The branch name or PR number is provided as argument: $ARGUMENTS

If no argument is provided, use the current branch to find the PR.

## Steps

1. **Find the PR**: Use `gh pr list --head <branch>` or `gh pr view <number>` to identify the PR.
2. **Fetch all review comments**: Use `gh api repos/{owner}/{repo}/pulls/{number}/comments` to get inline comments (full body, author, path, line, id). Also fetch issue-level comments with `gh pr view --json comments`.
3. **Triage comments**: Separate comments into **resolved** and **unresolved**. A thread is resolved only if the **last** reply is from the PR author; if a reviewer replied after the PR author, the thread is unresolved again. Present only unresolved comments grouped by file, showing author, severity (if tagged with [Blocking]/[Non-Blocking]), and content. Mention resolved comment count for context but don't list them individually.
4. **Classify unresolved comments**: For each unresolved comment, classify as:
   - **Code change** — requires modifying a file
   - **Data question** — requires querying a database or inspecting data to answer
   - **Discussion/informational** — no action needed, just needs a reply
   If all unresolved comments are data questions or discussions (no code changes needed), skip straight to step 8.
5. **Handle data questions**: If any comment requires querying data to answer, present the query to the user and ask them to run it. Use their results to inform your reply in step 8.
6. **Prepare the branch** (only if code changes are needed):
   - Checkout the PR branch if not already on it
   - Pull latest changes on the branch
   - Pull latest main and check for merge conflicts with the PR branch
   - If conflicts exist, report them to the user before proceeding
7. **Plan and implement code changes**: For each actionable code comment, explain what change is needed. Clarify any ambiguous feedback with the user before proceeding. Apply the requested changes — always follow the project's style guide and conventions (check CLAUDE.md and the Gemma Analytics SQL style guide at https://github.com/Gemma-Analytics/gemma-sql-style). Read the full style guide before writing SQL.
8. **Verify** (only if code changes were made): Activate the dbt venv, then run `dbt compile` on changed models to verify SQL syntax. Then run `dbt build` on changed models and their downstream dependents to verify they build and tests pass.
9. **Reply to PR comments**: Before posting any replies, present ALL draft replies to the user for review and wait for approval. **Keep replies tight — default to 1-2 sentences. Maximum three sentences unless the reviewer explicitly asked for reasoning.** State the outcome, skip preamble ("good call", "great question", restating the reviewer's point), skip options/trade-off breakdowns, skip recapping decisions you've already explained to the user in chat. PR threads are for colleagues skimming a review, not for walkthroughs. Concrete examples:
   - Straightforward fix: `done :)`
   - Change with a reason: `Changed to X — Y reason.` (one sentence)
   - Question/discussion: answer in 1-2 sentences; offer a follow-up PR rather than expanding scope here.
   Once the user approves (or adjusts), post replies via `gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies`.
10. **Commit and push**: Stage changed files, commit with a descriptive message summarizing the review feedback addressed, and push to the remote branch.
11. **Update the PR description if changes have made it stale**: After committing and pushing, re-read the PR description (`gh pr view <number> --json body`). If any portion describes the OLD implementation (CTE names, approach, behavior, file paths, validation numbers, test counts) rather than the shipped code, update the description via `gh api -X PATCH /repos/{owner}/{repo}/pulls/{number} --field body=<new_body>` — `gh pr edit` silently fails on some orgs. Verify with `gh pr view <number>`. Reviewers will notice when the description and the code disagree; keep them in sync as part of every revision round.

## Important

- Always read the full file before editing — understand context around the commented lines.
- Re-fetch comments if the review may have been updated since the initial fetch.
- If a comment is unclear or contradictory, ask the user before implementing.
- Never force-push or amend existing commits — always create new commits.
- Activate the project's dbt virtual environment before running any dbt commands. Common locations: `dbt-env/`, `.venv/`, `venv/` — check which exists in the project root.
- **Validation / data-inspection queries target the dev schema, not production.** When presenting SQL for the user to run (to confirm a fix, count NULLs, audit values, etc.), reference the dev dataset the user just built into — e.g. `dev_<name>_base.<model>` — never `analytics_base.<model>`. The user will not have just materialized the fix into production; the dev dataset is where `dbt build` wrote the updated table. Infer the dev schema prefix from the dbt build output lines (`dev_<name>_<layer>.<model>`) or from `~/.dbt/profiles.yml`. Only reference `analytics_*` if the user explicitly asks about production state.