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

実行モードの制約: サブエージェント・サブスキル・Bashをバックグラウンド実行しないこと

本スキルは claude-task-worker の cc-fix-onetime ラベルをトリガーに自動起動される想定。ワーカーはスキルプロセスの同期完了を根拠に cc-fix-onetime の除去やコールバックコメント投稿を進めるため、バックグラウンド化すると修正コミット未 push のまま Resolve だけ済まされたり、レビュー未対応のまま fix ラベルが外れて放置される状態壊れが起きる。内部処理はすべて同期実行で完結させること。

  • Agent ツールは既定が run_in_background: true（バックグラウンド）。そのため呼び出しごとに 必ず run_in_background: false を明示指定 し、フォアグラウンドで同期的に結果を受け取ってから次の処理に進む。指定を省略した場合はバックグラウンドで走り、本スキルが未完のまま終了する
  • Skill ツール呼び出しには run_in_background: true を指定しない（既定は同期）。特に create-review-fix-plan / commit-push / resolve-pr-comments は、返却された修正プラン・push完了・resolve完了を受け取ってから次のフェーズに進む
  • Bash ツールにも run_in_background: true を指定しない。既定の同期実行で結果を受け取ってから次の処理に進む
  • シェルコマンド末尾に & を付けない。nohup / disown / setsid でのデタッチ、ScheduleWakeup 等での後回しも禁止
  • 同一メッセージ内で複数の Agent / Skill を並列に投げるのは「並列実行」であって「バックグラウンド実行」ではないため許容される。ただし Agent は個別に run_in_background: false を指定 し、その場で同期的に完了を待つ

理由: Agent ツールの既定が background であることを見落として run_in_background を省略すると、修正コミット未 push のままスキルプロセスが終了し、ワーカーが「正常完了」と誤認して cc-fix-onetime が外れる事故が確実に起きる。

実行モードの制約: TaskCreate は1コール1タスクで発火する

進捗管理などで TaskCreate を使う場合、以下のルールを厳守すること。違反するとバリデーションエラー（missing subject/description や unexpected parameter tasks）で中断し、フェーズが未完のまま外側のワーカーが「正常完了」と誤認して cc-fix-onetime が外れてしまう。

  • 1コール = 1タスク。tasks / todos などの配列パラメータは存在しない。複数タスクを登録したい場合は、同一メッセージ内で TaskCreate を複数回発行する（並列可）
  • 必須パラメータは subject（短いタイトル）と description（何をするか）の2つ。いずれもトップレベル文字列として渡し、ネストしたオブジェクトの中に入れない
  • TaskCreate は deferred tool のため、セッション開始時点ではスキーマがプロンプトに含まれない。使用前に必ず ToolSearch(query: "select:TaskCreate") で1回だけスキーマをロードする。ロードせずに呼ぶと typed parameters が文字列化されてクライアント側でも弾かれる
  • そもそも本スキルは TaskCreate を必須としない。フェーズ1〜6の「並列/逐次グループ」内部管理で十分な場合は、TaskCreate を使わず直接次フェーズへ進んでよい

フェーズ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等のフロントエンド作業。PencilのデザインデータからUIを実装する（.pen を参照元としてUIに変換する）場合は必ずこのエージェントを使うこと
  • pencil-design-updater: Pencilファイル（.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）。.pen への編集タスクは必ずこのエージェントに任せること
  • lightweight-assistant: 内容が具体的で探索不要・単一ファイル編集レベルの軽量タスク（型定義追加、定数追加、設定ファイル更新など）
  • general-purpose-assistant: 上記以外、複数ファイルにまたがる実装、調査を伴うタスク、テスト/Lint修正

並列 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 "<更新後の本文>" を使用
    • 変更点の要約・テスト観点の追記・既存セクションの整合性を保つ
    • ## 修正履歴 セクションを必ず設ける。既存のdescriptionに無ければ末尾に新規追加し、既にあれば追記する形で残す。各エントリは以下のフォーマットに従う: 
      ## 修正履歴

### YYYY-MM-DD: レビュー指摘対応（<件数>件）
- <対応した指摘の要約1>（対応コミット: <commit hash 短縮>）
- <対応した指摘の要約2>（対応コミット: <commit hash 短縮>）
      • 日付は date +%Y-%m-%d で取得した実行日を使用する
      • 過去のエントリは削除・改変せず、新しいエントリを上に追記する（新しいものが上）
      • 1件ごとに「何を指摘され、どう直したか」が読み手に伝わる粒度で書く
  3. 最終報告として、対応した指摘の件数とPRのURLを出力

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

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

手順:

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