Agent Skills by ALSEL
OpenAILLM・AI開発⭐ リポ 6品質スコア 68/100

llm-council

【決定支援】取り返しのつかない重大な決断を、対抗的なAIアドバイザーとの議論を通じてストレステストします。このスキルは、経営判断やビジネス上の重要な選択肢を複数の視点から検証したい場合に活用できます。AIが意図的に反論・異議を唱えることで、あなたの決定の妥当性を徹底的に吟味し、見落としている課題やリスクを浮き彫りにします。

description の原文を見る

[Decision Support] Use when pressure-testing irreversible, high-stakes decisions with adversarial AI advisors.

SKILL.md 本文

Codex互換性に関する注記:

  • Codexではリポジトリスキルを $skill-name で呼び出します。このミラーコピーは従来のClaudeの /skill-name 参照を書き直します。
  • このCodexミラーでの計画ガイダンスには $plan-hard スキルを優先してください。
  • タスクトラッカーの必須要件: ワークフローまたはスキルステップを実行する前に、すべてのステップのタスク追跡を作成/更新し、進捗の変化に応じて同期させてください。
  • ユーザー質問プロンプトはCodexでユーザーに直接質問することを意図しています。
  • Claude固有のモード切り替え指示が表示される場合は、無視してください。
  • 厳密な実行契約: ユーザーが明示的にスキルを呼び出す場合、そのスキルプロトコルを書かれたとおりに実行してください。
  • サブエージェント認可: スキルがユーザーによって呼び出されるか、AIが検出され、そのプロトコルがサブエージェントを必要とする場合、そのスキル起動はそのタスクに必要な spawn_agent サブエージェントの使用を認可します。
  • ユーザーが明示的に最初に逸脱を承認しない限り、プロトコルステップをスキップ、並べ替え、マージしないでください。
  • ワークフロースキルの場合、リストされた各子スキルステップを明示的に実行し、ステップバイステップの証拠を報告してください。
  • 必要なステップ/ツールがこの環境で実行できない場合は、停止して適応する前にユーザーに質問してください。
<!-- CODEX:PROJECT-REFERENCE-LOADING:START -->

Codexプロジェクト参照の読み込み(フックなし)

Codexはクロードフックベースのドキュメント注入を受け取りません。 コーディング、計画、デバッグ、テスト、またはレビューの場合は、このルーティングを使用してプロジェクトドキュメントを明示的に開いてください。

常に読む:

  • docs/project-config.json (プロジェクト固有のパス、コマンド、モジュール、ワークフロー/テスト設定)
  • docs/project-reference/docs-index-reference.md (完全な docs/project-reference/* カタログへのルート)
  • docs/project-reference/lessons.md (常時のガードレールとアンチパターン)

状況別ドキュメント:

  • バックエンド/CQRS/API/ドメイン/エンティティの変更: backend-patterns-reference.md, domain-entities-reference.md, project-structure-reference.md
  • フロントエンド/UI/スタイリング/デザインシステム: frontend-patterns-reference.md, scss-styling-guide.md, design-system/README.md
  • 仕様/テストケース計画またはTC マッピング: feature-docs-reference.md
  • 統合テスト実装/レビュー: integration-test-reference.md
  • E2Eテスト実装/レビュー: e2e-test-reference.md
  • コードレビュー/監査作業: code-review-rules.md および変更されたファイルに基づく上記のドメインドキュメント

すべてのドキュメントを無差別に読まないでください。docs-index-reference.md から開始し、タスクに関連するファイルのみを開いてください。

<!-- CODEX:PROJECT-REFERENCE-LOADING:END -->

[重要] マスト アテンション: マルチオプション、難しい決定を逆転させ、高リスクな意思決定にのみコンシェルジュを使用してください。決して些細な、事実的な、可逆的な、または単一オプションの質問にはコンシェルジュを使用しないでください。 [重要] マスト アテンション: 5人のアドバイザーを並行で、次に5人の新しいピアレビュアーを並行で、その後チェアマンの統合を実行してください。 [重要] マスト アテンション: コード/アーキテクチャの主張には証拠が必要: file:line、グラフトレース、または明示的な「不十分な証拠」。

LLMコンシェルジュ

クイックサマリー

目標: コストの高い誤った選択のための対抗的な意思決定支援。5人のアドバイザーが独立して分析し、5人の新しいレビュアーが匿名で批評し、チェアマンが最終判定とレポート成果物を作成します。

ワークフロー: ゲート → フレーミング → 5つの並行アドバイザー → 匿名化された5つのレビュアーピアレビュー → チェアマン統合 → ペアのHTML/MDレポート。

主要ルール:

  • マスト アテンション: より安いはしごを使う: $why-review$plan-validate$llm-council
  • マスト アテンション: .code-graph/graph.db が存在する場合、コード/アーキテクチャの質問をグラフトレースしてください。
  • 決して、以前のアドバイザーの回答が後のアドバイザーに漏れないようにしてください。並行スポーンが必須です。
  • 常に、5未満の使用可能なアドバイザー応答が返される場合、判定を低下としてマークしてください。
  • 常に、編集を .agents/skills/llm-council/SKILL.md に同期してください。

フェーズ 0: コンシェルジュゲート

アドバイザーの前に実行します。

ゲート必須falseの場合のルート
マルチオプション>=2つの実行可能なパス単一オプションの根拠 → $why-review
逆転が難しいアーキテクチャ、スタック、価格設定、採用、不可逆的なリファクタ可逆的な選択 → 直接回答
実際のリスク誤った判断が >=1週間、金銭、信頼、または戦略的ポジションがかかる低リスク → 直接回答
マルチアングル価値反対/第一原理/上升/外部/実行ビューが答えを変える事実的/単一領域 → 直接回答

ゲートが失敗した場合、失敗したゲートとより軽いルートを述べてください。決して「markdownを使うべきか」をコンシェルジュしないでください。

良いプロンプト: 価格設定モデル、ポジショニング角度、ピボット、採用対自動化、アーキテクチャの賭け、高リスク起動、不可逆的なリファクタ。 悪いプロンプト: 事実検索、シンプルなイエス/ノー、コンテンツ生成、要約、バグ修正、パッケージアップグレード、ルーチンリファクタ、1つのgrepで決定可能な何か。


アドバイザーの次元

各アドバイザー = 思考の次元、ペルソナコスチュームではない。1つの強力な角度のみ。

アドバイザー思考
反対派何が失敗するか? どの仮定が計画を殺すか?
第一原理思考家何の問題を解決しているか? どの仮定を再構築する必要があるか?
拡張主義者どのような上升、隣接する機会、過小評価されたパスが欠けているか?
外部者コンテキストのない人を何が混乱させるか? どのような専門用語が価値を隠すか?
実行者月曜日の朝に何が起こることができるか? 最速の検証済みパス?

緊張関係: 反対派 対 拡張主義者、第一原理 対 実行者、外部者が両方を根拠づける。


ステップ 1: 質問をフレーミングする

ユーザーが「これをコンシェルジュして」と言ったら、充実させてからフレーミングしてください。

コンテキスト探索予算: <=30秒; 2-3の高信号ファイルを読む。

検索順序: CLAUDE.md / AGENTS.md; docs/project-config.json; docs/project-reference/project-structure-reference.md; マッチング docs/project-reference/*{domain-entities,backend-patterns,frontend-patterns,code-review-rules}*; docs/specs/; memory/; ユーザー参照ファイル; plans/reports/council-*; ドメインデータ(価格設定 -> 収益、アーキテクチャ -> サービスマップ、テックスタック -> 依存関係)。

コード/アーキテクチャゲート: 質問が既存のコード、サービス、ファイル、またはブラストラッドを参照する場合、フレーミングの前に実行してください:

python .claude/scripts/code_graph trace <key-file> --direction both --json

.code-graph/graph.db が存在しないか、質問がコード以外の場合のみグラフをスキップしてください。

フレーミングされた質問に含める: 中心的な決定、ユーザーコンテキスト、ワークスペースの証拠、リスク、制約、既知の未知。あなたの意見を追加しないでください。プロンプトが曖昧な場合のみ、正確に1つの明確化質問を尋ねてください。


ステップ 2: アドバイザーラウンド

5つのアドバイザーすべてを同時にスポーンしてください。各アドバイザーはアイデンティティ、フレーミングされた質問、証拠ルール、出力制約を取得します。

あなたはLLMコンシェルジュの[アドバイザー名]です。
思考スタイル: [表からのアドバイザーの次元]

質問:
---
[フレーミングされた質問]
---

証拠ルール:
- コード/アーキテクチャの主張には `file:line`、グラフトレース、または「不十分な証拠がまだあります」が必要です。
- 既存のコードコンテキストが必要な場合は、次を実行してください:
  python .claude/scripts/code_graph trace <file> --direction both --json
  python .claude/scripts/code_graph connections <file> --json
- ブラストラッド、呼び出し元、下流への影響についてはトレース出力を引用してください。
- 信頼度: 95-100% 完全トレース | 80-94% メインパス | 60-79% 部分的 | <60% 推奨しません。
- 推測しないでください。代わりに不足している証拠に名前を付けてください。

割り当てられた角度から応答してください。直接的、具体的、設計上はバランスを取っていません。他のアドバイザーが他の角度をカバーしています。
長さ: 150-300語プラス1行の信頼度宣言。プリアンブルなし。

ステップ 3: ピアレビューラウンド

応答を収集してください。ランダム化/匿名化をレスポンスA-Eにしてください。5人の新しいレビュアーを並行でスポーンしてください。

LLMコンシェルジュをレビューしています。

質問:
---
[フレーミングされた質問]
---

匿名化された応答:
**レスポンスA:** [レスポンス]
**レスポンスB:** [レスポンス]
**レスポンスC:** [レスポンス]
**レスポンスD:** [レスポンス]
**レスポンスE:** [レスポンス]

回答:
1. 最強の応答? なぜ?
2. 最大の盲点? 何が欠けているか?
3. 5人全員が見逃したことは?

レスポンスを文字で参照してください。具体的にしてください。200語未満。

ステップ 4: チェアマン統合

チェアマンは元の質問、フレーミングされた質問、匿名化解除されたアドバイザー応答、ピアレビュー、匿名化マップを受け取ります。

あなたはLLMコンシェルジュのチェアマンです。5人のアドバイザー + ピアレビューを最終判定に統合してください。

質問:
---
[フレーミングされた質問]
---

アドバイザー応答:
**反対派:** [レスポンス]
**第一原理思考家:** [レスポンス]
**拡張主義者:** [レスポンス]
**外部者:** [レスポンス]
**実行者:** [レスポンス]

ピアレビュー:
[すべてのピアレビュー]

正確な構造を作成してください:
## コンシェルジュが同意する場所
[独立した収束; 高信頼度信号。]
## コンシェルジュが衝突する場所
[真の意見の相違。両側を提示し、なぜ合理的なアドバイザーが意見の相違を説明するかを説明してください。]
## コンシェルジュが見つけた盲点
[ピアレビューを通じてのみ出現。]
## 推奨事項
[明確な直接的な推奨事項。「状況による」ではない。]
## 最初にやるべき1つのこと
[単一の具体的な次のステップ。]

直接的にしてください。曖昧にしないでください。1つの視点から利用できない明確さを提供してください。

品質ループ: チェアマンが必要なセクションを見逃したり、低下した品質状態を無視したり、サポートされていないコード主張を行った場合は、新しいチェアマンプロンプトで修復してください。最大3つの修復ラウンド。その後、不足している証拠でエスカレートしてください。


ステップ 5: レポート成果物

両方のファイルを書いてください。存在しない場合は plans/reports/ を作成してください。

plans/reports/council-{YYMMDD-HHMM}-{kebab-slug}.html
plans/reports/council-{YYMMDD-HHMM}-{kebab-slug}.md

{YYMMDD-HHMM} = セッション日時。{kebab-slug} = 3-6語の質問記述子。両方がプレフィックスを共有します。決してワークスペースルートまたは docs/ に成果物を書かないでください。

HTML: 自己完結型インラインCSS、トップの質問、目立つチェアマン判定、同意/不同意ビジュアル、折りたたまれたアドバイザー応答、折りたたまれたピアレビューハイライト、フッタータイムスタンプ/トピック、プロフェッショナルなブリーフィングスタイル、生成後に開く。

マークダウン トランスクリプト: 元の質問、フレーミングされた質問、すべてのアドバイザー応答、すべてのピアレビュー、匿名化マッピング、チェアマン統合。


出力形式

コンシェルジュ完了。

レポート: plans/reports/council-{YYMMDD-HHMM}-{kebab-slug}.html
トランスクリプト: plans/reports/council-{YYMMDD-HHMM}-{kebab-slug}.md

判定: [チェアマン推奨事項の1-2文]
最初のアクション: [単一の次のステップ]

ワークフロー統合

ホストスキルからのオプトインエスカレーションフック。決してバグ修正、リファクタ、マイグレーション、パッケージアップグレード、または test-* ワークフローに配線しないでください。

ホストスキルモードデフォルトゲート
architecture-design## 次のステップ 後に常にオファースキップユーザーが選択
tech-stack-research## 次のステップ 後に常にオファースキップユーザーが選択
why-reviewアクティブな計画/PBIフロントマターで条件付きゲートが発火時にエスカレート8-ORゲート
prioritizeランキング出力で条件付きゲートが発火時にエスカレートRICE トップ2 15%以内、MoSCoW タイ、またはステークホルダー不同意

why-review ゲートスキーマ

任意のフィールドが真の場合、ゲートが発火します。不在のフィールドはデフォルトで非発火; ゲートはフロントマターでオプトイン、決してオプトアウトしません。

フィールド慣例発火条件
cross_service_impactNONE / PARTIAL / FULL値 != NONE
breaking_changesbooltrue
complexitylow / medium / high / criticalhigh, critical, または story_points >= 13
new_frameworkbooltrue
irreversiblebooltrue
security_criticalbooltrue
performance_criticalbooltrue
cost_highbooltrue

ホストプロンプトコピーは、より安いランク付けを引用する必須です: $why-review, $plan-validate, $llm-council


終了のリマインダー

マスト アテンション重要 マルチオプション、難しい逆転、高リスク決定にのみコンシェルジュを使用してください。 マスト アテンション重要 5人のアドバイザーを並行でスポーン、その後5人の新しいピアレビュアーを並行でスポーン、その後チェアマン統合。 マスト アテンション重要 コード/アーキテクチャの主張に証拠が必要: file:line、グラフトレース、または明示的な「不十分な証拠」。 マスト アテンション重要 5未満の使用可能なアドバイザー応答が返される場合、判定を低下としてマークしてください。 マスト アテンション重要 ペアのHTML + マークダウン成果物を plans/reports/ に書いてHTMLを開いてください。 マスト アテンション重要 すべての正規の編集を .agents/skills/llm-council/SKILL.md に同期してください。

反合理化:

回避反論
「この決定は重要に感じる」ゲート: マルチオプション、難しい逆転、実際のリスク、マルチアングル価値。
「1人のアドバイザーがそれを処理できる」コンシェルジュの価値は独立した角度 + 匿名ピアレビューから来ます。
「順次スポーンはより簡単」順次スポーンは独立性を汚染します。並行スポーンが必須です。
「4人のアドバイザーで十分」欠けた角度が判定品質を変えます。低下としてマークしてください。
「証拠は遅くなります」サポートされていないコード/アーキテクチャ主張は推測です。グラフ/ファイル証拠を使用するか、不十分な証拠と述べてください。
<!-- CODEX:SYNC-PROMPT-PROTOCOLS:START -->

フックレスプロンプトプロトコルミラー(自動同期)

ソース: .claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須 重要 マスト クリティカル。理由は何であれスキップしないでください。

  1. 検出: プロンプトをワークフロータログと照合
  2. 分析: ベストマッチワークフローを検出し、カスタムステップの組み合わせがより適切かどうかを評価
  3. 質問(必須形式): この構造で直接ユーザー質問を使用:
    • 質問: 「どのワークフローをアクティブ化しますか?」
    • オプション1: 「[ベストマッチワークフロー] をアクティブ化(推奨)」
    • オプション2: 「カスタムワークフローをアクティブ化: [step1 → step2 → ...]」(1行の根拠を含む)
  4. アクティブ化(確認時): 標準の場合 $workflow-start <workflowId> を呼び出し、カスタムステップを手動でシーケンス化
  5. タスク作成: すべてのワークフロー ステップのタスク追跡
  6. 実行: 各ステップに順序を従う [CRITICAL-THINKING-MINDSET] 批判的思考、順序立った思考を適用。すべての主張には追跡証拠が必要、信頼度 >80% で行動 ハルシネーション防止原則: 推測をなぜかのように提示しないでください — すべての主張のソースを引用し、不確実性を自由に認め、出力にエラーがないか自己チェック、独立して相互参照、自身の信頼に懐疑的 — 証拠根のない確実性はすべてのハルシネーションの根 AI注意原則(第一性-最新性): 長いプロンプト/プロトコルの最初と最後の両方に3つの最も重要なルールを配置し、命令順守が長いコンテキストウィンドウを生き残ります。

学んだ教訓

教訓

[クリティカル] 難しく得られたプロジェクトデバッグ/アーキテクチャルール。マスト アテンション: 仮説を立てたりコードを書く前に適用してください。

クイックサマリー

目標: 既知の失敗パターンの再発を防ぐ — デバッグ、アーキテクチャ、命名、AIオーケストレーション、環境。

トップルール(常に適用):

  • マスト アテンション: コード層の仮説の前にすべての前提条件(構成、環境、DB名、DI登録)を検証してください
  • マスト アテンション: 責任層を修正してください — シンプトムサイトに呼び出し元固有の防御コードを決して修正しないでください
  • マスト アテンション: 並行非同期 + repo/UoW には ExecuteInjectScopedAsync を使用してください — 決して ExecuteUowTask を使用しないでください
  • マスト アテンション: 目的で命名してください、内容で命名しないでください — メンバーを追加すると強制的に名前変更 = 抽象化が壊れています
  • マスト アテンション: サブエージェント結果を各ファイル後に段階的に永続化してください — 最後にバッチ処理しないでください
  • マスト アテンション: Windows bash: Pythonエイリアスを検証してください (where python/where py) — 決して python/python3 が解決すると仮定しないでください

デバッグとルート原因の推論

  • [2026-04-11] 全体的優先: コード前に環境を確認。 失敗 → すべての前提条件をリストアップ(構成、環境変数、DB名、エンドポイント、DI登録、認証情報、権限、データ前提条件) → 各々を証拠で検証(grep/cat/クエリ) コード層の仮説の前。最悪のウサギの穴: 最寄りのレイヤーにダイビング、バグは他の場所にある — 例えば、「同期タイムアウト」のデバッグに数時間、実際の原因: テストアプリセッティングが間違ったDBを指す。最安チェック優先。
  • [2026-04-01] 「誰の責任?」を修正前に聞く。 トレース: 呼び出し元のバグ(データが間違っている)か呼び出し先(データ処理が間違っている)? 責任層を修正してください — シンプトムサイトをマスキング実際の問題で修正しないでください。
  • [2026-04-01] エラーサイトではなくデータライフサイクルをトレース。 データに従う: 作成

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
duc01226
リポジトリ
duc01226/EasyPlatform
ライセンス
MIT
最終更新
2026/5/10

Source: https://github.com/duc01226/EasyPlatform / ライセンス: MIT

本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: duc01226 · duc01226/EasyPlatform · ライセンス: MIT