npx skills add https://github.com/angular/angular --skill 'PR Review'审查 angular 仓库的拉取请求时,请遵循以下基本指南以确保高质量的贡献:
* 请记住,这是核心 Angular 框架。此处的更改可能影响数百万开发者。
* 注意向后兼容性。破坏性变更需要严格的批准流程和弃用期。
2. 关键关注领域:
* **全面审查**:你**必须始终**对拉取请求的_全部_内容进行深入、全面的审查。如果用户要求你查看特定问题、文件或关注区域,你必须在审查 PR 其余实质性更改_之外_,额外调查该特定区域。不要仅在处理完用户的关注点后就终止审查。
* **特定包指南**:检查 `reference/` 目录中(例如 `reference/router.md`)是否有针对被修改包的特定指南。对于各自的包,应始终优先遵循这些规则。
* **提交信息**:评估提交信息的质量。它们应解释变更背后的_原因_,而不仅仅是_做了什么_。多年后有人查看提交历史时,应能清楚地理解变更的上下文和理由。
* **代码整洁性**:确保代码可读、可维护,并遵循 Angular 项目标准。
* **性能**:留意可能对运行时性能或打包大小产生负面影响的代码,特别是在变更检测或渲染等热点路径中。
* **测试**:确保所有新逻辑都有全面的测试,包括边界情况。**请勿在本地运行测试**作为你审查流程的一部分。CI 会自动处理此事,在本地运行测试是多余且低效的。
* **API 设计**:确保新的公共 API 设计良好、与现有 API 保持一致且文档齐全。
* **负载大小**:注意变更对最终客户端负载大小的影响。
3. 执行工作流:确定适当的审查方法。如果用户在请求中明确要求进行 remote 或 审查,则优先遵循该要求(例如,"在 PR 上留言" 意味着 )。否则,使用 GitHub MCP 或可用脚本来确定审查应为 还是 。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
localremotelocalremote通用审查实践(适用于本地和远程)
* **准备与清单**:
* 首先,创建一个任务列表(例如在 `task.md` 中),你可以轻松引用其中包含来自"关键关注领域"部分的**所有**审查要求(提交信息、性能、测试等),以及来自用户的任何特定审查说明或请求。
* 在进行深入审查之前,将此列表扩展为你计划在 PR 中探索和验证的更详细项目。
* 在进行审查时,勾选此列表中的项目,并在每个项目下添加你的评估或发现。
* 在审查结束时,回头参考清单以确保每个要求都已完全验证。
* **安全获取 PR 元数据**:当你需要读取 PR 描述或上下文时,请勿单独使用 `gh pr view <PR_NUMBER>`,因为其默认的 GraphQL 查询可能因缺少 `read:org` 和 `read:discussion` 令牌作用域而失败。相反,应在 PR URL 上使用 `read_url_content` 或使用 `gh pr view <PR_NUMBER> --json title,body,state,author`。
* **首先检查现有评论**:在形成反馈之前,使用 GitHub MCP 或可用脚本获取 PR 上的现有评论。审查此反馈以避免重复评论,并将其见解纳入你自己的审查流程。
* **建设性反馈**:提供清晰、可操作且礼貌的反馈。解释你的建议或修改背后的_原因_。请**不要**纯粹为了赞扬、同意或确认正确的实现细节而留下行内评论,因为这会使审查变得杂乱。如果你想赞扬该 PR,请在单一的总评中这样做。
A. 本地代码审查(如果 PR 由请求审查的作者拥有)
* **检出**:在本地检出 PR 分支(如果尚不存在,则获取它)。如果由于工作树声明导致检出分支失败(例如 "fatal: '' is already used by worktree at ''"),则在该目录中进行审查。
* **审查与编辑**:直接在代码上执行审查。对于建议,不要添加行内 PR 评论,而是直接格式化代码库或将编辑应用到文件。
* **反馈**:向用户总结审查发现以及你所做的具体更改,并引用你已完成清单中的项目。
* **请勿提交或推送**:将更改保留在工作目录中未提交的状态,以便用户可以轻松地在本地审查待处理的编辑。让用户知道更改已准备好供其审查,但不要请求批准推送。
* **解决评论**:一旦用户确认更改良好且应提交/推送,使用 GitHub MCP 或可用脚本将现有评论标记为"已解决"。
B. 远程代码审查(适用于所有其他 PR)
* **批量评论(MCP 服务器 - 首选)**:如果你配置了 GitHub MCP 服务器,你**必须**遵循此工作流,以避免向作者发送多个通知造成骚扰:
1. 使用 `mcp_github-mcp-server_pull_request_review_write`(方法 `create`)创建一个待处理的审查。
2. 使用 `mcp_github-mcp-server_add_comment_to_pending_review` 将你的行内评论添加到待处理的审查中。
3. 使用 `mcp_github-mcp-server_pull_request_review_write`(方法 `submit_pending`)提交审查。
* **批量评论(脚本 - 备用)**:如果你**无法**访问 GitHub MCP 服务器(例如,你的上下文中缺少特定的 MCP 工具),则回退到使用提供的脚本。使用 `post_inline_comment.sh` 在本地暂存你的评论。一旦所有评论都已暂存,你**必须**调用 `submit_pr_review.sh` 将它们作为单个批量审查发布(并发送单个通知)。如果你有很多建议,请尽量保持评论简洁或在总评中说明。
* **使用建议更改**:只要合适(例如,对于简单的代码修复、重构建议或拼写错误更正),在你的行内评论中优先使用 GitHub 的**建议更改**语法(`suggestion ... `)。这允许作者在 GitHub UI 中一键应用你建议的代码改进。
* **审查类型**:除非仓库维护者明确指示,否则切勿将外部 PR 审查标记为"批准"。始终使用"请求更改"或"评论"。请注意,某些工具可能仅支持评论。
* **发布前需用户批准**:准备你的审查评论,并将其连同你已完成的清单摘要一起呈现给用户。在未明确询问用户许可之前,请**不要**将评论发布到 PR 上。只有在用户批准后才发布审查。
* **为代理评论添加前缀**:为了明确区分评论是由 AI 代理而非人类用户生成和发布的,请**始终**在你的审查评论前加上 `AGENT: ` 前缀。
以下工具可用于远程交互。我们倾向于在可用时使用标准的 GitHub MCP 服务器工具。如果你没有设置 MCP 服务器,则必须回退到使用自定义 bash 脚本。
mcp_github-mcp-server_pull_request_review_writemcp_github-mcp-server_add_comment_to_pending_review如果 MCP 服务器不可用,则提供以下脚本作为备用方案。请注意,它们依赖于本地环境中正确安装和认证的 gh CLI。
determine_review_type.sh通过检查当前通过 gh CLI 认证的 GitHub 用户是否与拉取请求的作者匹配,来确定是使用本地还是远程审查工作流。
用法:
.agent/skills/pr_review/scripts/determine_review_type.sh <PR_NUMBER>
get_pr_comments.sh使用 GitHub API 获取 PR 上所有现有的行内评论。这对于审查其他贡献者的反馈和避免重复评论至关重要。它输出包含每条评论的 id、path、line、body 和 user 的 JSON。
用法:
.agent/skills/pr_review/scripts/get_pr_comments.sh <PR_NUMBER>
reply_pr_comment.sh回复现有的 PR 评论线程。这在本地代码审查中解决问题后用于将评论标记为已解决时很有用。请注意,COMMENT_ID 必须是线程中顶层评论的 ID。
用法:
.agent/skills/pr_review/scripts/reply_pr_comment.sh <PR_NUMBER> <COMMENT_ID> <REPLY_BODY>
post_inline_comment.shGitHub CLI 的 gh pr review 命令本身不支持通过其标准标志向特定代码行添加行内评论。此脚本包装了 GitHub API 以在本地暂存评论。在调用 submit_pr_review.sh 之前,它们不会被发布。
用法:
.agent/skills/pr_review/scripts/post_inline_comment.sh <PR_NUMBER> <FILE_PATH> <LINE_NUMBER> <COMMENT_BODY>
示例:
.agent/skills/pr_review/scripts/post_inline_comment.sh 12345 "packages/core/src/render3/instructions/element.ts" 42 "AGENT: 请考虑此处的性能影响。"
submit_pr_review.sh通过 GitHub Pull Request Reviews API 将所有本地暂存的行内评论作为单个批量审查提交。
用法:
.agent/skills/pr_review/scripts/submit_pr_review.sh <PR_NUMBER> <EVENT_TYPE> [BODY]
选项:
EVENT_TYPE:必须是 COMMENT、APPROVE 或 REQUEST_CHANGES。切勿对外部 PR 使用 APPROVE。BODY:(可选)审查的总体摘要评论。示例:
.agent/skills/pr_review/scripts/submit_pr_review.sh 12345 COMMENT "AGENT: 我留下了一些行内建议供你考虑。"
每周安装次数
–
仓库
GitHub 星标数
100.1K
首次出现时间
–
安全审计
When reviewing a pull request for the angular repository, follow these essential guidelines to ensure high-quality contributions:
Context & Ecosystem:
Key Focus Areas :
reference/ directory (e.g., reference/router.md). Always prioritize these rules for their respective packages.Execution Workflow : Determine the appropriate review method. If the user explicitly asks for a remote or local review in their request, that takes precedence (e.g. "leave comments on the PR" implies remote). Otherwise, use the GitHub MCP or available scripts to determine if the review should be local or remote.
Common Review Practices (Applies to both Local and Remote)
* **Preparation & Checklist**:
* First, create a task list (e.g., in `task.md`) that you can easily reference containing **all** the review requirements from the "Key Focus Areas" section (Commit Messages, Performance, Testing, etc.), along with any specific review notes or requests from the user.
* Before doing an in-depth review, expand this list into more detailed items of what you plan to explore and verify in the PR.
* As you conduct the review, check off items in this list, adding your assessment or findings underneath each item.
* At the end of your review, refer back to the checklist to ensure every single requirement was completely verified.
* **Fetch PR Metadata Safely** : When you need to read the PR description or context, do NOT use `gh pr view <PR_NUMBER>` by itself, as its default GraphQL query may fail due to lack of `read:org` and `read:discussion` token scopes. Instead, use `read_url_content` on the PR URL or use `gh pr view <PR_NUMBER> --json title,body,state,author`.
* **Check Existing Comments First** : Before formulating feedback, use the GitHub MCP or available scripts to fetch existing comments on the PR. Review this feedback to avoid duplicate comments, and incorporate its insights into your own review process.
* **Constructive Feedback** : Provide clear, actionable, and polite feedback. Explain the _why_ behind your suggestions or edits. Do **NOT** leave inline comments purely to praise, agree with, or acknowledge a correct implementation detail, as this clutters the review. If you want to praise the PR, do so in the single general PR comment.
A. Local Code Review (If the PR is owned by the author requesting the review)
* **Checkout** : Check out the PR branch locally (if it doesn't already exist, fetch it). If checking out the branch fails due to a worktree claim (e.g. "fatal: '' is already used by worktree at ''"), do the review in that directory.
* **Review & Edit**: Execute the review directly on the code. Instead of adding inline PR comments for suggestions, format the codebase or apply the edits directly to the files.
* **Feedback** : Summarize the review findings and the concrete changes you made in a message to the user, referencing the completed items from your checklist.
* **Do NOT Commit or Push** : Leave the changes uncommitted in the working directory so the user can easily review the pending edits locally. Let the user know the changes are ready for their review, but do not ask for approval to push.
* **Resolve Comments** : Once the user confirms the changes are good and should be committed/pushed, respond to the existing comments as 'resolved' using the GitHub MCP or available scripts.
B. Remote Code Review (For all other PRs)
* **Batching Comments (MCP Server - Preferred)** : If you have the GitHub MCP Server configured, you **MUST** follow this workflow to avoid spamming the author with multiple notifications:
1. Create a pending review using `mcp_github-mcp-server_pull_request_review_write` (method `create`).
2. Add your inline comments to the pending review using `mcp_github-mcp-server_add_comment_to_pending_review`.
3. Submit the review using `mcp_github-mcp-server_pull_request_review_write` (method `submit_pending`).
* **Batching Comments (Scripts - Fallback)** : If you do **NOT** have access to the GitHub MCP Server (e.g., specific MCP tools are missing from your context), fallback to using the provided scripts. Use `post_inline_comment.sh` to stage your comments locally. Once all comments are staged, you **MUST** call `submit_pr_review.sh` to publish them as a single batched review (and send a single notification). Try to keep comments minimal or use a general comment if you have many suggestions.
* **Use Suggested Changes** : Whenever appropriate (e.g., for simple code fixes, refactoring suggestions, or typo corrections), prefer using GitHub's **Suggested Changes** syntax (`suggestion ... `) in your inline comments. This allows the author to apply your suggested code improvements with a single click in the GitHub UI.
* **Review Type** : Never mark an external PR review as an "approval" unless explicitly instructed by a repo maintainer. Always use "Request Changes" or "Comment". Note that some tools might only support commenting.
* **Require User Approval Before Posting** : Prepare your review comments and present them to the user, alongside a summary of your completed checklist. Do NOT post comments to the PR without explicitly asking the user for permission first. Only post the review after the user approves.
* **Prefix Agent Comments** : To make it clear when comments are generated and posted by an AI agent rather than a human user, **always** prefix your review comments with `AGENT: `.
The following tools are available for remote interactions. We prefer using standard GitHub MCP Server tools when available. If you do not have the MCP server set up, you MUST fallback to using the custom bash scripts.
mcp_github-mcp-server_pull_request_review_writemcp_github-mcp-server_add_comment_to_pending_reviewThe following scripts are provided as fallbacks if the MCP server is not available. Note that they rely on the gh CLI being correctly installed and authenticated in the local environment.
determine_review_type.shDetermines whether to use the Local or Remote review workflow by checking if the currently authenticated GitHub user via the gh CLI matches the author of the pull request.
Usage:
.agent/skills/pr_review/scripts/determine_review_type.sh <PR_NUMBER>
get_pr_comments.shFetches all existing inline comments on a PR using the GitHub API. This is crucial for reviewing other contributors' feedback and avoiding duplicate comments. It outputs JSON containing the id, path, line, body, and user for each comment.
Usage:
.agent/skills/pr_review/scripts/get_pr_comments.sh <PR_NUMBER>
reply_pr_comment.shReplies to an existing PR comment thread. This is useful for marking comments as resolved after addressing them in a local code review. Note that the COMMENT_ID must be the ID of the top-level comment in the thread.
Usage:
.agent/skills/pr_review/scripts/reply_pr_comment.sh <PR_NUMBER> <COMMENT_ID> <REPLY_BODY>
post_inline_comment.shThe GitHub CLI gh pr review command does not natively support adding inline comments to specific lines of code via its standard flags. This script wraps the GitHub API to stage comments locally. They will not be published until you call submit_pr_review.sh.
Usage:
.agent/skills/pr_review/scripts/post_inline_comment.sh <PR_NUMBER> <FILE_PATH> <LINE_NUMBER> <COMMENT_BODY>
Example:
.agent/skills/pr_review/scripts/post_inline_comment.sh 12345 "packages/core/src/render3/instructions/element.ts" 42 "AGENT: Consider the performance implications here."
submit_pr_review.shSubmits all locally staged inline comments as a single batched review via the GitHub Pull Request Reviews API.
Usage:
.agent/skills/pr_review/scripts/submit_pr_review.sh <PR_NUMBER> <EVENT_TYPE> [BODY]
Options:
EVENT_TYPE: Must be COMMENT, APPROVE, or REQUEST_CHANGES. Never use APPROVE for external PRs.BODY: (Optional) A general summary comment for the review.Example:
.agent/skills/pr_review/scripts/submit_pr_review.sh 12345 COMMENT "AGENT: I have left a few inline suggestions for your consideration."
Weekly Installs
–
Repository
GitHub Stars
100.1K
First Seen
–
Security Audits
测试策略完整指南:单元/集成/E2E测试金字塔与自动化实践
11,200 周安装