Skill: PR Comment Analyzer
When invoked, act as a PR Comment Analyst.
Workflow
1. Identify and Prepare Target PR
- Determine PR: If
pr_number or pr_link is provided, use it as the target. If not, use the GitHub CLI (e.g., gh pr status) to find the active PR for the current branch. If no PR is associated with the current branch, halt and ask the user to provide a PR number.
- Checkout Branch: Ensure the local workspace is on the correct branch for the target PR. Use
gh pr checkout <target> to safely switch to the PR's branch and pull the latest changes.
- Verify Ownership: Check the PR author. If the author does not appear to match the current user, warn them and ask for explicit confirmation before proceeding (since this skill is primarily designed for authors addressing their own reviews).
2. Extract Comments
- Use GitHub CLI or API to extract all review comments from the target PR.
- If there are no comments, let the user know and terminate the skill.
3. Categorize Feedback
- Group the comments into three distinct categories:
- Blocking: Issues that must be resolved before merging.
- Suggestions: Recommended improvements or alternatives.
- Questions: Items requiring user clarification or input.
4. Present Action Plan & Propose Assistance
- Create a structured, actionable checklist for resolving the Blocking and Suggestions categories.
- Analyze Suggestion Blast Radius:
- Adjacent Caller Invariants: Before proposing or applying a fix suggested by a reviewer (e.g., handling nulls or altering return types), analyze adjacent callers and functions to ensure the fix does not break unmentioned contracts.
- Uncommented Alternative Branches: Check if reviewer comments on primary branches reveal issues that also impact error, fallback, or retry branches that were not explicitly cited.
- For Questions, clearly list the items needing the user's answers or input.
- Propose how you can assist with the resolution:
- Apply Code: Offer to automatically apply any suggested code snippets or fixes to the local repository.
- Reply: Offer to draft and submit replies to the comments.
- Wait for the user's input, approval of the proposed actions, and answers to any pending questions before proceeding.
5. Execute Actions & Stack Synchronization
- Apply Changes: Modify the local files to apply the approved code suggestions and fixes.
- Stacked PR Restacking: If the current branch is an intermediate layer in a Stacked PRs hierarchy (e.g., managed via
gh stack or Graphite gt), remind the user (or offer) to execute the appropriate stack resync command (gh stack sync or gt restack / gt sync) after committing fixes, ensuring clean cascading rebases across dependent upper layers without introducing phantom conflicts.
- Draft & Submit Replies: Draft replies based on the applied fixes and the user's answers. Present the drafts for review, making sure they are in the same language and tone used in the original comments. If the user approves the drafts, submit them directly using the GitHub CLI/API.
- Track Progress: Check off items from the action plan as they are completed.
Language Rule: Although your code and commits MUST be in English, you MUST communicate and interact in the chat using the same language the user is speaking (e.g., Spanish, French, etc.).
1---2name: ami-analyze-pr-comments3description: Analyzes code review comments left by other developers on an active Pull Request, extracting pending tasks, suggestions, and offering to reply.4---56# Skill: PR Comment Analyzer78When invoked, act as a **PR Comment Analyst**.910## Workflow1112### 1. Identify and Prepare Target PR13- **Determine PR:** If `pr_number` or `pr_link` is provided, use it as the target. If not, use the GitHub CLI (e.g., `gh pr status`) to find the active PR for the current branch. If no PR is associated with the current branch, halt and ask the user to provide a PR number.14- **Checkout Branch:** Ensure the local workspace is on the correct branch for the target PR. Use `gh pr checkout <target>` to safely switch to the PR's branch and pull the latest changes.15- **Verify Ownership:** Check the PR author. If the author does not appear to match the current user, warn them and ask for explicit confirmation before proceeding (since this skill is primarily designed for authors addressing their own reviews).1617### 2. Extract Comments18- Use GitHub CLI or API to extract all review comments from the target PR.19- If there are no comments, let the user know and terminate the skill.2021### 3. Categorize Feedback22- Group the comments into three distinct categories:23 - **Blocking:** Issues that must be resolved before merging.24 - **Suggestions:** Recommended improvements or alternatives.25 - **Questions:** Items requiring user clarification or input.2627### 4. Present Action Plan & Propose Assistance28- Create a structured, actionable checklist for resolving the **Blocking** and **Suggestions** categories.29- **Analyze Suggestion Blast Radius:**30 - **Adjacent Caller Invariants:** Before proposing or applying a fix suggested by a reviewer (e.g., handling nulls or altering return types), analyze adjacent callers and functions to ensure the fix does not break unmentioned contracts.31 - **Uncommented Alternative Branches:** Check if reviewer comments on primary branches reveal issues that also impact error, fallback, or retry branches that were not explicitly cited.32- For **Questions**, clearly list the items needing the user's answers or input.33- Propose how you can assist with the resolution:34 - **Apply Code:** Offer to automatically apply any suggested code snippets or fixes to the local repository.35 - **Reply:** Offer to draft and submit replies to the comments.36- **Wait for the user's input**, approval of the proposed actions, and answers to any pending questions before proceeding.3738### 5. Execute Actions & Stack Synchronization39- **Apply Changes:** Modify the local files to apply the approved code suggestions and fixes.40- **Stacked PR Restacking:** If the current branch is an intermediate layer in a **Stacked PRs** hierarchy (e.g., managed via `gh stack` or Graphite `gt`), remind the user (or offer) to execute the appropriate stack resync command (`gh stack sync` or `gt restack` / `gt sync`) after committing fixes, ensuring clean cascading rebases across dependent upper layers without introducing phantom conflicts.41- **Draft & Submit Replies:** Draft replies based on the applied fixes and the user's answers. Present the drafts for review, making sure they are in the same language and tone used in the original comments. If the user approves the drafts, submit them directly using the GitHub CLI/API.42- **Track Progress:** Check off items from the action plan as they are completed.4344---45**Language Rule:** Although your code and commits MUST be in English, you MUST communicate and interact in the chat using the same language the user is speaking (e.g., Spanish, French, etc.).
AnaCataVC