SuperAPI AI Directory
Partner中文AI newsFavorites
Skillscomet-github-pr-review

comet-github-pr-review

Coding & development

View repository

Updated 10-16 01:35

About this skill

Comet GitHub PR review

First read ../comet-github/references/maintainer-contract.md. Unless the user separately authorizes fixing or replying on GitHub, remain read-only.

Refresh target state

  1. Parse the PR number or URL, and confirm the repository.
  2. Fetch the current PR metadata: target branch, source branch and SHA, author, linked Issue, labels, mergeability status, and update time.
  3. Read the full PR body, commits, diff, comments, and review threads. Confirm whether threads are resolved or stale; do not treat all visible comments as still valid.
  4. Query the current checks for the exact head. If there are failing checks, delegate detailed investigation to comet-github-ci-triage。

Conclusions must be based on the current PR head/base. Passing tests do not prove the PR is mergeable, because the head may be behind the base or there may be current conflicts.

Review the implementation

For each claimed behavior:

  • Find the real production call path;
  • Compare the implementation against the linked Issue/spec;
  • Check relevant tests and generated Runtime assets when necessary;
  • When reporting a Bug or blocker, reproduce a reachable failure path;
  • Check whether the current head has already fixed the issue.

Review bot output can only be used as an investigation lead, not directly as a conclusion. Distinguish production logic, test/fixture drift, generated artifact drift, environment noise, and merge conflicts.

Report only issues that must be addressed

Prioritize reporting issues that block correctness, data integrity, security, user-visible behavior, or merging. Unless the repository contract explicitly requires it, omit pure style suggestions, theoretical edge cases, and speculative improvements.

Each issue includes: severity, a concise title, the exact file/line number or Runtime path, why the current behavior fails, the minimal fix direction, and the evidence status.

End with a clear conclusion, such as "no must-fix items", "must-fix items exist", "merge/CI issues need to be handled first", or "insufficient evidence".

Comment and fix boundaries

  • When the user asks for a comment, provide copy-paste-ready Markdown after the analysis.
  • Do not post comments without an explicit request.
  • When the user asks for a fix, hand the confirmed scope to comet-github-issue-fix or the existing Comet workflow; do not make changes directly based on unconfirmed bot suggestions.