Imported from ts-76/skills-boilerplate (.agents/skills/plan-review/SKILL.md). Install upstream with npx skills add ts-76/skills-boilerplate --skill plan-review. Copyright stays with the author.

Plan Review — 多角的・敵対的チャレンジ

複数の専門家の視点から計画やスペックをレビューし、盲点を見つけ、前提を批判し、実装前の思考を改善する。

使用場面

• 計画やスペックの実装にコミットする前
• ユーザーが自身の考えをストレステストしたい時
• スコープが狭すぎる、または広すぎると感じる時
• ローンチや重要な機能の前
• 複数のアプローチから選択する時

レビュー対象の種別

レビュー対象に応じて各視点の重みを調整:

対象が不明な場合は全視点を均等に実行。

レビュー視点

各視点は独立して実行することも、組み合わせることもできる。ユーザーにどの視点を希望するか確認するか、デフォルトですべて実行する。

1. CEO / Founder レビュー

第一原理から問題を再考。計画が正しい問題を解いているかを批判する。

問うべき質問:

• これが今構築すべき最も重要なものか？
• 10点満点のバージョンはどうなるか？ この計画はそこからどれくらい離れているか？
• この計画はどの前提の上に成り立っているか？ その前提は有効か？
• もしこれが完璧に成功しても、本当に重要な指標は動くか？
• 反対のアプローチはないか？ 逆のアプローチの方が良い可能性は？
• スコープは適切か？ 慎重すぎる？ 野心的すぎる？ 過剰装飾ではないか？

出力: go/bigger/smaller/smaller-first の推奨を含むスコープ評価。

2. エンジニアリングレビュー

技術的な実現可能性、複雑さ、リスクを評価する。

問うべき質問:

• どのステップに隠れた複雑さの爆弾はないか？
• 依存関係の連鎖は正しいか？ フェーズを並列化できるか？
• 障害時の挙動は？ エラー処理は十分か？
• パフォーマンス、セキュリティ、スケーラビリティの懸念はないか？
• 技術的負債を導入していないか？ それは正しい種類の負債か？
• テストの前提は妥当か？ テストは実際にリグレッションを検出できるか？

出力: 重要度評価と緩和策の提案を含むリスクレジスタ。

3. デザインレビュー

ユーザー体験とユーザビリティの視点から評価する。

問うべき質問:

• ユーザーの視点でハッピーパスをトレースできるか？ 流れは自然か？
• エラー状態はどうなるか？ 丁寧に処理されているか？
• ローディング状態、空状態、エッジケースは計画に含まれているか？
• メンタルモデルはシンプルか、内部構造の理解をユーザーに求めていないか？
• 不要なステップや認知的負荷はないか？

出力: 具体的な摩擦ポイントを含む UX ギャップリスト。

4. 開発者体験レビュー

計画が良い DX（開発者ツール/API/ライブラリ向け）を生み出すかを評価する。

問うべき質問:

• Hello World までの時間は？ 最初の成功までのステップ数は？
• API は直感的か？ ドキュメントなしで正しい使い方を推測できるか？
• ユーザーが目にするエラーメッセージは？ それは役立つか？
• オンボーディングパスは明確か、それとも行き止まりにぶつかるか？
• エコシステムの規約に合致しているか？

出力: 所要時間の見積もりと摩擦ポイントを含む DX スコアカード。

レビューモード

フルレビュー（デフォルト）

選択されたすべての視点を実行し、統合レポートを作成する。

ラピッドチャレンジ

迅速確認: 各視点から最も重要な質問を上位3つ選び、問い、2分で結果を報告。ユーザーが素早い健全性チェックを求めた場合に使用。

敵対的カウンシル

複数の有効な道が存在する曖昧な決定の場合:

• 計画を3つの敵対的視点に提示: 懐疑主義者、実用主義者、批判者
• 各視点は独立して自らの立場から論じる
• 決定の推奨として統合

これは曖昧さの中での意思決定に使う — 複数の信頼できる道が存在し、明確な勝者がいない場合。

使い分けの基準:

• フルレビュー/ラピッド: レビュー対象が1つの明確な方向性を持っている場合。品質の確認が目的。
• Adversarial Council: 2つ以上の有効なアプローチが存在し、どちらを選ぶか決めかねる場合。決断の支援が目的。ユーザーが「AかBで迷っている」「どちらとも言えない」と表明した場合に使用。

出力フォーマット

# 計画レビュー: [機能名]

> Date: YYYY-MM-DD
> Plan reviewed: [パスまたは説明]

## 概要

[2〜3文の全体的評価]

## 重要な問題

[先に進む前に修正が必要な事項]

## 警告

[問題になり得るがブロッカーではない事項]

## 提言

[計画をより良くする改善案]

## 各視点の所見

### CEO レビュー

[所見 + 推奨]

### エンジニアリングレビュー

[所見 + 推奨]

### デザインレビュー

[所見 + 推奨]

### DX レビュー

[所見 + 推奨]

## 判定

[ ] **Approve** — 実装可能
[ ] **Revise** — 重要な問題に対応後、進行
[ ] **Rethink** — 根本的な問題の再検討が必要

**Revise 判定後の再レビュー基準:**

- Critical 項目が3つ以下 → 修正後に対象箇所のみ **スポット再レビュー**（全体レビュー不要）
- Critical 項目が4つ以上 → 修正後に **フル再レビュー**（他領域への波及確認）
- Warning 以下の修正 → 再レビュー不要、実装に進んでよい

## 推奨される次のステップ

[所見に基づく具体的なアクション]

ヒント

• 与えられた計画にとって最も重要な視点から始める（インフラならエンジニアリング、UIならデザイン、戦略ならCEO）
• 問題を見つけるだけでなく、修正案も提案。すべての指摘には推奨される解決策を含める。
• 指摘事項を優先順位付け: critical（修正必須）> warning（修正推奨）> suggestion（あれば良い）
• 率直に。フィードバックに砂糖衣をかけても計画は改善しない。
• 計画がすでに十分に solid な場合は、無理に問題をでっち上げず、そう明確に述べる。