Prometheus

Prometheus は何をしますか？

LLMエージェント向けプロンプトを作成するための汎用的なメタプロンプティングフレームワーク。Claude Code、Gemini CLI、Cursorなど、あらゆるエージェントCLIおよびCLI以外の用途で動作します。7つのプロンプト形状すべてをカバーします。エージェントループ、ワンショットタスク、ワークフローチェーン、サブエージェントプロンプト、システムペルソナ、LLM-as-Judgeグレーダー、エージェントチーム。

このフレームワークは、古典的なコンテキストエンジニアリング（Anthropicの「適切な抽象度」、「最小実行可能トークンセット」、「ルールよりも例」）と、量子意味論の原理（プロンプトは演算子であり、キー検索ではないこと、順序付けは構造的であること、曖昧さは機能であること、組み合わせは加算的ではないこと）に基づいています。

このスキルを使用するタイミング

ユーザーがLLMエージェント向けのプロンプト設計作業を開始するときにトリガーします。よくある表現：

• 「[タスク]のためのプロンプトを書くのを手伝って」
• 「[目的]のためのシステムプロンプトが必要」
• 「[プロジェクト]用の[Claude Code / Gemini CLI / など]のプロンプトを設定して」
• 「[評価]用のLLM-as-Judgeプロンプトを設計して」
• 「[X]を行うサブエージェントを構築中で、その指示を書くのを手伝って」
• 「[タスク]のためのエージェントループをブートストラップして」

以下の場合はトリガーしないでください：単純なQ&A、コード補完リクエスト、またはユーザーが後でその答えを得るためのプロンプトではなく、答えそのものを求めているタスク。

核となるスタンス：プロンプトは演算子である

このフレームワークの根底にある、量子意味論の文献からの最も深いリフレーミング：プロンプトはモデルから「正しい」答えを「抽出」するものではありません。プロンプトは、モデルの意味状態の変換を通じて答えを構築する演算子です。 プロンプトの各セクションは、特定の解釈を増幅し、他の解釈を抑制し、基底状態を混合して新しい読み取りを生み出す行列です。

これは比喩ではありません。設計実践を変えます：

• 「適切なキーワード」を見つけるのではなく、変換を設計します。
• 順序付けは構造的です。演算子は可換ではありません。
• セクションの組み合わせは加算ではなく、干渉を生み出します。
• 各命令は情報を破壊します。それに応じて設計してください。
• ユーザー意図の曖昧さは欠陥ではなく、重ね合わせです。

このスキルはこれらの原理を具体的に、風味としてではなく適用します。運用マッピングについては references/quantum-principles.md を、セクションを演算子としてのカタログについては operators/ を参照してください。

3つの動作モード

フレームワークは、ユーザーが持ち込むものに応じて3つのモードのいずれかで動作します。

ゼロからのモード（デフォルト）。 ユーザーがタスクを説明します。フレームワークはプロンプトを生成します。6つのフェーズ：形状推論 → 適応型インタビュー → 演算子設計ドラフト → 監査 → 正直な評価 → 提供。

リファクタリングモード。 ユーザーは既存のプロンプトを持っており、それを監査、修正、または書き直したいと考えています。6つのフェーズ（1R〜6R）：受け取りと解析 → 意図回復インタビュー → モード選択（監査 / 対象を絞ったリファクタリング / 全面的な書き直し） → モードの適用 → 正直な評価 → 提供。完全な手順は references/refactor-mode.md に文書化されています。

管理モード。 ユーザーが既存の管理エージェントパッケージを指し示し、そのライフサイクル全体にわたって実行したいと考えています（実行の監視、ゴール違反の分析、適応、内部状態を維持したままの停止と再起動）。これは、エージェントのプロンプトに対するMAPE-Kループ（監視/分析/計画/実行）であり、演算子代数を通じて表現されます。完全な手順は references/manage-mode.md にあります。パッケージレイアウト、ライフサイクル、台帳については references/agent-state.md を参照してください。

モード検出。 ユーザーの最初のメッセージにプロンプトが貼り付けられ、その後に監査、改善、修正、またはリファクタリングのリクエストが続く場合は、リファクタリングモードを自動検出します。「このプロンプトをリファクタリングして」「このプロンプトを監査して」「このプロンプトの何が問題か」のような直接的な呼び出しは、すぐにリファクタリングモードをトリガーします。ユーザーが既存のエージェントパッケージパスを指し示したり、それに対してライフサイクル動詞を呼び出したりする場合（「このエージェントを管理して」「適応サイクルを実行して」「なぜエージェントが後退したのか」「エージェントを再起動して」）は、管理モードを自動検出します。検出が曖昧な場合（プロンプトが貼り付けられたがリクエストが不明確）、一度だけ質問します。「プロンプトを確認しました。リファクタリングしますか、それとも別のタスクのコンテキストとして使用していますか？」リファクタリングまたは管理のシグナルが明確でない限り、デフォルトはゼロからのモードです。

3つのモードはインフラストラクチャ（形状カタログ、演算子カタログ、監査チェックリスト、検証器仕様）を共有しますが、異なる手順を実行します。特に管理モードは、新しい分析機構を追加するのではなく、サブルーチンとしてゼロからのモードとリファクタリングモードの機構を再利用します（監査チェックリスト、リファクタリングサブモード、実行間検証器）。ゼロからの手順は以下に続きます。リファクタリング手順は references/refactor-mode.md、管理手順は references/manage-mode.md にあります。

ゼロからの手順（6フェーズ）

フェーズ1 — ルーティングではなく形状推論

ユーザーのタスク説明は、重ね合わせ状態の意味状態として到着します。ルーティングの質問をしないでください。 すでに存在するシグナルから形状を推論します（§2.4 ベイズサンプリングの精神に則って）。

1. ユーザーのリクエストを注意深く読みます。シグナルを抽出します：動詞（構築 / ドラフト / 分類 / グレード / 評価 / 抽出 / 要約）、名詞（システム / ドキュメント / パイプライン / ループ / エージェント / ペルソナ / ジャッジ）、スケールマーカー（ワンショット vs 継続的、マルチターン vs シングルコール）、ツールの言及（Claude Code、Gemini CLI など）。

2. もっともらしい形状に対する内的事後分布を生成します。形状カタログは templates/shape-catalog.md にあります。まだ確定しないでください — 重みを保持します。

3. 2位の形状が明らかに離れている場合にのみ、最も高い事後質量を持つ形状を選択します。2つ以上の形状が互いに約30%以内にある場合、推論は曖昧なので、1つのターゲットを絞った明確化質問で曖昧さを解消する必要があります。オープンなルーティング質問ではなく、上位2つの形状の間の強制選択として質問を表現します。

4. ドメイン（エンジニアリング / 研究 / ライティング / 運用 / 汎用）は二次軸であり、形状とは直交します。同じ方法で推論します。ワンショットのライティングプロンプトとエージェントエンジニアリングプロンプトは両方ともこのフレームワークを適用しますが、セクションの内容が異なります。

5. 同じパスでハードリーズニングシグナルを検出します。 数学的/論理的タスク、マルチステップ計画、コード分析またはデバッグ、複数制約問題、またはユーザーがモデルが最初の試行で失敗したことに言及するタスクは、references/reasoning-patterns.md にある認知ツールスキャフォールドが、オプションの拡張ではなく、ドラフトにおける構造的デフォルトであるべきというシグナルです。2つ以上のシグナル + ツール呼び出しランタイム → 引用された経験的結果が適用されるレガシーおよびストロングティアでスキャフォールドを含めます。フロンティアティアでは、スキャフォールドはM5トリガーによるオプションであり、デフォルトではありません — references/reasoning-patterns.md §ティアゲーティングを参照してください。

6. 基板の能力ティアを推論します — 形状とドメインに直交する3番目の軸であり、ランタイムの答えから読み取ります：フロンティア（ランタイムの最新の高命令追従モデル）、ストロング（現在の主流モデル）、レガシー（古いか小さいモデル）。不明 → ストロングを想定します。ティア条件：フェーズ3のデフォルト演算子強度（references/quantum-principles.md の原則9 — 規範的演算子は高命令追従基板に過剰投影する）、スキャフォールドトリガーしきい値（上記ポイント5）、プリフィルの可用性、フェーズ6の推論制御パラメータガイダンス。

フェーズ2 — 適応型インタビュー（演算子認識）

インタビュー自体が、ユーザーの意図に適用される一連の演算子です。§5.6によれば、すべての質問は曖昧さを不可逆的に崩壊させます。あまり速く崩壊させないでください。

実施ルール：

• 質問は合計6つまでのハードキャップ。これにはフェーズ1からの曖昧さ解消質問も含まれます（3つの普遍的な質問 — デプロイコンテキストが明らかな場合はスキップ可能 — プラス形状固有の質問2〜3つ）。ハードキャップ。共著パス（形状3、6、7）は、templates/interview-branches.md の実施ルールに従い、この制限の対象外です。
• 1ターンにつき1つの質問。 複数質問のターンはより浅い回答を生みます。
• ユーザーのリクエストにすでに回答がある質問はスキップします。 再質問は情報を破壊する繰り返しです。
• 質問の順序が重要です（§2.3、§5.1）。最初に最も広い枠組みの質問をし、次に制約を絞り込み、最後にフォーマットを尋ねます。最初の質問は、後続のすべての質問が動作する部分空間を設定します。
• 質問のコストが低く、間違えるコストが高い場合は、重ね合わせを保持します（§4.1）。アーキテクチャレベルの選択（形状、オーディエンス、ツール）については保持します。戦術的な選択（ファイル名、大文字小文字）についてはデフォルトを設定して先に進みます。

形状ごとの質問バンクは templates/interview-branches.md にあります。すべての形状に共通する2つの質問：

1. ツール / ランタイム。 「このプロンプトはどこで実行されますか？（Claude Code、Gemini CLI、OpenAI API、汎用LLM、その他？）」メモリファイルの命名とツール固有の機能に影響します。
2. 完了定義 / 成功基準。 「プロンプトが機能したことはどのようにわかりますか？雰囲気ベースではなく、確認可能なものである必要があります。」フェーズ5の自己評価のためのルーブリックを提供します。

インタビューの最後に要約の崩壊を行います：推論した形状、収集した主要な制約、指定されていないものに割り当てるデフォルトを述べます。ドラフトの前に、ユーザーに一度上書きの機会を与えます。これは意図的な測定ステップ（§1.2）です — ユーザーが崩壊に異議を唱えられるように明示的にします。

フェーズ3 — 演算子設計ドラフト

ドラフトはセクション埋めではなく、演算子設計（§5.3）です。含める各セクションについて：

1. セクションが変換する基底状態を特定します — どの解釈が増幅、抑制、または混合されるべきか？
2. 強度を選択します — 強い演算子（ペルソナ、ハード制約）は積極的に投影します。弱い演算子（スタイル設定、フォーマット）は他のほとんどの演算子と可換です。デフォルトの強度を基板ティアに合わせて調整します（原則9）： フロンティアティアでは、列挙よりも簡潔な一般的な指示を好み、強意語（「CRITICAL」、「MUST」、繰り返しの禁止）は実証された失敗モードがある制約のために予約します。レガシーティアでは、より強い投影が適切な場合がよくあります。破壊的能力を持つロールのための機能ロックダウンは、すべてのティアで階層化され、明示的に保たれます — その正当性はリスクであり、基板の弱さではありません。
3. 演算子シーケンスに配置します（§5.1に従って）：最初に最も広い枠組み、次に絞り込み、最後にフォーマット。
4. 隣接セクションとの干渉を確認します（§5.4） — 組み合わせが意図した、または意図しない創発的な振る舞いを生み出しますか？

形状固有の骨組みには templates/shape-catalog.md を使用します。セクションごとの演算子の説明（各セクションが何を増幅/抑制/混合するか、その強度、可換性）については operators/ を参照してください。完全な形状選択を必要としないタスク（小さく、明確に定義された、単一目的）の場合、templates/minimum-viable-prompt.yaml がフォールバックスキャフォールドです — 6つのスロット（システム / 指示 / 例 / 制約 / 状態 / クエリ）のみ。

構造化された分解がモノリシックな連鎖思考よりも優れている、推論を多用するタスクについては、references/reasoning-patterns.md を参照してください — これには認知ツールサブパターン（IBMチューリッヒ、AIME2024で+16.6%）と、それを選択した形状内でいつ呼び出すかが文書化されています。

プロンプトの出力が人間に表示されるのではなく、別のLLMエージェントによって消費される場合（形状4のサブエージェント/ツールプロンプトと形状6のLLM-as-Judgeで最も一般的）、references/agent-consumability.md を参照してください。消費者がエージェントである場合、出力設計は変わります：grep可能な失敗マーカー、集約ファースト構造、冗長ログ付きのコンパクトな標準出力、決定論的だが異なるサンプリング、そして可視の状態遷移。

形状7（エージェントチーム）の場合、トポロジーの選択は基礎的であり、ロールごとのドラフトに先立って行わなければなりません。4つの標準トポロジー（オーケストレーター-ワーカー、並列化-セクショニング、並列化-ボーティング、評価者-最適化）について、その演算子プロファイル、ロール定義、一般的な失敗モードを含む詳細は references/agent-team-topologies.md を参照してください。最初にトポロジーを選択し、次に各ロールのプロンプトを個々の形状の骨組みを使ってドラフトし、その後ロール間の一貫性を監査します。

すべての形状に適用される普遍的なドラフトルール：

• 適切な抽象度。 実行可能なほど具体的で、モデルが適応できるほど柔軟。脆弱なハードコーディングと曖昧なごまかしは、二重の失敗モードです。
• 最小実行可能トークンセット。 特定の失敗モードに対処したり、具体的な振る舞いを可能にしたりしないものはすべて削除します。各トークンは注意力を消費します。
• ルールよりも例。 ルールが重要な場合、動作例を書いてください。例は、抽象的な指示を固定する重要な演算子です。しかし、例には独自の曖昧さの表面があります — 例の中の暗黙の判断は、モデルがリバースエンジニアリングするルールになります。例を出荷する前に、自問してください：この例は、意図したこと以外に何を暗黙的に教えているか？わからない場合は、よりクリーンなケースに置き換えてください。
• 演算子の強度によるセクションの順序付け。 最も強い演算子を最初に。
• 失敗モードを「してはいけないこと」として。 それぞれが、具体的な結果を伴う特定の既知の鋭いエッジに対処します。一般的な警告はトークンの無駄です。

フェーズ4 — 監査（構造的および量子的）

references/audit-checklist.md の監査チェックリストを実行します。チェックリストは、古典的なコンテキストエンジニアリングチェック（適切な抽象度、最小トークンセット、例の存在、長期ホライゾンサポートの耐久性）と、量子意味論的チェックを組み合わせたものです：

• 演算子カタログが完全であること。 各セクションには明確な増幅/抑制/混合プロファイルがあります。「飾り」のセクションはありません。
• 順序付けが最適化されていること。 最も強い演算子を最初に。隣接するセクションを入れ替えて「これで振る舞いは変わるか？」と自問することでテストします。はいの場合、非可換ペアを正しく特定しています。
• 干渉がチェックされていること。 2つのセクションが相互作用する可能性が高い場合（例：ペルソナ + トーン + フォーマット）、その組み合わせが意図した創発的な振る舞いを生み出し、望ましくない打ち消しを起こさないことを確認します。
• 情報が保存されていること。 重要なコンテキストは可能な限り早く読み込まれます（より多くの投影に耐えます）。曖昧なままにすべきものはそのようにフラグが立てられ、事前に崩壊されません。
• 測定を認識していること。 プロンプトが事前に事前登録された検証器ステップの測定対象になる場合（references/verifier-specification.md を参照）、フェーズ6の検証器が実際にアクセスできる出力を生成することを確認します。

保存されている監査実行を再利用するには、references/audit-checklist.md の「監査の再利用」セクションを参照してください。

フェーズ5 — 正直な評価

提供前に、プロンプトを出力に対して自己評価します。フェーズ2で収集した完了定義を使用します。フェーズ4の監査が合格したことを確認した上で、以下を評価します：

1. 堅牢性。 記述されたタスクの最も可能性の高いエッジケースに対してプロンプトが機能する可能性はどのくらいか？エッジケースを想定した場合の失敗モードは？
2. 効率。 フェーズ3の最小トークンセットルールを適用した後でも、トークンをさらに削減できますか？フィラー句、過度に慎重な言い換え、実際の失敗モードに対処しない冗長な禁止事項を探します。
3. 透明性。 初心者のユーザーは、このプロンプトが何をするかを説明なしに理解できますか？重要でないと思われるものを、重要であるかのように扱っていませんか？モデルが行うべきトレードオフについて、暗黙の前提を埋め込んでいませんか？
4. 正直さ。 プロンプトができないと約束していることはありますか？そもそもプロンプトで解決すべき問題ですか？よりシンプルな解決策（ルールベースのチェック、ハードコードされたロジック、プロンプト以外の方法）の方が適切ですか？もしそうなら、そのように述べてください。

正直な評価に合格しなかったプロンプトは提供しないでください。やり直すか、不合格の理由を正直にユーザーに伝えてください。

フェーズ6 — 検証と提供

評価に合格したプロンプトに対して、references/verifier-specification.md に従って検証器を出荷します。検証器は以下のことを行います：

1. プロンプトが最初の実行で機能したかどうかを確認します。
2. プロンプト内の特定された負荷のかかる制約についてテストします。
3. すべての失敗モードにわたって、パス/失敗をログに記録します。
4. プロンプトが失敗した場合にユーザーに通知し、修正手順を提案します。

検証器の出荷は、形状と基板に条件付けられます。references/verifier-specification.md には、プロンプトの失敗モードごとに事前作成された成功基準が含まれています。

形状に基づくユースケース固有のトークン数のガイダンスも提供してください。一般的なガイドラインは references/verifier-specification.md の形状別トークン数テーブルにあります。

推論制御パラメータ（temperature、top_p）については、references/verifier-specification.md の推論制御パラメータセクションを参照してください。基本的なルール：高temperatureは創造的なタスク（アイデア、革新）、低temperatureは決定論的なタスク（分類、抽出、事実検索）に適しています。汎用的なタスク（コーディング、分析、計画）では、ほとんどの場合デフォルトで中程度のtemperatureが適切に機能します。

提供形式

各フェーズの出力をユーザーに表示します。最終的な提供には以下を含めます：

1. プロンプト自体。 ユーザーがコピーして使用できる状態で。
2. 簡単な使用手順。 プロンプトの使用方法（該当する場合、ファイルに保存するか、CLIに貼り付けるか）。
3. 検証器の仕様。 組み込みの検証器がある場合。
4. プロンプトが失敗した場合のトラブルシューティングのヒント。

関連リファレンス

• templates/shape-catalog.md — 7つのプロンプト形状すべてのテンプレート
• templates/minimum-viable-prompt.yaml — 最小限のプロンプトスキャフォールド
• templates/interview-branches.md — 形状固有の質問バンク
• operators/ — 演算子カタログ（セクションごとのamplify/suppress/mixプロファイル）
• references/quantum-principles.md — 量子意味論の運用マッピング
• references/audit-checklist.md — 構造的および量子的監査チェックリスト
• references/verifier-specification.md — 検証器の仕様と成功基準
• references/reasoning-patterns.md — 認知ツールスキャフォールドと推論パターン
• references/agent-consumability.md — エージェント消費可能な出力設計
• references/agent-team-topologies.md — エージェントチームトポロジー
• references/refactor-mode.md — リファクタリングモードの手順
• references/manage-mode.md — 管理モードの手順
• references/agent-state.md — 管理モードのパッケージレイアウトと状態
• effects/prompt-effects.yaml — 効果カタログ（量子効果のエンジニアリングマッピング）