critique-panellisted

## 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. 各パネリ