Communitygithub.com

jcosxgb/graphe

Hermes用のエビデンスグラフスキル:計画、並行調査、懐疑、統合、人間によるゲート。

graphe とは?

Grapheは、Hermesエージェント環境で使用するためのエビデンスグラフスキルであり、1つの重大な質問や提案されたワークフローを「計画 → 並行レーン → 懐疑 → 統合 → 人間ゲート」という5段階のステージに分解して実行します。このスキルは、市場検証、技術選定、運用設計など、弱いエビデンスが無駄な作業につながる可能性がある意思決定において特に有効です。各調査レーンは独立して並行実行され、生成されたクレームはすべてソースと信頼度が紐付けられます。その後、独立した懐疑エージェントがそれらのエビデンスを攻撃し、厳格な検証を経て、最終的な推奨事項は人間の承認を待ってから実行に移されます。非現実的な並列処理や、結果を先取りして報告することを禁止する厳格なルールにより、高品質で信頼性の高いマルチエージェントワークフローを実現します。

対応~Claude Code~Codex CLI~Cursor
npx skills add jcosxgb/graphe

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Graphe — 1つの質問、グラフとして実行

1つの重大な質問または提案されたワークフローを、段階的なエビデンスグラフに変換します:

計画 → 並行レーン → 懐疑 → 統合 → 人間ゲート

このスキルは以下のように明示的に呼び出されます:

/graphe <質問またはワークフロー>

使用するタイミング

ユーザーが、重大な質問、決定、調査、または提案されたワークフローを、独立したエビデンスレーンに分解し、別の懐疑エージェントによって挑戦され、人間の決定ゲートに戻すことを明示的に希望する場合に /graphe を使用します。これは特に、市場検証、技術選定、運用設計、および弱いエビデンスが無駄な作業を引き起こす可能性がある意思決定に役立ちます。通常の質問には暗黙的に有効化しないでください。スラッシュコマンドがオプトインです。

呼び出しはマルチエージェントワークへの意図的なオプトインです。質問が単純に見えるからといって、通常のシングルエージェントの回答に格下げしないでください。

設計原則

  • ジョブを定義する前に、最終的な成果を定義します。
  • グラフを矢印で接続されたジョブとして扱います。矢印は実際の依存関係をエンコードし、共有ノート/結果が状態となります。
  • 品質を実質的に向上させる最小のグラフを構築します。エージェントが多すぎると、ノイズが重複する可能性があります。
  • 偽の待機を削除します。独立したジョブは並行して実行し、依存するジョブは待機します。
  • ワーカーとチェッカーを分離します。リサーチャーは自分の作業を評価しません。
  • 指定された判断基準に対して十分な答えが得られた時点で停止します。
  • ユーザーが再利用可能な証跡を要求した場合、またはワークスペースにすでに研究アーティファクトの規則がある場合は、有用な状態(計画、エビデンス、ソース、懐疑的な判定、および決定)を保持します。
  • オーケストレーションツールはワークフローに従属します。新しい繰り返しグラフの場合は、より重いフレームワークや外部自動化を追加する前に、手動で形状を証明します。

非交渉ルール

  1. シーケンスは厳格です。 懐疑エージェントが終了する前に統合しないでください。人間ゲートの前に推奨事項を実行しないでください。
  2. 調査レーンは読み取り専用です。 ソース、ファイル、システム、公開情報を調査することはできますが、公開、送信、購入、削除、デプロイ、本番環境の変更、または人への連絡を行ってはなりません。
  3. エビデンスはクレームレベルです。 すべての重要な事実に関するクレームには、ソースURL/パス、ソースタイプ、および信頼度が必要です。「サブエージェントがそう言った」はエビデンスではありません。
  4. 一次ソースが優先されます。 公式ドキュメント、ファーストパーティデータ、ソースコード、契約書、直接の顧客エビデンス、または元の記録を優先します。二次エビデンスと推論にはラベルを付けます。
  5. 懐疑エージェントは別のジョブです。 クレームを独立して攻撃し、元のソースを確認し、矛盾を発見し、各クレームをkeep、qualify、またはrejectにマークします。
  6. 生き残ったものだけが統合されます。 拒否されたクレームは、最終推奨事項で事実として表示できません。
  7. 人間が次の行動を選択します。 ゲートにはclarifyツールを使用します。静かにオプションを選択したり開始したりしないでください。
  8. 疑似並列処理は禁止です。 独立したレーンには、1回のバッチdelegate_task(tasks=[...])呼び出しを使用します。並列レーンに対してシーケンシャルなシングルチャイルド呼び出しを行わないでください。
  9. Hermesの非同期委任を尊重します。 バッチがディスパッチされた後は、ポーリングしたり完了を主張したりしないでください。すべてのレーンが終了したときに調査結果が会話に再入力されます。その後、懐疑エージェントを起動します。
  10. 出力は意思決定サイズに保ちます。 統合は1ページの推奨事項であり、各レーンレポートのダンプではありません。

ステージ 0 — 呼び出しを解析する

/graphe の後のテキストを質問として扱います。オプションのモードワードを指定できます:

  • fast: 2レーン、狭いエビデンスパス。
  • standard: 3レーン、デフォルト。
  • deep: 3レーン、より広いソースカバレッジと明示的なフォローアップギャップ。

質問が指定されていない場合は、1つのオープンエンドな明確化を求めます:「グラフとして実行する質問またはワークフローは何ですか?」ターゲットなしで調査を開始しないでください。

ステージ 1 — 計画

親エージェントが計画を所有します。委任する前に、コンパクトなグラフ計画を作成します:

  • 決定/質問 — 1文。
  • 出力基準 — 有用な回答が決定または有効にする必要があるもの。
  • 制約 — 時間、市場、管轄区域、予算、リポジトリ/システム境界、および禁止された副作用。
  • レーン — 2つまたは3つの直交する調査ジョブ。それぞれに明確な質問と停止基準があります。
  • ゲート — 実行が人間の選択を待つことを示します。

ラベルを盲目的に再利用するのではなく、ドメインに適したレーンを選択します。

デフォルトレーンパターン

マーケット/製品/ビジネスに関する質問には、以下を優先します:

  1. 顧客の課題/現在の行動 — ターゲットユーザーが現在どのように問題に対処しているか。直接的なエビデンス、回避策、緊急性、変更意欲。
  2. 競合他社/代替案/経済性 — 誰がすでに解決しているか、代替品、ポジショニング、価格設定、スイッチングコスト、失敗モード。
  3. 流通/実行/制約 — 実際にオーディエンスにリーチする方法、運用の実現可能性、法務/セキュリティの制約、テストコスト。

一般的な調査や技術的な決定には、以下を優先します:

  1. 根拠/現在の状態 — 一次的な事実、要件、システム動作。
  2. 代替案/反証 — 競合するアプローチ、反証となるエビデンス、トレードオフ。
  3. 実行/リスク/検証 — 実装パス、依存関係、失敗モード、安全なテスト方法。

実装ワークフローの場合、ゲートまですべてのレーンを読み取り専用に保ちます。並列エージェントは異なる領域を検査できますが、同じチェックアウトを編集したり、外部副作用を作成したりしてはなりません。

冗長なレーンを避けます。2つのレーンが同じクレームで同じソースを検索する場合は、それらを再設計します。

ステージ 2 — 並行調査

delegate_task を2〜3つのリーフタスクのバッチで1回呼び出します。すべての子に、完全な質問、共有制約、そのレーンのミッション、以下のエビデンス契約、および必要な出力言語を提供します。

親が読み取るフィールドのみを必要とする、寛容なタスクごとの output_schema を使用します:

{
  "type": "object",
  "required": ["lane", "bottom_line", "claims", "gaps"],
  "properties": {
    "lane": {"type": "string"},
    "bottom_line": {"type": "string"},
    "claims": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "claim", "evidence", "source", "locator", "source_type", "confidence"],
        "properties": {
          "id": {"type": "string"},
          "claim": {"type": "string"},
          "evidence": {"type": "string"},
          "source": {"type": "string"},
          "locator": {"type": "string"},
          "observed_or_published_at": {"type": "string"},
          "source_type": {"type": "string"},
          "confidence": {"type": "string"},
          "assumptions": {"type": "array"},
          "caveat": {"type": "string"}
        }
      }
    },
    "contradictions": {"type": "array"},
    "gaps": {"type": "array"},
    "candidate_next_moves": {"type": "array"}
  }
}

レーンエビデンス契約

各レーンは以下を実施する必要があります:

  • 独立して調査する。兄弟レーンと調整しない。
  • アクセス可能な場合は、最新のオリジナルソースを使用する。
  • すべての重要なクレームについて、URL、ファイルパス(行/ページ参照付き)、または直接のレコード識別子を引用する。
  • 安定したクレームIDを割り当て、利用可能な場合は引用、ページ、行、セクション、タイムスタンプ、またはその他のロケーターを含める。
  • 観測された事実、報告されたクレーム、計算、および推論を分離する。
  • 時間に敏感なエビデンスには日付を含める。
  • 矛盾するエビデンスと未知のものを報告し、隠さない。
  • コンテキストが不足している場合は、ブロッカーを報告するか、仮定に明確にラベルを付ける。子は明確化を求めることができず、推測してはならない。
  • 指定された停止基準が満たされたとき、または追加の検索による利益が急激に減少したときに停止する。
  • 外部変更を行わない。

ディスパッチツールがバッチの実行を確認した後、どのレーンがアクティブであるかを簡単に述べます。結果を捏造したり、ポーリングしたりしないでください。

ステージ 3 — 懐疑

統合されたレーンの結果が会話に再入力されたら、それらを安定したクレームIDをキーとするクレーム/エビデンスマトリックスに正規化し、次に新しい1つのリーフ delegate_task を懐疑エージェントとして起動します。元の質問、制約、正規化されたマトリックス、およびすべてのレーン出力を提供します。

懐疑エージェントは以下を行う必要があります:

  1. 最初に、最も影響の大きい意思決定に重要なクレームを攻撃する。
  2. アクセス可能な場合は、引用された元のソースを開いて確認する。引用文字列だけでは不十分。
  3. ソースの品質、最新性、関連性、サンプルバイアス、因果関係の飛躍、隠された仮定、算術、ソース依存、循環的な裏付けをテストする。
  4. 特に、レーン全体にわたって反証と矛盾を検索する。
  5. 各クレームを keep、qualify、または reject にマークし、理由を述べ、該当する場合は欠陥を fatal、material、または minor とラベル付けする。
  6. 事実の誤りと好みの不一致を区別する。
  7. 決定を変える可能性のあるエビデンスと、それぞれの重要な異議を解決できる最小の追加チェックを特定する。
  8. 最大の不確実性を解決する、低コストの次の行動を3つまで推奨する。
  9. 副作用を実行しない。

以下を必要とする出力スキーマを使用します:

{
  "type": "object",
  "required": ["claim_verdicts", "contradictions", "decision_risks", "best_next_tests"],
  "properties": {
    "claim_verdicts": {"type": "array"},
    "contradictions": {"type": "array"},
    "decision_risks": {"type": "array"},
    "best_next_tests": {"type": "array"}
  }
}

懐疑エージェントをディスパッチした後、エビデンス攻撃が実行中であることを述べます。早期に統合したり、ポーリングしたりしないでください。

ステージ 4 — 統合

懐疑エージェントの結果が戻ってきたら、親エージェントはkeepおよび明確に限定されたqualifyクレームのみを使用して1ページの推奨事項を作成します。重要なあいまいさを解決するために必要なソースは再度開きます。サブエージェントの要約は、外部副作用やライブシステム状態の証拠にはなりません。

この正確な構造を使用します:

# 推奨事項

**決定:** <1文>
**信頼度:** <低 / 中 / 高、理由を1行で>

## 理由
- <生き残ったクレーム + 引用>
- <生き残ったクレーム + 引用>
- <生き残ったクレーム + 引用>

## 生き残らなかったもの
- <拒否された、または実質的に弱められたクレーム + 理由>

## 主要なリスクと未知のもの
- <リスク/未知>

## 最善の次の行動
1. <最大の不確実性を減らす最小のテスト>
2. <2つ目のオプション>
3. <3つ目のオプション、有用な場合のみ>
4. パス — 今は行動を起こさない

おおよそ1ページに収まるようにします。インラインでソースをリンクまたは引用します。詳細なレーン資料は、ユーザーが要求した場合にのみ付録に含めます。

ステージ 5 — 人間ゲート

1ページの統合の直後に、シングルセレクトモードでclarifyを呼び出し、4つ以下の選択肢を提示します:

  • エビデンスから導き出された、最大3つの具体的な次の行動。
  • 常に「パス — 今は行動を起こさない」を含めます。

各オプションはchoices配列にのみ配置します。選択肢を質問の散文で重複させないでください。質問:「どの次の行動を承認しますか?」

ユーザーの選択が到着するまで、いかなるオプションも実行しないでください。/graphe の呼び出し自体は、副作用の承認ではありません。選択後:

  • 選択された次の行動と承認された分析範囲を1文で言い換えます。
  • その行動がメッセージの送信、公開、購入、アカウントの変更、デプロイ、ファイルの削除、APIの変更、またはその他の外部副作用を引き起こす場合は、実行前に、正確なターゲット/アカウント/ワークスペース、提案されたペイロード/コマンド/変更、予想されるコストとオーディエンス、元に戻せるかどうか/ロールバック計画、重複防止戦略、検証方法、および未解決のリスクを提示します。通常の安全ルールで必要とされる追加の承認を取得します。
  • 承認された行動のみを実行します。
  • 送信、購入、デプロイ、破壊的なアクション、シークレット、または本番環境の変更には、通常の安全/承認ルールを適用します。
  • 結果のオブジェクトを読み戻すかフェッチし、独立して検証された効果のみを報告します。

失敗およびフォールバック動作

  • レーンが失敗する: 一時的な障害の場合のみ、1回再試行します。それ以外の場合は、残りのレーンで続行し、信頼度を著しく下げます。
  • ソースにアクセスできない: アクセス障害を報告します。欠落したエビデンスをもっともらしい散文で置き換えないでください。
  • レーンが矛盾する: 矛盾を懐疑段階まで保持します。互換性のないクレームを平均化しないでください。
  • 委任が利用できない: 要求されたマルチエージェントグラフを設計どおりに実行できないことを伝えます。明確にラベル付けされたシングルエージェントのフォールバックを提供します。静かに置き換えないでください。
  • 実行中に質問が変わる: 古いグラフを停止し、修正された決定を言い換え、再計画します。無関係なレーンの結果を新しい質問に継ぎ接ぎしないでください。
  • 安全でない、または許可されていないリクエスト: 通常の安全ルールがグラフをオーバーライドします。安全な分析を維持しながら、安全でない部分を拒否または制限します。

品質チェックリスト

人間ゲートを開く前に、以下を確認します:

  • 親が明示的な計画を作成した。
  • 2〜3の独立したレーンが1つの並行バッチで実行された。
  • すべての重要なクレームに追跡可能なエビデンスがある。
  • 別の懐疑エージェントがエビデンスを攻撃した。
  • 拒否されたクレームは推奨事項から除外された。
  • 統合は簡潔で意思決定指向である。
  • ゲートの前に外部副作用は発生しなかった。
  • 人間に具体的な選択肢(「パス」を含む)が提示されている。

関連スキル