# Critique Panel

> 提案・設計・計画に対して、複数の異なる視点からの批判的検討を行い、死角と改善余地を可視化する。1人の視点で固まりすぎた判断を揺さぶる場面で使う。

- Skill: `thinkyou0714/critique-panel` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/critique-panel`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/critique-panel/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/critique-panel

---


## Purpose

単一視点・単一最適化による「見えていない盲点」を発見する。
批判的検討をあえて構造化することで、採用・棄却いずれの判断も根拠のあるものにする。

## Use When

- 自分の提案・設計に自信がありすぎる（または不安がある）場合
- 反論・批判を事前に想定しておきたい場合
- 複数のステークホルダーがいて、立場ごとの懸念を整理したい場合
- issue-framing / risk-scan の後にさらに深掘りしたい場合
- 意思決定会議・承認フロー前の最終確認として使う場合

## Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

- **対象**: 批判的検討を行う提案・設計・方針・計画
- **提案者の主張**: なぜこれが最善だと考えているか
- **期待するパネリスト**: 批判してほしい観点・立場（指定がない場合は後述デフォルトを使う）
- **決定期限**: いつまでにこの提案に対して判断を下す必要があるか

## Output Contract

以下の順で出力すること。順序を変えない。

1. **論点**: この提案が内包する批判の核心
2. **根拠**: その論点をそう判断した理由
3. **パネル批評**: 各パネリストからの批判（後述フォーマット）
4. **含意**: パネル批評が示す設計上・戦略上の重要な示唆
5. **改善案**: 批判を踏まえた現実的な改善の選択肢（複数）
6. **代替案**: 提案全体を見直す場合の別アプローチ
7. **判断材料**: 批評を踏まえて「採用 / 修正 / 棄却」を判断するための情報

### パネリスト批評フォーマット

```text
### [パネリスト名] の視点

**批判の核心**: （1〜2文）
**根拠**: （箇条書き）
**最大の懸念**: （1文）
**改善提案**: （具体的な代替案または修正案）
```

### デフォルトパネリスト

指定がない場合は以下の4視点を使う。

1. **ユーザー代表**: エンドユーザー（LAB会員）の視点から使い勝手・価値を批判
2. **技術負債監査役**: 長期的な保守性・スケーラビリティ・技術的リスクを批判
3. **コスト最適化論者**: 工数・運用コスト・ROI の観点から効率を批判
4. **セキュリティ審査官**: 認証・データ・プライバシー・脆弱性の観点から安全性を批判

## Review Lens

- **目的妥当性**: パネリストの批判が、本来の目的に対して有意か
- **範囲の過不足**: 重要な視点のパネリストが抜けていないか
- **中長期リスク**: 現時点では批判が当たらなくても、将来問題になる観点はないか
- **LAB全体との整合性**: LAB の運用・事業方針と批判が整合しているか
- **非エンジニア理解可能性**: パネリストの批判が非技術者にも説明できる言葉か
- **他LLM移植耐性**: パネリスト設定がClaude固有の解釈に依存していないか

## Instructions

1. 対象の提案・設計を読み、「提案者が最も守りたいポイント」を把握する
2. 各パネリストの立場・価値観・優先順位を明確にしてから批判を展開する
3. 各パネリストは「この提案を否定する」立場で一貫して批判する（中立にならない）
4. 批判は「気持ちの問題」ではなく「具体的な根拠・数字・事例」に基づかせる
5. 各パネリストの批判に対して「改善提案」を1つ以上示す
6. パネル批評全体を踏まえて、提案の「守れる部分」と「見直すべき部分」を整理する
7. 「採用 / 修正 / 棄却」の判断材料を人間が選べる形で提示する（AI が断定しない）

## Guardrails

- パネリストの批判を「どうせ問題ない」と打ち消さない
- AI 自身の判断で「採用 / 棄却」を断定しない。パネルは判断材料であり、判断は人間がする
- 批判のための批判（根拠なし）はしない。すべての批判に根拠を添える
- 改善案を1つに絞らない。複数の選択肢を示す
- コスト影響（修正工数・機会損失）を省略しない
- 提案者に都合よくなるようにパネルを誘導しない

## LAB Cross-Check

実行結果に対して以下を確認すること。

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化の観点からの批判が含まれているか |
| データ / 認証 / ログ | — | セキュリティ審査官の批判が十分に機能しているか |
| 実装 / 運用フロー | — | 技術負債監査役の批判が運用現実を踏まえているか |
| 非エンジニア理解可能性 | — | ユーザー代表の批判が実際の会員視点になっているか |
| 会員共有 / 再利用耐性 | — | このパネル設定が他ケースにも転用できるか |
| 他LLM移植耐性 | — | パネリスト定義が Claude 固有の概念に依存していないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

施工AI へ渡す前に以下を確定させること。

- **要件**: 批評を踏まえて修正した最終仕様（変更点を明示）
- **成功条件**: パネルの批判が対応済みとなる基準
- **失敗条件**: 批判が顕在化した場合の判断基準
- **実行範囲**: 修正対象のファイル・機能・DB
- **影響範囲**: 修正が波及する可能性のあるシステム・機能
- **ロールバック方針**: 修正後に問題が起きた場合の戻し方
- **コスト比較**: 「批判を全部対応する」vs「一部受容して進む」のコスト差

## Further Reading

- `issue-framing` skill — 批判対象の論点整理に先に使う
- `assumption-audit` skill — 提案の前提を洗い出してから批判する
- `risk-scan` skill — 批判から見えたリスクをさらに深掘りする
- `tradeoff-analysis` skill — 批判と改善案の間のトレードオフを整理する
- `decision-materials` skill — 批評を踏まえた最終的な判断材料を整理する