Plan-review Gate の Escort 実行手順。Escort sub-agent が自動起動時に使用
Engine が plan-gate フェーズを検知したとき、独立プロセス（claude -p）として起動される Escort skill。
42）VIBE_ADMIRAL_SHIP_ID — この Escort の IDVIBE_ADMIRAL_PARENT_SHIP_ID — レビュー対象の親 Ship IDVIBE_ADMIRAL_MAIN_REPO — Fleet のメインリポジトリ（owner/repo）VIBE_ADMIRAL_ENGINE_PORT — Engine API ポート（デフォルト: 9721）VIBE_ADMIRAL_QA_REQUIRED_PATHS — qaRequired 強制パス（JSON 配列）セットアップ:
PARENT_SHIP_ID="${VIBE_ADMIRAL_PARENT_SHIP_ID}"
REPO="${VIBE_ADMIRAL_MAIN_REPO:-$(git remote get-url origin | sed -E 's#.+github\.com[:/](.+)\.git#\1#' | sed -E 's#.+github\.com[:/](.+)$#\1#')}"
SHIP_ID="$VIBE_ADMIRAL_SHIP_ID"
ENGINE_PORT="${VIBE_ADMIRAL_ENGINE_PORT:-9721}"
QA_REQUIRED_PATHS="${VIBE_ADMIRAL_QA_REQUIRED_PATHS:-}"
Ship の調査ログを確認（コンテキスト理解のため）:
tail -n 200 .claude/ship-log.jsonl 2>/dev/null | grep '"type":"assistant"' | tail -n 20
Issue の全コンテキストを取得:
gh issue view <ISSUE_NUMBER> --repo "$REPO" --json title,body,comments
Plan 記載チェック（即 reject 判定）:
コメント一覧に ## Implementation Plan ヘッダーを含むコメントが存在するか確認する。
gh issue comment <ISSUE_NUMBER> --repo "$REPO" --body "## Plan Review
**Verdict: REJECT**
Plan が issue comment に記載されていません。実装計画を \`## Implementation Plan\` セクションとして issue コメントに投稿してから再度 gate に進んでください。"
curl -sS --fail-with-body http://localhost:${ENGINE_PORT}/api/ship/${PARENT_SHIP_ID}/gate-verdict \
-H 'Content-Type: application/json' \
-d '{"verdict": "reject", "feedback": {"summary": "Plan が issue comment に記載されていません", "items": [{"category": "plan", "severity": "blocker", "message": "Implementation Plan セクションが issue コメントに存在しない"}]}}'
全コメントを確認:
最新の Implementation Plan コメントを読む
qaRequired パスチェック:
QA_REQUIRED_PATHS が設定されている場合、Implementation Plan の「### Changes」セクションに記載されたファイルパスを QA_REQUIRED_PATHS のパターンと突き合わせる。
QA_REQUIRED_PATHS は JSON 配列（例: ["src/components/**", "src/styles/**"]）qaRequired: false と判断している場合 → REJECT する
qaRequired: true → 問題なし、レビュー続行QA_REQUIRED_PATHS が未設定 → チェックスキップ、レビュー続行レビュー:
GitHub コメント → Gate intent → verdict:
Gate API は親 Ship（PARENT_SHIP_ID）に対して実行する。SHIP_ID（Escort 自身）ではない。
8a. GitHub にレビュー結果を記録（verdict より先に実行）:
COMMENT_URL=$(gh issue comment <ISSUE_NUMBER> --repo "$REPO" --body "## Plan Review
<詳細なレビュー>
### qaRequired Path Check
<QA_REQUIRED_PATHS が設定されている場合のみ記載>
- Configured patterns: <パターン一覧>
- Planned files matching: <マッチしたファイル一覧 or "none">
- Plan's qaRequired: <true or false>
- Check result: <PASS or FAIL (with reason)>
**Verdict: APPROVE** (or REJECT)")
gh issue commentの出力がコメント URL になる。この URL を verdict API に渡す。
8b. Gate intent → 8c. Gate verdict: /escort-gate-protocol の手順に従う。
計画レビュー中に Issue スコープ外の大きな問題（設計の欠陥、既存バグ、アーキテクチャ上の懸念等）を発見した場合は gh issue create で新規 issue を起票する。reject 理由にはしない。
gh issue create --repo "$REPO" \
--title "fix: <問題の要約>" \
--body "## 発見経緯
Escort plan-review (Ship #<ISSUE_NUMBER>) 中に発見。Issue スコープ外のため別 issue として起票。
## 問題
<問題の詳細>
---
🤖 Auto-generated by Escort plan-review (boy scout)"
Ship の計画コメントに含まれる qaRequired の判定を以下のルールで検証する。1 つでも該当する場合は qaRequired: true を強制する（Ship の判定が false であっても reject して修正を求める）:
| 条件 | 理由 |
|---|---|
src/components/ 配下のファイルに変更がある | UI コンポーネントの変更は表示に直接影響する |
| 表示値（phase 名、ステータス、ラベル等）のリネーム・変更がある | 表示値の不整合は全コンポーネントに波及する |
STATUS_CONFIG や表示ヘルパー関数に変更がある | バッジ・ステータス表示の源泉データが変わる |
| Store（Zustand）の状態構造に変更がある | UI の表示データソースが変わる |
| 「DB → Engine → Frontend」を貫通する値の変更がある | 全レイヤーの整合性確認が必要 |
背景（PR #641 事例）: planning-gate が
qaRequired: falseと判定した結果、acceptance-test-gate が QA をスキップし、バッジ表示の不具合がそのまま merge された。UI 表示に影響する変更は保守的にqaRequired: trueとすること。