setup-ci-review

name: setup-ci-review description: GitHubリポジトリにPRレビュー自動化を対話的に導入する。Claude Code workflow / Greptile / Checkov gating を bootstrap。生成時に既存ファイルは無断上書きしない（既存インストールの更新は update-existing.sh で対応）。「PRレビュー導入」「setup-ci-review」「コードレビューCI bootstrap」「CIレビュー setup」等で起動。 user-invocable: true allowed-tools: - Read - Write - Bash(ls:) - Bash(mkdir:) - Bash(gh:) - Bash(git:) - Bash(jq:) - AskUserQuestion - Bash(~/.claude/skills/setup-ci-review/scripts/)

実行手順

1. リポジトリ確認

gh repo view --json nameWithOwner,defaultBranchRef

失敗した場合は git remote get-url origin でフォールバック。

REPO_NAME は owner/repo 形式に正規化する（SSH / HTTPS / .git 付きの揺らぎを吸収）。以下で一括処理可能:

REPO_NAME=$(gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null \
  || git remote get-url origin | sed -E 's#^git@github\.com:##; s#^https?://github\.com/##; s#\.git$##')

REPO_NAME は完了ガイド表示や workflow の identity 確認用途のみで、テンプレート置換には使わない（テンプレートは相対パスで動作する）。

2. ユーザーへの質問（1回でまとめて聞く）

AskUserQuestion で以下を一度に収集する。往復を最小化するため、1回でまとめて聞く。

• preset: generic / iac
• tier: 対象リポの Tier 分類（1 / 2 / 3、デフォルト 2）。Tier 1=ops/server-config 相当の重要かつ活発なリポ、Tier 2=重要だが PR 頻度が低〜中で初回レビューだけで足りるリポ、Tier 3=スクラッチ/experimental または商用 IaC scanner で重複機能をカバーできるリポ。判定基準は reference.md の「Tier 分類」を参照。Tier 選択がコンポーネント選択と greptileAutoReview の既定値を決める
• コンポーネント選択（multiSelect、Tier ごとのデフォルトを提示）:
  • generic: Claude Code workflow / Greptile（Tier 1/2 はデフォルト選択、Tier 3 はデフォルト未選択）
  • iac: Claude Code workflow / Greptile / Checkov（IaC のみ候補追加。Greptile の選択基準は generic と同じ）
• analyze: コードベースを分析して設定を最適化するか（yes/no）
• model: レビューに使うClaudeモデル（default = action既定 / opus-4-5 / その他、デフォルト default）
• greptileAutoReview: Greptile の Auto-review on new commits を有効化するか（yes/no）。デフォルトは Tier 1 のみ yes、Tier 2/3 は no。理由は 2026-03 の料金改定で 1 アカウントあたり 50 件/月を超えたレビューに $1/件 が追加課金されるため、Tier 1 以外で triggerOnUpdates: true にする費用対効果が薄い（詳細は reference.md の「Tier 分類」と「Greptile 料金改定」を参照）

ユーザーが Tier 3 を選択した場合は、Greptile を deselect した構成で生成する。GitHub App から該当リポを uninstall する手順は完了ガイドで案内する（skill 側からは App 操作不可）。

3. コードベース分析（analyze=yes の場合のみ）

スタックや規約を検出し、生成ファイルをリポジトリに合わせる。

探索対象（存在するもののみ読む）:

• CLAUDE.md / README.md（コーディング規約・プロジェクト概要）
• 言語マニフェスト: go.mod / package.json / pyproject.toml / Cargo.toml（存在確認）
• .github/workflows/（Bash(ls:*) で一覧取得）
• トップレベルディレクトリ一覧（Bash(ls:*) で確認）

分析結果から以下をセットする:

• REVIEWER_ROLE: 検出スタックを反映（例: 「Go/Terraformに精通したシニアエンジニア」）
• REVIEW_CRITERIA: スタック固有の観点を追記（IaC presetの場合はIaC観点カタログと統合）
• Greptile rules.md の <!-- ここにリポジトリ固有の観点を追記 --> 部分: CLAUDE.mdから抽出したコーディング規約で置換
• Greptile files.json の files[]: 重要ファイル・ディレクトリを {path, description, scope?} オブジェクトとして追加（scope 省略時は全レビュー対象）

4. 競合検出

既存ファイルへの無断上書きを防ぐため、生成予定ファイルのパスを引数として ${CLAUDE_SKILL_DIR}/scripts/detect-conflicts.sh を実行する。

出力を読んでユーザーに提示し、既存ファイルがある場合はマージ判断を仰ぐ。 Skillは自動マージも自動上書きもしない（既存設定の意図を判断できないため）。

衝突検出後の動作は .new 退避＋他ファイル継続 が既定フロー。

• 衝突したファイルへは書かない。detect-conflicts.sh が生成した <file>.new プレースホルダに新内容を書き込み、ユーザーに mv <file>.new <file> での適用を委ねる
• その他の非衝突ファイルは通常通り生成して続行する（全停止はしない）
• 注意: <file>.new は detect-conflicts.sh が touch で空ファイルとして先に作成している。Write ツールは未 Read のファイルへの書き込みを拒否するため、.new への書き込み前に一度 Read を挟む

.greptile/ 配下は3ファイル（config.json / rules.md / files.json）を個別に引数に含める。 ディレクトリの存在だけで「スキップ」と判定してはいけない。 .claude/skills/claude-code-review/SKILL.md も個別に競合判定する（他のスキル管理と混在するため、ディレクトリ存在だけで判定してはいけない）。

5. テンプレートの読み込みと変数置換、ファイル生成

${CLAUDE_SKILL_DIR}/templates/ 配下のテンプレートを Read し、以下を置換して Write する。

置換ルール（iteration 検証で曖昧と出た箇所を明文化）:

• {{REVIEW_CRITERIA}} はテンプレート claude-code-review-skill.md 中で ## 役割 と ## 優先度ラベル の間に独立配置されている。置換時はこの「独立ブロック」として扱う:
  • 空文字（generic preset + analyze=no）: プレースホルダを含む行ごと削除。前後に ## 節があるので空行1行は残って構わない（結果的に二重空行になった場合だけ1行に詰める）
  • 本文を入れる（iac preset または analyze=yes）: ## レビュー観点 という独立見出しを付けて差し込む（テンプレ上は ## 役割 → ## レビュー観点 → ## 優先度ラベル の流れになる）。見出しを省略すると直前の ## 役割 節に観点が吸収されて読みにくくなるので、必ず独立見出しを付ける
• analyze=yes で CLAUDE.md から規約を抽出する場合: 原文を引用せず「観点のリスト」に再構成する（CLAUDE.md は数十〜数百行あり原文引用は情報過多になる。3-7 項目の箇条書きに圧縮する）
• {{REVIEWER_ROLE}} 命名規則: 検出スタック名を形容詞化して並べる（例: 「Go/Terraform に精通したシニアエンジニア」「Next.js/TypeScript に精通したシニアエンジニア」「Terraform/GCP に精通したIaCシニアレビュアー」）。単一スタックでも同形式。
• Greptile files.json の scope フィールド: 特定のパスパターンでのみレビュー対象にしたい場合に付ける。デフォルトは省略（全件対象）でよい。例: テストファイルのみの観点は scope: "**/*_test.go" のように限定する
• Greptile files.json の description: 1行・日本語・20〜60文字で「用途と重点確認ポイント」を書く（例: "本番VPC定義。CIDR変更・ピアリング変更は要承認"）
• Write は存在しないディレクトリに書き込めない環境があるため、生成前に mkdir -p .github/workflows .claude/skills/claude-code-review .greptile で事前作成する

--model フラグはテンプレートで claude-opus-4-7 をデフォルト指定している。--model を外すと action のデフォルト（Sonnet）になるため、深いレビューが欲しい場合は Opus を明示する。軽量運用なら --model 行を削除して Sonnet に任せる。

--disallowedTools フラグはテンプレートで Edit,Write,NotebookEdit,Bash(git commit:*),Bash(git push:*),Bash(git checkout:*),Bash(git reset:*),Bash(git rebase:*),Bash(git branch:*),Bash(git tag:*) を指定している。これは Wiz custom rule CIWorkflow-020 対応で必須（後述 Gotcha 参照）。レビューに編集系ツールは不要なので、危険ツールの surface area を明示的に縮める。

生成先（選択されたコンポーネントのみ）:

• Claude Code workflow: .github/workflows/claude-review.yml
• Claude Code review skill: .claude/skills/claude-code-review/SKILL.md
  • claude-code-review-skill.md テンプレートを Read し、{{REVIEWER_ROLE}} / {{REVIEW_CRITERIA}} を置換して .claude/skills/claude-code-review/SKILL.md として Write
  • workflow からは claude-code-review スキル名で呼び出されるため、パスは固定（変更禁止）
• Greptile: .greptile/config.json / .greptile/rules.md / .greptile/files.json
  • IaC preset → config-iac.json を config.json、rules-iac.md を rules.md として生成
  • generic preset → config.json / rules.md をそのまま生成
  • analyze=yesの場合 → rules.md のプレースホルダーを分析結果で置換、files.json の files[] に実際の重要ファイルを {path, description} で追記（公式スキーマ準拠）、config.json の instructions にリポジトリ概要（1〜3文）を埋める
  • analyze=noの場合 → instructions: "{{PROJECT_INSTRUCTIONS}}" の行ごと削除（プレースホルダを残したまま Greptile に送らない）
  • 公式フィールドのみ使用: strictness / commentTypes / triggerOnUpdates / triggerOnDrafts / statusCheck / summarySection / issuesTableSection / confidenceScoreSection / sequenceDiagramSection / ignorePatterns / instructions / rules / disabledRules。updateExistingSummaryComment / updateSummaryOnly / fileChangeLimit は公式ドキュメントに記載がないため追加しない
  • triggerOnUpdates: テンプレートは既定 false（org レベルで OFF と同じ挙動）。ステップ2で greptileAutoReview=yes が選ばれた場合のみ、生成後に .greptile/config.json の該当行を "triggerOnUpdates": true, に書き換える。書き換え例: sed -i '' 's/"triggerOnUpdates": false,/"triggerOnUpdates": true,/' .greptile/config.json（macOS）。書き換えた場合は差分を目視確認する
  • 構造化ルール: IaC preset の config.json には rules[] に id / severity / scope 付きのIaC観点が含まれる。サブディレクトリで一部ルールを無効化したい場合は、そのディレクトリに .greptile/config.json を置いて disabledRules: ["<id>"] を指定する（cascading で親ルールを継承）
  • Provider本体・ライブラリ等の Go/TS/Python コードベース: generic preset を選んで analyze=yes で instructions と rules[] を埋める。IaC preset は **/*.tf スコープなので .tf が存在しないリポジトリでは発火しない
• Checkov: .github/workflows/checkov.yml（IaC preset かつ選択時のみ）

6. SHA-pin 検証

サプライチェーン攻撃対策として、生成した .yml ファイルのパスを引数として ${CLAUDE_SKILL_DIR}/scripts/verify-sha-pin.sh を実行する。

検証対象は「最終的にリポジトリに採用される可能性のある全 .yml」。具体的には:

• 通常生成した .yml（例: .github/workflows/claude-review.yml, .github/workflows/checkov.yml）
• 衝突で .new プレースホルダに書いた .yml も対象（ユーザーが mv *.new で採用する前提のため、検証漏れを防ぐ）

複数 .yml は 1コマンドでまとめて渡す（例: verify-sha-pin.sh a.yml b.yml c.yml）。個別実行は不要。

exit 1 の場合は失敗として報告し、修正を促す。 local action（uses: ./...）と reusable workflow は検証対象外（スクリプト内で除外済み）。

7. 完了ガイド表示

全工程完了後、最終応答テキスト（チャットに返すメッセージ） として以下をまとめて表示する。stdout echo や追加ファイル生成はしない。箇条書きで提示。

• 必要な Secret: ANTHROPIC_API_KEY（リポジトリ Settings > Secrets > Actions）
• Claude Code GitHub App のインストールが必須: https://github.com/apps/claude を開き、対象リポジトリに個別インストールする。workflow 投入だけでは動かず、App が無いと 401 Unauthorized - Claude Code is not installed on this repository で workflow が 3回リトライして失敗する。OAuth 同意が必要なユーザー手動作業
• Tier 3（Greptile を deselect した構成）の場合のみ追加案内: Greptile GitHub App が org にインストール済みの場合、設定ファイルなしでも初回レビューが走る。完全に無効化するには org admin に依頼して該当リポを Greptile App の Repository access から外してもらう（https://github.com/organizations/<org>/settings/installations の Greptile 行 → Configure → Repository access）
• Branch Protection は維持したまま、Claude / Greptile の check を Required Check にしない
• Greptile statusCheck: true は状態表示用。Required Check にすると block 相当になるため注意
• Required review count は 2 以上を推奨（human + AI の 2 Approve 制）: Claude のコンテキスト補正ルールにより「文脈依存P0 + PR本文の申告」でAI Approveに至る経路がある。AI単独マージを防ぐため、Branch Protection で Require a pull request before merging → Required approvals: 2 を設定し、少なくとも1件は human reviewer の Approve を必須にすること
• 生成ファイルの確認を促し、コミット・PR作成はユーザーに委ねる
• 再レビューのトリガー方法を伝える:
  • 自動: 新しいコミットをpushすると synchronize で再レビューが走る（force-push も検出してフルレビューに切り替わる）
  • 手動再レビューが必要な場合は空コミットを push する（git commit --allow-empty -m "re-review" && git push）。issue_comment トリガー (@claude) は Wiz custom rule CIWorkflow-020 対応で削除済み
• 初回 workflow 追加 PR ではレビューがスキップされる（"Action skipped due to workflow validation error"）。動作確認はマージ後の次の PR で行うこと
• 増分レビューは <!-- claude-code-review --> マーカー付きコメントに追記される仕組み。初回は新規コメント、2回目以降は既存コメントに履歴が蓄積される

既存インストールの更新

テンプレート（claude-review.yml / claude-code-review/SKILL.md / .greptile/config.json）を変更した場合、既にこの skill で導入済みのリポジトリには自動では反映されない。scripts/update-existing.sh を使って差分を当てる。

bash ${CLAUDE_SKILL_DIR}/scripts/update-existing.sh /path/to/target-repo
# 差分を目視確認 → y で適用 → ユーザー側で commit & push

# 確認プロンプトをスキップしたい場合
bash ${CLAUDE_SKILL_DIR}/scripts/update-existing.sh /path/to/target-repo --yes

挙動:

• claude-review.yml は最新テンプレートで完全上書き
• SKILL.md は最新テンプレートで完全上書き。ただし REVIEWER_ROLE / REVIEW_CRITERIA は既存ファイルから抽出して保持する（setup-ci-review が analyze=yes で埋めた値は消えない）
• .greptile/config.json は preset を自動判定して config.json / config-iac.json のいずれかで全置換
  • IaC preset 判定: .github/workflows/checkov.yml の有無、または既存 rules[] に iam-no-basic-roles / wif-attribute-condition / iam-use-member-not-binding などのIaC用 rule id が含まれるか
  • .greptile/rules.md / files.json は analyze=yes で埋めた内容を壊さないよう対象外（手動で追随）
• 各ファイルごとに差分を表示して y/N 確認（--yes で省略可）
• コミット・push は行わない

注意:

• 既存 SKILL.md に REVIEWER_ROLE / REVIEW_CRITERIA 以外の手動カスタマイズがある場合、全置換で失われる。差分を必ず目視確認すること
• 抽出ロジックは「あなたは ... です。このPRをレビューします。」パターンと「3. 既存コードとの一貫性チェック ... 」から「## 優先度ラベル」の間で REVIEW_CRITERIA を識別する。SKILL.md の骨格を手動で大きく変えている場合は抽出失敗して WARN を出す（この場合は skip される）
• .greptile/config.json の strictness / ignorePatterns / instructions / rules[] を個別調整している場合、全置換で失われる。差分目視必須
• PR ブランチが古い main 上にいると、そのブランチの SKILL.md は更新前のまま。git rebase origin/main してから再レビューを走らせる必要がある。テンプレート冒頭に rebase ガイドが入っているので Claude 自身も古い PR で rebase を促す

Gotchas

• action バージョンは v1.0.101（38ec876110f9fbf8b950c79f534430740c3ac009）を pin: mcp__github_inline_comment__create_inline_comment は v1.0.94 / v1.0.101 いずれも引き続き使用可能（過去の「v1.0.101 で削除」という記述は誤り）。v1.0.94 で PR branch 上の .claude/ と .mcp.json を base branch から自動 restore する防御が入り、attacker が PR branch でレビュー指示を改ざんする経路を塞いだ。v1.0.101 でも継承されているため、新しい方を pin する。SKILL.md はこの挙動を前提に書くこと（PR branch 上の SKILL.md 改変は効かず base branch の内容が読まれる）
• --max-turns は 50 以上を推奨: SKILL.md が長い（コンテキスト補正ルール / ERROR-WHY-FIX / 追記テンプレート等）と、既定の 30 ターンでは Claude が gh pr review 投稿前に error_max_turns で打ち切られる。最低 50、SKILL.md を大幅に拡張した場合はさらに増やす
• --allowedTools には mcp__github_inline_comment__create_inline_comment を必ず含める。これが無いと Claude が分析だけして何も投稿せず終わるケースがある（display_report: true はworkflow summaryに出すだけでPRコメントには投稿しない）
• --allowedTools の Bash パターンに空白と複数 * を混ぜると Claude CLI の引数解釈が壊れて Could not resolve authentication credentials で fail する。Bash(gh api --method PATCH repos/*/issues/comments/*:*) は動作確認済みだが、新規パターンを増やすときは単体で動作確認する
• 2-pass レビュー（B+C 案）: claude-review.yml の Prepare consistency context step が .claude-review-context.md を生成し、 prompt の CONSISTENCY_CONTEXT_PATH で参照させる。SKILL.md template の「2-pass 順序」セクションで Phase 1 (logic/security) → Phase 2 (consistency) の順序を強制し、Phase 2 で CONSISTENCY_CONTEXT_PATH を Read する。Greptile 選択時もこの context 生成は走らせて構わない（害はない、むしろ補助情報として活用できる）。A 案（matrix で 2 セッションに分割）は ops / server-config 等のクリティカルリポでのみ別 workflow として後付けする
• anthropics/claude-code-action は id-token: write permission が必須。ANTHROPIC_API_KEY 直接認証の構成でも内部で OIDC token を要求するため、未使用に見えても削除してはいけない（削除すると Could not fetch an OIDC token で fail する）。Codex/AI レビュアが「未使用だから削除」と誤指摘することがあるので却下すること
• PR レビューの最終判定は --approve または --request-changes を必須で出す設計。--comment はレビュー状態が「commented」扱いで CI/Branch Protection 連携がしにくいため使わない。P0/P1 なし → --approve、あり → --request-changes。AI による approve を避けたい場合は --comment に差し替えるが、レビュー完了を機械的に判別できなくなる点を受容すること
• Claude Code workflow を追加する初回 PR 自身では Claude のレビューはスキップされる（"Action skipped due to workflow validation error" / セキュリティ対策）。CI status は pass 扱いだがレビューコメントは付かない。動作確認はマージ後の次の PRで行うよう案内すること
• .greptile/ は3ファイルを個別に競合判定。ディレクトリ存在だけでスキップ禁止
• Greptile triggerOnUpdates の既定は false: 2026-03 の料金改定で 1 アカウントあたり 50 件超のレビューに $1/件 が追加課金されるようになり、org レベルで Auto-review on new commits が OFF に切り替えられた（2倍〜3倍に値上がり）。setup-ci-review のテンプレートも追随して既定 false。true に上げるのは WinTicket/ops と WinTicket/server-config のようにプロダクトに重要で追加料金を払う価値があるリポのみ。ステップ2の greptileAutoReview で yes を選んだ場合のみ、生成後に手動書き換えする
• Checkov は IaC preset 選択時のみ候補に出す（Terraform専用）
• 商用 IaC scanner が既に動いているリポジトリには Checkov を入れない: Wiz / Prisma Cloud / Snyk IaC などが CI で動作している場合、Checkov は機能重複でノイズの二重化・baseline / skip_check の二重メンテが発生する。ステップ3（analyze）で .github/workflows/ を確認し、wiz-cli / prisma-cloud-scan / snyk-iac 等の step が存在する、または Wiz IaC Scanner などの status check が既に PR に付いている場合は、ステップ2のコンポーネント選択で Checkov をデフォルト非選択にして、その旨を option の description に明記する（例: 「Wiz IaC Scanner が検出されたため非推奨」）
• verify-sha-pin.sh は生成ファイルのみ対象
• analyze=yesでCLAUDE.mdが存在しない場合はREADME.mdとディレクトリ構造から推定する
• CIWorkflow-020 対応には --disallowedTools も必須: Wiz custom rule CIWorkflow-020 (Workflow should not use AI agents with dangerous tools on external triggers, MEDIUM) は anthropics/claude-code-action の --allowedTools に Bash / WebFetch / WebSearch 等の危険ツールが含まれていると、pull_request トリガー単独でも実測で fire する（2026-06-03 WinTicket/security-check-db PR #24 で確認）。ルール説明は issues / issue_comment / pull_request_target を例示するが、実装は pull_request も外部入力トリガーとして扱う模様。対応として skill template は以下を両方適用する: (1) issue_comment トリガーを採用しない（Poisoned Pipeline Execution 経路の遮断と兼ねる）、(2) --disallowedTools "Edit,Write,NotebookEdit,Bash(git commit:*),..." で危険ツールの surface area を明示剥離する。手動再レビューは空コミット push で代替する
• allowed_bots は default (空) で運用する。dependabot[bot] / renovate[bot] のいずれも入れない。理由: Wiz custom rule 459cd9a5-6932-401a-b31a-f7d9eb6b3c5a (claude-code-action should not use wildcard or dependabot in allowed_bots, HIGH) は dependabot と renovate の両方を Confused Deputy 攻撃ベクトルとして検出する。@dependabot recreate / @renovate run 等のコメントで attacker が bot を perceived actor 化できる経路がある。bot PR への Claude レビューは諦め、Renovate 自身の Release Notes と人間レビューでカバーする方針。WinTicket org は Renovate の minor/patch/digest を automerge、major のみ手動レビュー対象なので便益喪失は限定的。exclude_comments_by_actor: "*[bot]" を併用して bot コメントを Claude のコンテキストから除外する
• 増分レビュー（履歴蓄積）は server リポジトリで実運用されている方式。<!-- claude-code-review --> マーカー検索 → 存在すれば gh api --method PATCH で追記、無ければ新規作成。force-push は git merge-base --is-ancestor で検出してフルレビューに切り替える
• レビュー指示は .claude/skills/claude-code-review/SKILL.md に分離している。Skill invocation は使えない: Claude Code Action v1.0.72 の SDK は組み込み skill（debug / simplify / batch / loop / claude-api）しかロードしないため、Skill tool による claude-code-review 呼び出しは is_error: true で失敗する。回避策として workflow の prompt に「.claude/skills/claude-code-review/SKILL.md を Read で読み込んで指示に従ってください」と書き、ただのマークダウンファイルとして読ませる。レビュー観点・投稿ルールを変更する場合は SKILL.md 側を編集する（workflow の再デプロイ不要）
• concurrency: pull_request トリガーのみの構成では cancel-in-progress: true で問題ない。新コミット push で古いレビューを止める挙動が期待値。過去に issue_comment トリガー併用時は bot 自身のコメントが自己キャンセルループを引き起こすため cancel-in-progress: ${{ github.event_name != 'issue_comment' }} が必要だったが、issue_comment 削除に伴い不要
• SKILL.md の投稿フロー最終ステップを省略する現象: 過去の実測で Claude がサマリコメント投稿後に gh pr review --approve/--request-changes を忘れてタスク完了と判断するケースがあった。GitHub 上のレビュー状態が残らないため、SKILL.md の「PR レビュー判定」セクションは「省略禁止」「必ず最後に実行」と明示的に強調すること（テンプレート済み）
• workflow ファイル変更を含む PR は Claude にレビューさせられない: claude-code-action は PR ブランチの workflow ファイルが main と一致しているか検証する（セキュリティ機構）。差異があると Workflow validation failed で即 fail する。skill template の Detect claude-review workflow changes step が .github/workflows/claude-review.yml の変更を検出して action を skip するため、claude-review.yml 自体を変更する PR でも CI が fail することはない（skip された step は green 扱い）。ただしレビューコメントは付かないので、claude-review.yml を編集する PR は人間レビュー必須
• ユーザーのローカル環境で _gh_ensure_token エラーが出る: gh:1: command not found: _gh_ensure_token は zsh の gh 認証 wrapper の副作用で、コマンド自体は動く。Skill の挙動には影響しない
• Claude Code GitHub App のインストール忘れで CI が 401 で失敗する: workflow 投入後に Claude Review が 401 Unauthorized - Claude Code is not installed on this repository. Please install the Claude Code GitHub App at https://github.com/apps/claude で 3回リトライ失敗するパターン。App インストールは workflow ファイルとは別管理のため、新規リポジトリでは必ず https://github.com/apps/claude から対象リポジトリにインストールする必要がある。完了ガイドで明示するが、ユーザーが見落としやすいので症状を見たら真っ先に疑うこと

詳細は ${CLAUDE_SKILL_DIR}/reference.md を参照（必要時のみ読み込む）。