القائمة
曖昧な判断、トレードオフ、go/no-go のコールのために 4 声の評議会を招集します。複数の有効なパスが存在し、選択する前に構造化された不一致が必要な場合に使用します。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
キャプチャ、診断、抑制されたリカバリ、内省レポートを用いた、AI エージェント障害向けの体系的なセルフデバッグワークフローです。
リポジトリ認識の並列レビューパスを使用してスキル、コマンド、ルール、フック、その他を DAILY と LIBRARY のバケットに分類することで、特定のリポジトリ向けにエビデンスに基づく ECC インストールプランを構築します。フルバンドルをロードするのではなく、プロジェクトが実際に必要とするものに ECC をトリミングすべき場合に使用します。
対象リポジトリの既存の統合パターンに正確に合わせて新しい API コネクタやプロバイダを構築します。第二のアーキテクチャを発明することなく、もう一つの統合を追加する場合に使用します。
Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
ECC 向けのエビデンスファーストな自動化インベントリと重複監査のワークフローです。何かを修正する前に、どのジョブ、フック、コネクタ、MCP サーバー、またはラッパーがライブ、壊れている、冗長、または欠落しているかをユーザーが知りたい場合に使用します。
CodeTour の `.tour` ファイルを作成します。実際のファイルと行のアンカーを持つペルソナ対象のステップバイステップウォークスルーです。オンボーディングツアー、アーキテクチャウォークスルー、PR ツアー、RCA ツアー、および構造化された「これがどのように動作するか説明して」というリクエストに使用します。
| name | council |
| description | 曖昧な判断、トレードオフ、go/no-go のコールのために 4 声の評議会を招集します。複数の有効なパスが存在し、選択する前に構造化された不一致が必要な場合に使用します。 |
| origin | ECC |
曖昧な判断のために 4 人のアドバイザーを招集します:
これは曖昧性の下での意思決定のためのものであり、コードレビュー、実装計画、またはアーキテクチャ設計のためではありません。
以下の場合に council を使用します:
例:
| council の代わりに | 使用するもの |
|---|---|
| 出力が正しいかどうかの検証 | santa-method |
| 機能を実装ステップに分解 | planner |
| システムアーキテクチャの設計 | architect |
| バグやセキュリティのコードレビュー | code-reviewer または santa-method |
| 単純な事実質問 | 直接回答 |
| 明白な実行タスク | そのまま実施 |
| 声 | レンズ |
|---|---|
| Architect | 正確性、保守性、長期的な影響 |
| Skeptic | 前提への挑戦、簡素化、仮定の打破 |
| Pragmatist | shipping スピード、ユーザーインパクト、運用上の現実 |
| Critic | エッジケース、下振れリスク、失敗モード |
3 つの外部の声は質問と関連するコンテキストのみで新鮮なサブエージェントとして起動されるべきであり、進行中の完全な会話は渡しません。それがアンチアンカリングメカニズムです。
判断を 1 つの明示的なプロンプトに還元します:
質問が曖昧であれば、council を招集する前に 1 つの明確化質問をします。
判断がコードベース固有の場合:
判断が戦略的/一般的な場合:
他の声を読む前に、以下を書き下します:
合成が外部の声を単に反映しないように、最初にこれを行います。
各サブエージェントが受け取るもの:
プロンプト形式:
You are the [ROLE] on a four-voice decision council.
Question:
[decision question]
Context:
[only the relevant snippets or constraints]
Respond with:
1. Position — 1-2 sentences
2. Reasoning — 3 concise bullets
3. Risk — biggest risk in your recommendation
4. Surprise — one thing the other voices may miss
Be direct. No hedging. Keep it under 300 words.
ロールの強調:
あなたは参加者であり合成者でもあるため、以下のルールを使用します:
以下の出力形式を使用します:
## Council: [short decision title]
**Architect:** [1-2 sentence position]
[1 line on why]
**Skeptic:** [1-2 sentence position]
[1 line on why]
**Pragmatist:** [1-2 sentence position]
[1 line on why]
**Critic:** [1-2 sentence position]
[1 line on why]
### Verdict
- **Consensus:** [where they align]
- **Strongest dissent:** [most important disagreement]
- **Premise check:** [did the Skeptic challenge the question itself?]
- **Recommendation:** [the synthesized path]
携帯電話画面でスキャン可能に保ちます。
このスキルから ~/.claude/notes その他の shadow パスにアドホックなノートを書き込まないでください。
council が推奨を実質的に変更した場合:
knowledge-ops を使用して、適切な永続的な場所にレッスンを保存する/save-session を使用する判断が実際に何かを変える場合にのみ永続化します。
デフォルトは 1 ラウンドです。
ユーザーが別のラウンドを望む場合:
santa-method — 敵対的検証knowledge-ops — 永続的な判断差分を正しく保存search-first — 必要に応じて council 前に外部参考資料を集めるarchitecture-decision-records — 判断が長期的なシステムポリシーになる場合に結果を形式化質問:
Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
考えられる council の形:
価値は全会一致ではありません。価値は、選択する前に不一致を可視化することです。