review-pr-clickup

ClickUp のコンテキストを利用したプルリクエストのレビュー

目的

特定の GitHub プルリクエストの差分を取得し、関連する .github/instructions ファイルと ClickUp チケットの要件に照らして分析したうえで、GitHub CLI（gh）を使って構造化されたレビューコメントをプルリクエストに直接投稿します。

ステップ 1：コンテキストを解決する — 必ず最初に同梱スクリプトを実行する

旧ワークフローのステップ 1、2、3、3.5（REPO／PR の解決、分離された WORKDIR の算出、作業ツリーがクリーンであることの確認、gh によるプルリクエストの差分／メタデータ／コメントの取得、ClickUp チケットの検出と取得）は、すべて機械的な処理です。判断は必要ないため、手作業で再現する手順を文章で説明するのではなく、同梱スクリプトとして一度実装されています。この処理を自分で再現すること（WORKDIR を再計算したり、個別に gh を呼び出したりすること）は、実行中にパスのずれや混乱が生じる原因そのものです。必ずスクリプトに任せてください。

モードにかかわらず、毎回、最初のアクションとして次を実行してください。

bash "$(dirname "$0")/../scripts/prefetch.sh" --repo "$REPO" --pr "$PR"

実際には、SKILL.md がインストールされている場所を基準に scripts/prefetch.sh のパスを解決し（例：~/.claude/skills/review-pr-clickup/scripts/prefetch.sh）、--repo owner/repo --pr NUMBER を渡します。呼び出し元（CI パイプラインなど）があなたを呼び出す前にこのスクリプトをすでに実行し、そのことを伝えている場合は、再度実行する必要はありません。ただし、少しでも不確かな場合は、そのまま実行してください。このスクリプトは冪等であり、取得済みのファイルは再取得せずに再利用されます。また、ネットワークにアクセスせずに WORKDIR をすぐに復元したい場合は、--print-workdir-only 以外の引数を指定せずに実行することも含め、何度でも安全に呼び出せます。

スクリプトは、次のような最終ブロックを出力し、$WORKDIR/context.env に保存します。

MODE=CI|INTERACTIVE
REPO=owner/repo
PR=123
WORKDIR=/tmp/pr_review/owner_repo/123
SHA=<head-commit-sha>
TICKET_ID=CU-xxxxxxxx (or empty)
CLICKUP_STATUS=fetched|skipped|error|no_ticket
REPO_ROOT=/absolute/path/to/checked-out/repo

これらの値を正式な値として使用してください。手作業で WORKDIR を再計算したり、コンテキストから REPO／PR を再導出したり、SHA を推測したりしないでください。実行中にこれらの値が再度必要になった場合は、出力された値を保持しておくか、--print-workdir-only を再実行して WORKDIR を復元し、残りの値を $WORKDIR/context.env から読み取ってください。

REPO_ROOT は、すでにチェックアウト済みのリポジトリの絶対パスです。このスキルによってリポジトリが再度クローンまたはコピーされることはありません。 リポジトリ内にあるファイル（WORKDIR 内の取得済みアーティファクトではないファイル）を読む場合、たとえば .github/instructions/ やソースファイルを読む場合は、必ずパスの先頭に $REPO_ROOT を付けてください（例："$REPO_ROOT/.github/instructions"）。相対パスだけを使ってはいけません。その時点でシェルの現在の作業ディレクトリがリポジトリのルートである保証はありません（取得したファイルを調べるために、以前 WORKDIR に cd している可能性があります）。実際の実行で、リポジトリに存在していたにもかかわらず指示ファイルが検出されなかったのは、この曖昧さが原因でした。

処理する終了コード：

• 0：成功。ステップ 4 に進みます。
• 1：致命的エラー — REPO／PR がない、または CI モードで作業ツリーが汚れている場合です。スクリプト自身のエラー出力を表示して停止してください。回避しようとしてはいけません。
• 2：インタラクティブモードで作業ツリーが汚れています。ユーザーに先にコミットまたはスタッシュするよう伝えてください（または、ユーザーが明示的に問題ないと確認した場合に限り、--force を付けて再実行します）。

プルリクエストが指定されていない場合（インタラクティブモードのみ）： まだ --repo／--pr がない場合は、スクリプトを実行する前に、プルリクエストの URL または owner/repo#number（例：andresjz/API#1）をユーザーに尋ねてください。CI モードでは REPO／PR は GITHUB_REPOSITORY／PR_NUMBER 環境変数から取得され、スクリプトが自動的に読み取るため、ユーザーに質問してはいけません（下記を参照）。

スクリプトの MODE= 出力に基づくモードと投稿動作：

• MODE=CI：投稿前に確認を求めてはいけません。パイプライン自体が承認ゲートです。生成したらすぐにレビューを投稿してください（ステップ 6）。ユーザーからの入力を求めて待ってはいけません。
• MODE=INTERACTIVE：投稿する前に、下書きをユーザーに提示して確認を求めてください（ステップ 5 を参照）。

前提条件

• gh が認証済みであること（gh auth status）
• clickup-cli がインストールされ、PATH からアクセスできること
• ClickUp 認証用に CLICKUP_TOKEN 環境変数が設定されていること
• CLICKUP_TEAM_ID 環境変数が設定されていること（例：90111366728）
• .github/instructions/ ディレクトリが存在し、指示ファイルが格納されていること
• PR がオープンで、アクセス可能であること

必須のワークフロー

ここから参照する一時ファイル（meta.json、diff.txt、files.txt、head_sha.txt、comments.json、inline_comments.json、clickup_tickets.txt、clickup_summary.txt、context.env、summary.md、summary_simple.md、summary_fallbacks.md、findings.jsonl）はすべて、上記のステップ 1 で scripts/prefetch.sh が出力する WORKDIR の下に置きます。別のパスや手作業で算出したパスには決して置かないでください。

4. 関連する指示のみを検出して読み込む（リポジトリ非依存）

このスキルは、あらゆるリポジトリ／言語／フレームワークで動作する必要があります。java.instructions.md や controllers.instructions.md のようなファイル名をハードコードしないでください。実際に存在するファイルを検出し、関連性を動的に判断してください。

ls "$REPO_ROOT/.github/instructions"/*.md 2>/dev/null

常に $REPO_ROOT（ステップ 1 の出力）を基準にしてください。裸の相対パスは決して使わないでください。ステップ 1 の REPO_ROOT に関する注記を参照してください。

対象を *.instructions.md のみに限定しないでください。 リポジトリによっては、.instructions.md 接尾辞やフロントマターのない coding-standards.md、security.md などの名前で指示ファイルを置いている場合があり、これらも有効な指示ファイルとして検出する必要があります。上記の glob で何も見つからない場合、これはディレクトリに .md ファイルがまったくない（またはディレクトリ自体が存在しない）ことを意味します。実際に実行することなく「指示はない」と判断しないでください。

見つかった *.md ファイルごとに、この PR に適用されるかどうかを判断します。

Tier 1 — フロントマターの applyTo（推奨。GitHub の Copilot カスタム指示の規約と一致）： ファイル先頭の YAML フロントマター（--- 行の間）を読みます。1 つ以上の glob パターンを持つ applyTo キー（例：applyTo: "**/*.java" または applyTo: "**/*Controller.java,**/*Controller.kt"）がある場合、$WORKDIR/files.txt 内の各パスをそれらの glob に照合します。

• 一致する場合 → その指示ファイルの内容を、該当ファイルのレビュー時に含めます。
• 変更されたファイルのいずれにも一致しない場合 → その指示ファイルは完全にスキップします（内容を読み込まず、言及もしません）。
• applyTo がない、空である、または **／* に設定されているファイルは、常に適用可能（一般的なリポジトリ全体への指針。例：general.instructions.md）として扱います。

Tier 2 — ファイル名キーワードによる代替判定（ファイルにフロントマターがない、または applyTo キーがない場合のみ）： 拡張子（.md または .instructions.md）を取り除き、ファイル名からキーワードを取得します。

• キーワードが特定の技術／モジュール／レイヤーを示す場合（例：services、migrations、frontend、terraform）、そのキーワード（単数形または複数形、大文字小文字を区別しない）が変更されたファイルのうち少なくとも 1 つのパスに含まれる場合にのみ、そのファイルを含めます。
• キーワードが一般的で、技術スタックに依存しないエンジニアリングの実践方法を示す場合（例：general、default、common、coding-standards、standards、guidelines、conventions、style、security、commits）、明示的に applyTo: "**" が指定されている場合と同様に、常に適用可能として扱います。ファイル名だけでは判断が難しい場合は、ファイルの冒頭数行を読んでください。「すべての PR が遵守しなければならない」旨のルールを示す内容（つまり、特定のファイル形式に限定されず、プロジェクト全体に適用される内容）は、ファイル名にかかわらず一般的な指針です。
• フロントマターのないファイルが一般向けか、特定範囲向けかをどうしても判断できない場合は、含める方を選んでください。誤って含めても追加のガイドライン確認が発生するだけですが、誤って除外すると、レビューから実際のプロジェクト標準が知らないうちに漏れるため、より重大です。

一致した指示ファイルのみを読み込みます。どの指示ファイルを関連すると判断したか、その理由とともにレビュー草稿に記載してください（1 行で十分です）。これにより、想定で済ませず、リポジトリごとに判断の根拠を監査可能にします。

5. 構造化されたレビュー案を作成する

差分、指示、ClickUp チケットのコンテキスト、既存のコメントを分析し、スペイン語で構造化されたフィードバックを作成します（下記の「レビューの目標」を参照）。

既存のコメントは、重複を避けるだけでなく、不確実な点を解消するために活用してください。 指摘事項として挙げる前に、$WORKDIR/comments.json と $WORKDIR/inline_comments.json を確認してください。

• 過去のコメントですでに、一見不自然な点が意図的である理由が説明されている場合は、再度指摘せず、関連があれば以前のやり取りを参照してください。
• 過去のコメントで同じ懸念が挙げられており、現在の差分でも未解決の場合は、新たな指摘として提示する代わりに、「以前コメントしたとおり…」と参照できます。
• 実際に問題かどうか確信が持てない場合（たとえば、意図的なプロジェクト規約の可能性がある不慣れなパターンなど）は、推測する前に、過去のコメントですでに解決済みかどうかを確認してください。

ClickUp チケットのコンテキストを使って実装を検証してください。 $WORKDIR/clickup_summary.txt が存在し、チケットのデータが含まれている場合：

• 要件を理解するため、チケットの説明を読んでください。
• 変更対象となるルート／モジュールを確認するため、「Alcance」（スコープ）セクションを確認してください。
• PR が期待どおりに実装されているか確認するため、「Resultado esperado」（期待される結果）を確認してください。
• 「Replicar」（再現手順）セクションがある場合は、PR が説明されている問題を修正しているか確認してください。
• PR が、明確な根拠なしにスコープに記載されていないファイルを変更している場合は指摘してください。
• 検証ロジックがチケットの説明と一致しているか確認してください（例：大文字と小文字を区別しないメールアドレス検証）。

パターンや重複コードを確認するため、差分外のファイルを範囲を限定して読むことができます。 元の「リポジトリを調べない」という制約は厳しすぎました。「X にすでにあるロジックと重複している」「Y で使われているパターンに従っていない」などの指摘は、推測ではなく正確なものにするため、別のファイルを確認する必要がある場合があります。範囲は次のように制限してください（「ループ防止ガード」も参照）。

• 手順4の指示ファイルと同様に、パスは必ず $REPO_ROOT を基準に解決してください（例："$REPO_ROOT/src/..."）。相対パスのみを指定しないでください。
• 具体的な指摘の判断に実質的な影響がある場合に限り、差分外のファイルを読んでください。全般的な調査のために読むことは避けてください。
• ディレクトリを調べ回るのではなく、関数名／クラス名を対象とした grep／find を優先してください。
• 追加で読むファイルは、レビュー全体でおおむね5つまでにしてください。それを超えて確認する必要がある場合は、それ以上追う価値がない指摘である可能性が高いため、網羅的に確認する代わりに、レビューでは作成者への質問として疑念を述べてください。

対話モードのみ：案をユーザーに提示し、次のように確認してください。

このレビューを PR に投稿してよいですか？（はい／いいえ）

「はい」と答えると、投稿されます。 「いいえ」と答える場合、または変更したい場合は、変更内容をお知らせください。

CI モード：この手順は省略してください。手順6に進んでください。

分析中にインラインコメントの候補を準備しますが、書き込みはまとめて行い、指摘ごとには行わないでください。 インラインコメントの対象となるすべての指摘について（「実用的なコメントの作成」のタグガイドを参照）、対象箇所の差分ハンクを確認している時点で、該当箇所の path／snippet／tag／body を決めてください。ただし、分析中は作業メモにとどめてください。すべてのファイルの分析が完了した後に限り、収集したすべての指摘を、1回の Bash 呼び出しで（1つのヒアドキュメントを使い、1行に1件ずつ）$WORKDIR/findings.jsonl に書き込んでください。このファイルに追記するために、指摘ごとに別々の Bash 呼び出しを行うことは絶対にしないでください。呼び出しのたびにターン数が消費されるため、大規模な PR では手順6（投稿）に進む前に予算を使い果たし、全般的な要約も含め、コメントが1件も投稿されないおそれがあります。これはスタックに関係なく、大規模な PR であればどの言語でも起こり得ます。 行番号は計算せず、代わりに特徴的なsnippetを記述してください。 post_review.shスクリプト（ステップ6）が、snippetを機械的に行番号へ解決します。コメント対象の行にある、最も一意性の高い部分文字列を選んでください。関数やメソッドの呼び出し、文字列リテラル、変数への代入など、そのファイル内に1回だけ出現するものを使います。ファイル内のあちこちに繰り返し出現する}、);、pass、return、nullなどの一般的なトークンだけを使うのは避けてください。特徴が明確であるほど、解決の信頼性が高まります。

複数行の提案ブロックの場合は、範囲の先頭行を指定するstart_snippetを追加してください（最後の行を指定するsnippetもそのまま残します）。スクリプトが両方を解決し、正しい範囲のペイロードを作成します。

すべての指摘をまとめて、一度に書き込んでください（単一の呼び出しで、1行につき1つのJSONオブジェクトを記述するJSONL形式）：

cat > "$WORKDIR/findings.jsonl" << EOF
{"path": "<path/to/file>", "snippet": "<distinctive substring from the exact line>", "tag": "BUG", "body": "[BUG] full comment body here, including any suggestion fence"}
{"path": "<path/to/other-file>", "snippet": "<last line of range>", "start_snippet": "<first line of range>", "tag": "PATTERN", "body": "[PATTERN] another finding's full comment body here"}
EOF

ステップ6に進む時点で、findings.jsonlにはインラインコメント候補の識別情報がすべて揃っています。スクリプトが行番号を解決し、自動的に投稿します。

6. レビューを投稿する

CIモード：確認なしで自動的に投稿します。対話モード：ユーザーの確認後にのみ投稿します。

投稿処理はすべてscripts/post_review.shが実行します。この決定論的なスクリプトは、次の処理を行います。

1. $WORKDIR/findings.jsonl（ステップ5で作成）と$WORKDIR/summary.mdを読み込みます
2. grep -n -Fを使い、各指摘のsnippetを実際の行番号に解決します
3. gh pr commentを使って要約を投稿します（オプションA）
4. gh api POST .../pulls/.../commentsを使って各インラインコメントを投稿します（オプションB）
5. 失敗時には1回再試行し、インラインコメントの投稿にも失敗した場合は、後続の一般コメントに切り替えます
6. 結果を標準出力に報告します

bash "$(dirname "$0")/../scripts/post_review.sh"

終了コード： post_review.shは、フォールバックを含めて成功した場合は0を返します。要約コメント自体を投稿できなかった場合は1を返します。

CIモード： 一般的な要約のみが必要な場合は、POST_REVIEW_DISABLE_INLINE=trueを指定してpost_review.shを実行し、インラインコメントを完全にスキップすることを検討してください。API呼び出しとCIの実行時間を削減できます。

7. クリーンアップ

これは必須の最終ステップであり、レビューを投稿した場合、スキップした場合、実行途中で失敗した場合のいずれでも、必ず実行してください。対象は限定されています。このスキルが実行中に作成した一時ファイルだけを空にしてください。 /tmpにあるほかのものには触れないでください。

for f in "$WORKDIR/meta.json" \
         "$WORKDIR/diff.txt" \
         "$WORKDIR/files.txt" \
         "$WORKDIR/head_sha.txt" \
         "$WORKDIR/comments.json" \
         "$WORKDIR/inline_comments.json" \
         "$WORKDIR/clickup_tickets.txt" \
         "$WORKDIR/clickup_summary.txt" \
         "$WORKDIR/context.env" \
         "$WORKDIR/summary.md" \
         "$WORKDIR/summary_simple.md" \
         "$WORKDIR/summary_fallbacks.md" \
         "$WORKDIR/findings.jsonl"; do
  [ -f "$f" ] && echo "" > "$f"
done

ghによる投稿処理が成功したか失敗したかにかかわらず、完了した後に、これを最後の操作として実行してください。後続のステップで読み込むファイルがあるため、実行の途中でこれらのファイルを空にしてはいけません。$WORKDIR内のほかのファイルをワイルドカード指定で削除しないでください。このスキルが作成したファイルだけを対象にしてください。

レビューの目標

Pull Requestをレビューするシニアコードレビュアーとして対応してください。

次の情報を使用します。

• PRの差分（$WORKDIR/diff.txt）
• PRのメタデータ（タイトル、説明、作成者）
• 利用可能な場合はClickUpチケットのコンテキスト（$WORKDIR/clickup_summary.txt）
• 変更対象ファイルに関連する.github/instructions
• 重複を避けるため、PR上の既存コメント

次の内容を含む、構成化されたレビューをスペイン語で作成してください。

0. 品質スコア

レビューは必ず、PR全体の品質スコアから始めてください。次の形式を厳密に使用します。

## Puntuación de Calidad
⭐⭐⭐⭐ — [Justificación de 1-2 líneas, basada en los hallazgos concretos de las secciones siguientes, no genérica.]

スケール（いずれか1つを選び、PRの実際の状態に最も近い基準を使ってください。スタックを問わず、バックエンド、フロントエンド、インフラなどに等しく適用されます）：

スコア	基準
⭐	バグを引き起こす、または重要なパターンを破壊する
⭐⭐	標準との不整合が複数ある
⭐⭐⭐	機能するが、改善の余地がある
⭐⭐⭐⭐	ベストプラクティスに従っており、軽微な指摘がある
⭐⭐⭐⭐⭐	模範的なコードで、すべての標準に従っている

評価の根拠では、実際に見つかった内容を挙げてください（例：「潜在的なバグが2件あり、テストカバレッジが不足しています」や「プロジェクトのパターンに従っており、命名に関する細かな指摘のみです」）。以下のセクションに根拠を示さず、「よくできています」のような一般的な表現だけを使うのは避けてください。ファイルごとの分析とガイドラインへの準拠状況を確認した後にスコアを決めてください。スコアは指摘に基づいて決まるべきであり、その逆ではありません。

1. 変更の概要

• PRの主な変更点を3～7項目の箇条書きで説明します。

2. ファイルごとのフィードバック

変更された各ファイルについて、次の点を特定します。

• 発生する可能性のあるバグ、または確認済みのバグ。
• 考慮されていないエッジケース。
• パフォーマンス、並行処理、またはセキュリティ上の懸念。

3. ガイドラインへの準拠

ステップ 4 で読み込まれたすべての指示ファイルに照らして準拠状況を確認します。読み込まれた指示ファイルごとにサブセクションを設け、そのファイル固有の名前またはトピックを見出しに使用してください（たとえば、リポジトリに frontend.instructions.md と terraform.instructions.md がある場合は、それぞれを基準にレビューします。リポジトリの指示で実際に定められていない限り、コントローラー／サービス／エンティティ／DTO による分類を想定しないでください）。

4. テストの不足

PR に不足している、または不十分なテストを特定します。 必要に応じて、具体的なテストケースを提案してください。

5. 改善案

次のような、実践的な改善案を提案します。

• 小規模なリファクタリング。
• 命名の改善。
• ヘルパーの抽出。
• モジュール構成の改善。

6. ClickUp チケットのコンテキスト

ClickUp チケットのデータを正常に取得できた場合（つまり、$WORKDIR/clickup_summary.txt が存在し、有効なデータを含んでいる場合）に限り、このセクションを含めてください。

### 6. Contexto del Ticket ClickUp
**Ticket**: [CU-XXXXXXXX](https://app.clickup.com/t/XXXXXXXX)
**Nombre**: [Task name from summary]
**Estado**: [status] | **Prioridad**: [priority]
**Asignados**: [assignees]

**Descripción del ticket**:
[Resumen breve de lo que el ticket solicita, extraído de la descripción]

**Alcance mencionado en el ticket**:
- [Lista de rutas/módulos mencionados en el ticket]
- Verificar que estos archivos/rutas están modificados en el PR

**Resultado esperado**:
[Lo que el ticket espera como resultado]

**Validación**:
- ✅/❌ El PR implementa el resultado esperado
- ✅/❌ Todas las rutas del alcance están cubiertas
- ✅/❌ La validación maneja el caso descrito
- ⚠️ Observaciones adicionales o gaps detectados

チケットが見つからなかった場合、または取得に失敗した場合：

### 6. Contexto del Ticket ClickUp
⚠️ **Ticket no encontrado**: No se pudo obtener la información del ticket CU-XXXXXXXX.
El PR será revisado sin el contexto del ticket.

ブランチ名または PR の説明からチケット ID が見つからなかった場合： このセクション全体をレビューから省略してください。

実行可能なコメントを書く — 解決例を含める

すべての [BUG]、[MIGRATION]、[PATTERN]、[BREAKING] コメントには、問題の修正方法または緩和方法を示すコード例を含めてください。

[MIGRATION] はバックエンド／SQL に限定されません。DB マイグレーション、インフラの状態変更（Terraform/Pulumi）、設定スキーマの変更、キュー／トピックの名前変更、フィーチャーフラグの段階的な導入、フロントエンドのビルド／ルーティングのマイグレーションなど、構造的で元に戻しにくい変更にはどれでも使用してください。具体例は、変更内容に実際に合った言語／形式（SQL、HCL、YAML、JSON、シェル）で記述し、デフォルトで SQL を使わないでください。

悪い例 — 問題だけを指摘（バックエンド／DB の例）：

[MIGRATION] DROP COLUMN にはバックフィルがありません。予防措置として、バックフィルの UPDATE を追加することをおすすめします。

良い例 — 問題 + 具体的な修正（バックエンド／DB の例）：

[MIGRATION] DROP COLUMN の前にバックフィルがありません。DROP の前にバックフィルの UPDATE を追加してください。

UPDATE notifications
SET message_data = (
    COALESCE(message_data::jsonb, '{}'::jsonb) ||
    jsonb_build_object('unitType', unit_type)
)::text
WHERE unit_type IS NOT NULL;

ALTER TABLE notifications DROP COLUMN IF EXISTS unit_type;

良い例 — 問題 + 具体的な修正（インフラの例。バックエンド以外のリポジトリでも同じ原則を適用）：

[MIGRATION] Terraform でこの instance_type を変更すると、リソースがインプレース更新されずに再作成されるため、ダウンタイムが発生します。lifecycle.create_before_destroy を使うか、段階的に移行してください。

resource "aws_instance" "app" {
  instance_type = "t3.large"
  lifecycle {
    create_before_destroy = true
  }
}

上記の2つの例は、異なるスタックに同じタグを適用する例です。実際のリポジトリに合った形式を選び、バックエンド以外の変更に SQL を無理に使わないでください。

指摘の種類ごとのガイド：

タグ	例に含める内容	suggestion ブロック？
[BUG]	修正済みのコードスニペット（修正前／修正後）	修正が機械的で1か所で完結する場合（null チェック、誤った変数、off-by-one）は、使用してください
[MIGRATION]	リポジトリに合った形式で修正後の構造変更（DB マイグレーションには SQL、インフラには HCL/YAML、設定には JSON スキーマなど）を記述し、該当する場合はロールバック／バックフィル戦略も含める	いいえ — ほとんどの場合、判断が必要です（データ量、ダウンタイムの時間枠、デプロイ順序）
[PATTERN]	プロジェクトのパターンに沿ったあるべき姿（リファクタリング後のコード）	いいえ。ただし、変更が簡単でコメント対象の範囲内に収まる場合を除きます
[BREAKING]	利用側の移行戦略（クライアント側のコード例、またはコード例が該当しない場合はリリースノート）	いいえ
[IMPROVEMENT]	具体的な代替案（リファクタリング後のコード、提案するテスト）	小規模で自己完結したリファクタリングの場合のみ
[SECURITY]	脆弱なコード + 安全なバージョン	修正がコメント対象の行だけで完結する場合は、使用してください
[STYLE]	任意 — 変更の説明が非常に簡単な場合のみ	はい — suggestion に最適なケースです

出力ルール

• スペイン語で回答してください。
• 例にはコードブロックを使用してください。
• 具体的で、実行可能な内容にしてください。
• 一般的な称賛より、具体的な指摘を優先してください。
• 問題がない場合は、その旨を明示し、理由を説明してください。
• レビューは、gh を使って PR コメントまたはインラインコメントとして投稿してください。
• ClickUp のチケット情報がある場合は、PR がチケットの要件と期待される結果を満たしているか、明示的に検証してください。

ループ防止ガード（厳格な制限）

• PR の差分以外を読むことが許可されるのは、ステップ 5 で説明されている制限付きの方法（特定のパターン／重複に関する指摘を検証するため、追加で読むファイルは約 5 件までに制限し、閲覧よりも対象を絞った grep を優先）に限ります。一般的な調査に利用してはいけません。
• タスクの範囲を PR の範囲より広げてはいけません。
• 同じコマンドや推論の手順を繰り返してはいけません。
• PR のメタデータ／差分／コメントと ClickUp チケットの概要は、ステップ 1 で scripts/prefetch.sh によって一度だけ取得します。$WORKDIR 内のキャッシュ済みファイルを再利用し、gh／clickup-cli を直接使って再取得してはいけません。
• 差分が大きい場合（1000 行超）は、このリポジトリでリスクが高い可能性のあるファイルを優先してください。固定のバックエンド層（「services/controllers」など）を決めつけず、実際の変更内容と、読み込まれた指示ファイルで注意が必要とされた箇所（認証／セキュリティ関連のコード、データアクセス／マイグレーション用ファイル、公開 API の契約、インフラの状態など）をもとに判断します。確認を見送ったファイルと、その理由を明示してください。
• 情報が不足している場合は、推測せず制約を明記してください。
• 各ツール呼び出しの試行回数は最大 2 回 です。最初の失敗時には出力／エラーの全文を表示し、失敗理由を説明してください。2 回目も失敗した場合はそこで打ち切って続行し、条件を変えて3回目を試してはいけません。
• インラインコメントは、指摘ごとに最大 2 回 まで試行します（post_review.sh が処理します）。それ以降は一般コメントに切り替えて先に進んでください。
• ClickUp チケットの取得は最大 2 回 まで試行します。それ以降は失敗したことを記録し、ClickUp の情報を使わずに進めてください。
• CI モードでは質問への回答を待ってはいけません。 指示のどこかで人間の回答を待つ必要があるように思われる場合は、作業を止めず、ステップ 1 の MODE= に従った CI モードの既定の動作を優先してください。
• 全体の試行上限：実行全体を通じて、同じ種類の操作（例：インラインコメントの再試行）を約 5 回以上繰り返していることに気づいた場合は、インラインコメントの試行をすべて中止し、概要コメントにその旨を記載して完了してください。
• 指摘ごとに Bash ツールを呼び出して findings.jsonl を作成してはいけません（同様に繰り返しが必要な記録作業も同様です）。分析が完了したら、まとめて 1 回の呼び出しで処理してください。ターン数には厳しい上限があります。大きな PR で指摘ごとに呼び出しを重ねると、ステップ 6（投稿）に進む前に上限に達し、一般的な概要コメントさえ一切投稿できなくなる可能性があります。
• post_review.sh は常に、インラインコメントを試みる前に一般的な概要を投稿します。残りターン数が少なくなった場合でも、インラインコメントがなく概要だけ投稿されていれば実行は成功です。
• どのような状況であっても、終了する前に必ずステップ 7（クリーンアップ）を実行してください。早期終了やエラーの場合でも、作業ファイルを空にする必要があります。
• ステップ 1（scripts/prefetch.sh）は必須であり、どのモードでも必ず最初に実行してください。 REPO／PR／WORKDIR／SHA／TICKET_ID を自分で導き出してはいけません。このスクリプトが唯一の情報源であり、冪等性があるため、判断に迷った場合に再実行しても問題ありません。値を手作業で推測したり計算し直したりすることは、このスクリプトが防ぐための失敗そのものです。

使用例

CI（GitHub Actions。環境変数は設定済みです：GITHUB_REPOSITORY、PR_NUMBER、GITHUB_BASE_REF、CI=true、CLICKUP_TOKEN、CLICKUP_TEAM_ID）：

スキルの SKILL.md を入力として、エージェントを非対話／出力モードで実行します。正確なコマンドは使用するエージェントによって異なります。エージェントは、git、gh、jq、clickup-cli、ls、cat、find、grep、head、mkdir、tr、echo、bash、Read、Write の各ツールを利用できる必要があります。

例（汎用）：

<agent-cli> --print --max-turns 40 < SKILL.md

CI（推奨）： エージェントを呼び出す前に、パイプラインから scripts/prefetch.sh --repo "$GITHUB_REPOSITORY" --pr "$PR_NUMBER" を任意で実行できます。これはエージェントのターン予算外でフェッチエラーを検出し、ジョブをすばやく失敗させるためだけのものです。どちらの場合も、エージェントはステップ 1 の最初のアクションとして同じスクリプトを実行（または問題なく再実行）します。このスクリプトはスキルに同梱され、冪等になるよう設計されているため、別途「高速パス」用のプロンプトを設定する必要はもうありません。これは、平易な文章の指示に従う信頼性が比較的低いモデル（例：リレー経由の非 Claude モデル）を使用するパイプライン向けの想定された統合方法です。これにより、幻覚やコンテキスト値の捏造が発生する可能性を一掃し、トークン使用量を削減できます。

対話型：

• ユーザー：「myorg/myrepo#42 をレビューして」
• ユーザー：「https://github.com/myorg/myrepo/pull/42 をレビューして」
• ユーザー：「現在の PR をレビューして（チェックアウト済みのブランチで gh pr view が動作することを前提とします）」