القائمة
GitHub PR のコードレビューコメントに対応する。未 resolve のみを抽出 → 対応方針をユーザー承認 → 1 件ずつ修正＋返信 → AI レビュー由来の指摘はナレッジに反映するワークフロー。「/review-response [PR番号]」「レビュー対応」「レビューに返信」などの依頼時に使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
PR の CI 失敗を修正し、全 CI がパスするまでプッシュ→待機→修正を繰り返す。「/ci-fix-and-verify [PR番号]」「CI直して」「CIが落ちてる」「CI修正」などの依頼時に使用。
PR 提出前にコードオーナー視点でフルレビューする。WHY の理解 → 設計 → AST/基盤型 → 実装（複数 Agent の順次レビュー）の順に、各フェーズでユーザーと対話しながら指摘を修正し、品質に問題がなくなるまで繰り返す。「/full-code-review」「フルレビュー」「レビューして」などの依頼時に使用。rsvelte（公式 Svelte コンパイラの Rust ポート）専用。
Rust の性能改善を「計測 → 仮説 → 変更 → 再計測」のループで地道に回すためのスキル。プロファイラの選び方、Cargo の最適化設定、データ構造・アロケーション・ハッシュ・分岐などの定石をフェーズ順に適用する。1 回 1 変更 1 計測の規律を厳守する。rsvelte 固有の既知ボトルネック（`serde_json::Value` 駆逐、`bumpalo` 導入、`Atom<'a>`、codegen 直書き）と OXC 対応表、NAPI 検証手順も §7 に収録。「Rust の性能改善」「ボトルネック調査」「プロファイル取って最適化」などの依頼で使用。
Audit and clean up the repository — remove dead files, fix naming inconsistencies, update .gitignore, and ensure the repo is well-organized for OSS contributors. Does NOT modify source code logic.
Upgrade the Svelte submodule to the latest (or specified) version, regenerate fixtures, identify test failures, and fix all regressions until tests pass 100%.
Svelte を使う外部リポジトリ（ツール / ライブラリ / アプリ）を git submodule として取り込み、Svelte コンパイラを rsvelte に差し替えても完全に同等に動作するかを検証する。既存のサブモジュールが指定された場合は最新化したうえで再検証し、回帰があれば rsvelte 側を自動修正する。「/verify-svelte-compat <url-or-name>」で実行。
| name | review-response |
| description | GitHub PR のコードレビューコメントに対応する。未 resolve のみを抽出 → 対応方針をユーザー承認 → 1 件ずつ修正＋返信 → AI レビュー由来の指摘はナレッジに反映するワークフロー。「/review-response [PR番号]」「レビュー対応」「レビューに返信」などの依頼時に使用。 |
| argument-hint | [pr-number] |
| allowed-tools | Read, Grep, Glob, Bash, Edit, Write, Agent, Skill |
GitHub PR でレビューコメントを受け取った際の対応手順。
| 原則 | 内容 |
|---|---|
| 未 resolve に着目 | resolve 済みは対応不要。未 resolve のみ対応 |
| 1 つずつ対応 | 複数コメントがあっても 1 つずつ順番に対応 |
| 必ず返信 | 対応したら必ずそのコメントに返信（スレッド形式） |
| コミットハッシュを記載 | 返信には対応したコミットハッシュを必ず含める |
| 変更不要でも説明 | 変更しない場合も、なぜ不要なのか理由を明記して返信 |
| ページングで全件確認 | コメントが多い場合、API のページングで全件取得する |
未 resolve のレビュースレッドのみを GraphQL で取得する（REST API では resolve 状態が取れない）。
# 引数から PR 番号を取得（省略時は現在ブランチから）
PR_NUMBER="${1:-$(gh pr list --head "$(git branch --show-current)" --json number --jq '.[0].number')}"
# owner/repo
REPO_INFO=$(gh repo view --json owner,name --jq '"\(.owner.login)|\(.name)"')
OWNER="${REPO_INFO%|*}"
REPO="${REPO_INFO#*|}"
# 未 resolve のレビュースレッドを取得
gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $pr) {
reviewThreads(first: 100) {
nodes {
id
isResolved
path
line
comments(first: 20) {
nodes {
databaseId
body
author { login }
url
}
}
}
}
}
}
}
' -f owner="$OWNER" -f repo="$REPO" -F pr="$PR_NUMBER"
スレッド数が 100 を超える場合は pageInfo を使ってページングする。
コードの修正やコメントへの返信を行う前に、必ずこのステップを実行すること。
未 resolve のコメントを全件取得したら、各コメントについて現在のコードを読んで検証し、以下の情報を表形式でユーザーに提示する：
| # | ファイル | 指摘内容（要約） | 判定 | 対応方針 |
|---|---|---|---|---|
| 1 | path/to/file.rs:L42 | 指摘の要約 | 要修正 / 対応不要 | 具体的な修正内容 or 不要と判断した理由 |
判定の基準：
ユーザーの承認を得てから、次のステップに進むこと。 ユーザーが方針を修正した場合はそれに従う。
ユーザーの承認後、未 resolve のコメントのみを対象に 1 つずつ順番に対応する。これにより：
各コメントに対応したら、その変更をコミットする。
cargo fmt && cargo clippy）を必ず通すfix:, refactor:, perf: など）cargo fmt --all
cargo clippy --all-targets --all-features -- -D warnings
cargo test --release --test <関連スイート>
git add <修正ファイル>
git commit -m "fix(<scope>): <変更内容の要約>"
git push origin HEAD
コミット後、GitHub コメントにスレッド形式で返信する（返信のフォーマット参照）。
レビューコメントの投稿者が AI ボット（coderabbitai[bot]、devin-ai-integration[bot]、chatgpt-codex-connector[bot]、claude[bot] など）の場合、対応後に以下のフィードバックループを実行する。
指摘が正しく、実際にコード修正を行った場合：
CLAUDE.md（プロジェクト全体の方針）.claude/skills/*/SKILL.md（rsvelte 固有のスキル群: full-code-review, verify-svelte-compat, perf など）CLAUDE.md に新しいパターンとして追記する指摘が的外れで、変更不要と判断した場合：
CLAUDE.md に「これは問題ない」という文脈を追記する
注意: スキル / CLAUDE.md の追記・改善はユーザーに確認してから行うこと。
返信は 指摘者の言語に合わせる（日本語の指摘には日本語、英語の指摘には英語）。OSS なので英語が多い。
Thanks for the catch!
[summary of the fix]
Fixed in: abc1234
Thanks for the review!
[reasoning for keeping the current implementation]
- [reason 1]
- [reason 2]
- [link to spec / official Svelte source if relevant]
I'll keep the current implementation for the reasons above.
ご指摘ありがとうございます！
[対応内容の説明]
対応コミット: abc1234
ご指摘ありがとうございます！
[変更不要と判断した理由の説明]
- [根拠 1]
- [根拠 2]
- [必要に応じて参考リンクや仕様書への参照]
上記の理由から、現状の実装を維持させていただきます。
# スレッド形式で返信（pull request review comment への reply）
gh api "repos/${OWNER}/${REPO}/pulls/${PR_NUMBER}/comments/${COMMENT_ID}/replies" \
-f body="返信内容"
COMMENT_ID は GraphQL で取得した databaseId を使う。
レビューコメント (coderabbitai[bot]):
The
unwrap()on line 42 will panic if the iterator is empty. Consider usingunwrap_or_default()or handling the error explicitly.
返信:
Good catch — switched to `unwrap_or_default()` since an empty iterator is a valid state in this code path.
Fixed in: 7f8e9a1
追加対応 (unwrap_or_default 系の指摘なので、ナレッジに同じパターンが既にあるか CLAUDE.md を確認 → なければユーザーに追記提案)
レビューコメント:
Why use
compact_strinstead ofStringhere?
返信:
This matches the official Svelte compiler's intent of keeping symbol names compact in memory. `CompactString` inlines small strings (≤24 bytes) without heap allocation, which is the common case for Svelte identifiers.
See `CLAUDE.md` → "Memory-efficient layout (u32 positions, compact_str)".
Keeping the current implementation.