this is to analyze the PRs and solve the requested changes in them
AI Summary
Analyze and resolve GitHub PR review comments by fetching suggestions, planning fixes, applying code changes, running tests, and updating the PR. Use this when you need to systematically address reviewer feedback and ensure all suggestions are properly handled.
Analyze and Resolve Suggested Changes in GitHub Pull Request
Follow these steps to analyze suggested changes (e.g., review comments, inline suggestions, or requested modifications) in a GitHub Pull Request (PR) and resolve them efficiently. The goal is to review, understand, plan fixes, apply changes, test, and update the PR while maintaining code quality and collaboration.
Assume the PR reference is provided as $ARGUMENTS (e.g., a PR number or URL like #456 or https://github.com/repo/pull/456).
Use the GitHub CLI (gh) for all GitHub-related tasks, such as fetching PR details, comments, and updating the PR.
PLAN
Use gh pr view to get the PR details
Fetch the full PR title, description, base branch, head branch, labels, assignees, reviewers, and any linked issues.
Note the current status (e.g., open, draft, merged) and any merge conflicts.
Fetch and review all comments and suggestions
Use gh pr comment list or gh api to retrieve all review comments, including inline suggestions (e.g., code diffs suggested in reviews).
Categorize comments:
Suggestions for code changes (e.g., "Change this function to use async/await").
Questions or clarifications (e.g., "Why did you choose this approach?").
Bugs or issues (e.g., "This breaks on edge case X").
Style/nitpicks (e.g., "Rename variable for clarity").
Approvals or general feedback.
Identify threaded discussions or resolved/unresolved comments.
Identify related dependencies or context
Look for linked issues or other PRs (e.g., "fixes #123" or "depends on #789").
Check if the PR is part of a larger epic, feature branch, or release.
Review the diff: Use gh pr diff to understand the changes introduced in the PR.
If suggestions reference external resources (e.g., docs, standards), verify them.
Ask clarification questions if needed
If a suggestion is ambiguous, prepare questions for the reviewer (e.g., post them as replies in the PR).
Examples: "Can you provide an example of the expected output?" or "Does this need to handle internationalization?"
Understand prior art and codebase impact
Search the codebase for affected files/modules (e.g., use git grep or IDE search).
Review commit history in the PR branch for context.
Check for similar past PRs or issues resolved in the repo.
Ultrathink about resolving suggestions in a small and manageable way
Break down each suggestion into actionable fixes.
Prioritize: Address blockers first (e.g., bugs > features > style).
Sequence fixes logically (e.g., refactor code before adding tests).
Consider edge cases, performance, security, and compatibility.
Draft a plan that minimizes new changes and avoids introducing regressions.
Document the plan in the scratchpad
Include the PR title and link.
List suggestions with proposed resolutions.
Ensure the plan is structured for easy execution by humans or automation.
Scratchpad for PR Resolution Planning
Pull Request Details
Title: <Copy from GitHub PR title>
Link: <Paste GitHub PR link>
Description: <Paste or summarize the PR description here>
Base Branch: <e.g., main>
Head Branch: <e.g., feature/new-auth>
Linked Issues: <List any referenced issues, e.g., #123>
Suggested Changes / Comments
Document each comment or suggestion here, grouped by file or category.
Include commenter, comment text, and inline diff if applicable.