Agent-Skills.md

Agent Skills: Fix Review Point

Address unresolved review comments on specified branch

UncategorizedID: getty104/claude-code-marketplace/fix-review-point
10

Install this agent skill to your local

pnpm dlx add-skill https://github.com/getty104/claude-code-marketplace/tree/HEAD/base-tools/skills/fix-review-point

Skill Files

Browse the full folder contents for fix-review-point.

Download Skill

Loading file tree…

base-tools/skills/fix-review-point/SKILL.md

Skill Metadata

Name
fix-review-point
Description
Address unresolved review comments on specified PR

Fix Review Point

GitHub PR $0 の未解決レビューコメントに対応し、修正のコミット・push・Resolve・description更新までを完遂するスキルです。 Instructionsに従って順に実行してください。各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。

自律実行モード: このスキルはユーザーへの確認を求めずに最後まで自律的に完遂すること。判断が必要な場面では、本ドキュメントに記載された既定の挙動に従って自動的に意思決定を行い、処理を継続する。確認のために停止することは禁止する（フェーズ0の安全ガード条件に該当する場合のみ中断可）。

Instructions

フェーズ0: 事前チェックとPRチェックアウト

並列で以下を確認します。1つでも失敗したら、その場で原因を解消してから先に進むこと。

  • gh pr view $0 --json number,state,headRefName,isDraft でPRが存在し OPEN であることを確認する。CLOSED/MERGEDなら処理を中断
  • gh pr checkout $0 >/dev/null 2>&1 でPRブランチをチェックアウト
  • pwd を実行し、.claude/worktrees/ 配下にいることを確認する。worktree外にいた場合は安全のため処理を中断する（デフォルトブランチで作業してはならない）
  • gh repo view --json defaultBranchRef -q .defaultBranchRef.name でデフォルトブランチ名を取得し、git rev-parse --abbrev-ref HEAD で現在ブランチを確認する。現在ブランチがデフォルトブランチと一致する場合は安全のため処理を中断する。デフォルトブランチ名の取得に失敗した場合も処理を中断する（fail-safe）
  • git status --short で未コミット変更の有無を確認する。未コミット変更が存在する場合は git stash push -u -m "fix-review-point auto-stash $0" で自動的に退避してから先に進む（ユーザーへの確認は行わない）

完了条件: worktree内、PRブランチ（デフォルトブランチ以外）にチェックアウト済み、PR OPEN が確認できていること。

フェーズ1: 修正プランの取得

create-review-fix-plan skill を $0 で呼び出し、以下を取得する：

  • 未解決レビューコメントの一覧（コメント本文・対象ファイル・行番号）
  • CIステータス（失敗ジョブと原因の要約）
  • 修正タスクの一覧（目的・対象範囲・完了条件付き）
  • タスク間の依存関係

修正点がない場合: gh pr merge $0 --merge --delete-branch でPRをマージし、このスキルの処理を終了する。

返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。

完了条件: 修正タスクが「並列実行可能なグループ」と「逐次グループ」に分類できていること。

フェーズ2: タスク実行戦略の決定

タスクを以下の基準で振り分けて実行計画を立てる：

サブエージェント選定

  • frontend-implementer: UI/コンポーネント実装、デザイン適用、shadcn/ui等のフロントエンド作業
  • lightweight-assistant: 内容が具体的で探索不要・単一ファイル編集レベルの軽量タスク（typo修正、命名変更、定数追加など）
  • general-purpose-assistant: 上記以外、複数ファイルにまたがる修正、調査を伴うタスク、テスト/Lint修正、CI失敗の原因調査

並列 vs 逐次の判断

以下のいずれかに該当するタスク同士は 逐次 で実行する：

  • 同じファイルを編集する可能性がある
  • 一方の出力（型・関数・スキーマ）に他方が依存する
  • マイグレーションやスキーマ変更を含む

それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。

フェーズ3: サブエージェントへのブリーフィング

各サブエージェントを起動する際は、以下を すべて プロンプトに含めること。サブエージェントは現在の会話履歴を持たないため、自己完結したブリーフィングが品質を決める。

【背景】PR #$0 のレビュー指摘対応: <PRタイトル要約>

【あなたが担当する指摘】
<レビューコメント本文を引用>
- 対象ファイル: <path:line>
- 指摘者の意図: <create-review-fix-plan が抽出した要約>

【対象範囲（編集可ファイル/ディレクトリ）】
<具体パスを列挙。範囲外を触らないこと>

【触れてはいけないファイル】
<並列実行中の他タスクが触る予定のファイル>

【完了条件】
- レビュアーの指摘内容が解消されていること
- 該当箇所のテストが追加・更新され、すべてpassすること
- `npm run lint`（またはプロジェクト指定のlint）に該当ファイルでエラーがないこと
- 既存の挙動を意図せず変更していないこと

【参考情報】
- レビューコメントへの直リンク
- 既存の類似実装の参照先（あれば）

【作業ディレクトリ】
<worktreeの絶対パス>。すべてのコマンドはここを基準に実行すること。

サブエージェントが完了報告を返したら、本体側で git diff --stat を実行して変更範囲が宣言通りか検証する。範囲外の変更や指摘と無関係な変更があれば、当該サブエージェントを再起動して修正させる。

フェーズ4: テストとLintの収束ループ

すべてのサブエージェントが完了したら、本体で以下を順に実行：

  1. プロジェクトのテストコマンドを実行（package.json の scripts.test を確認）
  2. プロジェクトのLintコマンドを実行（scripts.lint）
  3. 失敗した場合、general-purpose-assistant に 失敗ログ全文と該当ファイルパス を渡して修正させる
  4. 修正後、再度テストとLintを実行

テスト/Lintコマンドがプロジェクトに存在しない場合はスキップしてよい（その旨を最終報告に含めること）。

フェーズ5: コミットとpush

  1. commit-push skill を呼び出し、変更をコミット・push
  2. Push後のCI結果は 待たずに 次のフェーズへ進む（CIの収束は別ループで扱う）

フェーズ6: Resolve と description 更新

  1. resolve-pr-comments skill を呼び出し、対応済みのレビューコメントをすべてResolveする
  2. 今回の修正内容を反映してPRのdescriptionを最新化する
    • gh pr edit $0 --body "<更新後の本文>" を使用
    • 変更点の要約・テスト観点の追記・既存セクションの整合性を保つ
  3. 最終報告として、対応した指摘の件数とPRのURLを出力

PRクローズ時の連動処理（共通ルール）

本スキルの実行中に何らかの理由でPRをクローズする判断に至った場合（例: 指摘が「このPRは取り下げて別アプローチで再実装」を求めている、要件が陳腐化していた、別PRで既に対応済み、コンフリクトが解消不能、など）は、PRと 関連Issueを必ず連動してクローズする。PRだけ閉じてIssueをOPENのまま残すと、他の作業者が同じスコープに重複着手するため、片側だけのクローズは禁止する。

手順:

  1. クローズ理由を1-3行で言語化する
  2. PRに理由を含むコメントを投稿し、PRをクローズする 
    gh pr close $0 --comment "<クローズ理由。代替PR/Issueがあればそのリンクを含める>"
  3. 関連Issueを特定する。優先順位:
    • gh pr view $0 --json closingIssuesReferences -q '.closingIssuesReferences[].number'（GitHubが自動認識したリンク）
    • 上記が空の場合は gh pr view $0 --json body -q '.body' の本文から Closes #<n> / Fixes #<n> / Resolves #<n> を正規表現で抽出する
  4. 取得した各Issue番号について gh issue view <n> --json state -q '.state' で状態を確認し、OPEN の場合のみ以下を実行する。 
    gh issue comment <n> --body-file - <<EOF
## 関連PRクローズに伴うクローズ
PR #$0 を以下の理由でクローズしました。本Issueの作業はこのPR内では行いません。

### クローズ理由
<理由>

### 今後の扱い
<代替PR/Issueがあればリンク。再着手が必要な場合はその旨と新規Issue番号>
EOF
gh issue close <n> --reason "not planned"
  5. 最終報告に「PR #$0 とリンクされたIssue #<n> をクローズした理由・代替手段」を必ず明記する

クローズ判断はフェーズ0の安全ガードとは独立に発生し得る。判断時点でこの共通ルールを適用すること。

注意事項

  • デフォルトブランチで作業しない: フェーズ0で必ず確認。途中でもファイル編集前には pwd を再確認することを推奨
  • サブエージェントの結果を鵜呑みにしない: 完了報告は「やったつもり」を示すだけ。git diff で実際の差分を必ず検証する
  • 指摘の本質に応える: コメントの字面だけを拾って小手先で済ませない。レビュアーが懸念している根本（設計・安全性・可読性）に向き合うこと
  • コメントは残さない: 生成コードに「なぜ」を説明する以外のコメントを入れないよう、サブエージェントへのブリーフィングにも明記する
  • エラーの根本原因に向き合う: テスト失敗時に --no-verify やテストのスキップで誤魔化さないこと。原因を特定してから修正する
  • ユーザーへの確認を求めない: 全フェーズを通じて、進行可否や方針判断についてユーザーに確認を求めない。安全ガード（フェーズ0のworktree外/デフォルトブランチ検出、PRがCLOSED/MERGED）に該当する場合のみ中断し、それ以外は本ドキュメントの既定挙動に従って自律的に最後まで完遂する
  • PRクローズと関連Issueクローズは必ずセット: PRをクローズする判断に至った場合は、上記「PRクローズ時の連動処理」を必ず適用し、関連Issueも理由付きコメントを残してクローズする。片側だけクローズして放置することは禁止する