SuperAPI AI Directory

implement-review-pr

Security & auditing

View repository

Updated 10-15 21:40

About this skill

implement-review-pr

Review GitHub PR CI status, code quality, and security.

Prerequisites

  • gh The CLI is installed and authenticated

Flow

Step 1: Get PR information

gh pr view <number-or-url>
gh pr diff <number-or-url>

Step 2: Check CI status

gh pr checks <number-or-url>

Check whether all checks pass. If any have failed, report the details to the user.

Step 3: Check the PR title

Check compliance with the Conventional Commits format:

  • type(scope): subject Format of
  • Valid type (feat / fix / docs / refactor / test / chore / style / build / ci / perf)
  • Subject is within 72 characters

Step 4: ① Specification compliance review

Delegate to the Agent tool to check compliance with the specification:

Check items:

  • Whether the requirements and acceptance criteria of the Issue linked to the PR are satisfied
  • Whether out-of-scope implementation has been mixed in
  • Whether the descriptions in the PR title and body are consistent with the changes

Step 5: ② Code quality review (including OWASP security)

Delegate to the Agent tool to check code quality and security:

Check items (quality):

  • Architecture compliance (component hierarchy, placement location)
  • Naming conventions
  • Import rules
  • If frontend (React, etc.) changes are included: risk of unnecessary re-renders
  • Test coverage

Check items (security, required):

  • OWASP Top 10
  • API key and secret leakage
  • Input validation
  • Authentication and authorization implementation
  • Handling of sensitive data

Step 6: Generate a review report

If any out-of-scope items are detected, include "items excluded from scope" and proposed handling in this report (see "Handling of out-of-scope items" below). The issue number for the extracted destination will be finalized when the issue is created after user approval, so write 'TBD' at the report stage. Collect out-of-scope items during the review (Steps 4–5).

## PR #123: feat(auth): 新機能追加

### CI Status
✅ All checks passed

### Title Compliance
✅ Conventional Commits 準拠

### ①仕様準拠レビュー
✅ 問題なし
⚠️ 要確認: 受け入れ条件 X が未実装

### ②コード品質レビュー

#### コード品質
✅ 問題なし
⚠️ 要改善: `src/Foo.tsx:10` — 説明
❌ 要修正: `src/Bar.tsx:20` — 説明

#### セキュリティ(OWASP)
✅ セキュリティ問題なし
❌ [HIGH] `src/api.ts:5` — 説明

Step 7: Post review comments to GitHub (optional)

Post after confirming with the user:

gh pr review <number> --comment --body "..."
# または
gh pr review <number> --approve
gh pr review <number> --request-changes --body "..."

Handling of out-of-scope items

This skill is in principle a read-only review, but if during the PR review it detects matters that should be addressed but are judged to be outside the current scope (unaddressed improvements, separate features, technical debt, follow-up work), track them rather than leaving them unattended.Only when out-of-scope items are detected, an exception is made to perform write operations such as commenting on or creating Issues after obtaining user approvalLet it be.

Procedure

  1. Check existing Issues Search for existing open Issues that implement the target:
gh issue list --state open --search "${KEYWORD}"

The keyword is "${KEYWORD}" Pass it quoted in .

  1. Present to the user and obtain approval Include out-of-scope items, the presence or absence of existing Issues, and proposed actions (adding a comment to an existing Issue or filing a new one) in the review report and present them to the user.Execute after obtaining approval(do not perform Issue operations without confirmation).

  2. If an existing Issue exists: add a comment

gh issue comment "${ISSUE_NUMBER}" --body "$(cat <<'EOF'
## 実装サポート情報(別作業から検出)

### 検出背景
PR レビュー(PR #N)の過程で発見した事項。

### 関連ファイル・シンボル
- `src/path/to/file.ts` — 対象関数名・クラス名

### パッケージ・サービスから見た役割・影響範囲
(このシンボルの担う境界、呼び出し元/呼び出し先)

### 着手時の注意点・依存関係
(依存パッケージ、順序制約など)
EOF
)"
  1. If no existing Issue exists: file a new one create-issue-tree is introduced, use it (linking to an existing route is --root <ルートissue番号>); if not introduced, use create-issue to file under the appropriate parent Issue. The title shall be in Conventional Commits format.

  2. State explicitly in the PR body and review report Out-of-scope items are collected during the review (Steps 4–5) and included in the Step 6 report. Write operations to Issues are performed after approval. The Step 6 review report and the Step 7 GitHub review comment shall state the "items excluded as out of scope" and proposed actions. Since the spinoff destination Issue number is finalized upon filing after approval, it shall be 'TBD' at the time of the report, and the finalized number shall be added in a GitHub comment after filing.

Security notes: gh The keywords and comment body passed to "${var}" shall quote variables with<<'EOF') to prevent injection.

Verification

After the review is complete, confirm that the report contains both sections: "①Specification compliance" and "②Code quality/security" (if .claude/rules/verification.md exists in the target repository, follow its five-stage gate. If it does not exist, follow these key points: do not declare completion without evidence). Do not declare completion if security issues (HIGH) remain.

Common failures

Problem Workaround
Proceeding to code quality review without confirming specification compliance Follow the order of Step 4 (①Specification compliance) → Step 5 (②Code quality/security)
Report the security review in a separate section independent of code quality Report it integrated into the "Security (OWASP)" subsection within the ②Code quality section
Proceeding to code review without confirming CI failures First confirm in Step 2 that CI has passed all checks

Notes

  • If there are security issues (HIGH), recommend request-changes
  • If CI is failing, recommend blocking the review

Execution in a sandbox environment

This skill requires GitHub operations over the network (gh pr view / gh pr checks , etc.). The default flow is entirely read-only and performs no writes, but if you choose to post a review viagh pr review , it involves writes. Run the relevant commands with the sandbox disabled on a per-command basis.gh pr review When executing this as well, disable the sandbox on a per-command basis in the same way. It cannot be executed in an environment where network blocking cannot be lifted.