would-agents-actually について
would-agents-actuallyは、構成を固定したエージェントシステムが、定義された行動を実行または回避するかを評価するスキルです。記録されたトレースと環境で確認した結果を区別し、根拠に基づく判定とテスト計画を作成します。
主な機能
- 01エージェント構成と試験条件の固定
- 02結果・トレース・推論の区別
- 03独立した根拠と環境での再確認
- 04定義済み判定ラベルの使用
- 05最小権限のテスト計画作成
活用シーン
- 01エージェントがツール利用タスクを完了するか評価
- 02指定条件下でのエージェントの棄権を検証
- 03本番に近いエージェント行動テストを計画
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ srinitude/ skills --skill would-agents-actuallyインストール後、Claude Code で/would-agents-actuallyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
mise.toml.github/workflows/ci.ymlassets/decision-records.jsonimprovement-contract.jsoninvocation-receipt-template.jsonmise-primitives-catalog.jsonmise-primitives.jsonprimitive-lifecycle.jsonuse-case-contract.jsonverdict-template.mdevals/cases.jsoncontract.mdevals.jsonmanifest.jsonrubric.mdsource-lineage.jsonspeed-budgets.jsontrigger-cases.jsontrigger-queries.jsonexamples/failure-unvalidated.mdhelp.mdverdict-insufficient-evidence.mdreferences/decisions.mdevidence-base.mdframeworks.mdgeneration-contract.mdoutput-template.mdrecent-public-signal.mdresource-and-experiment-design.mduse-case-specificity.md詳細
エージェントは実際に?
固定したエージェントシステムが、明示したタスク、ツール、ポリシー、予算、試行のもとで、定義したアクションを実行するのか、あるいは回避するのかについて、証拠に基づく判定を示します。システムの発言、トレースの記録、環境が証明することを分けて扱います。
コマンド構文
/would-agents-actually help:調査せずに、契約、判定ラベル、必須のシステム固定情報を表示します。/would-agents-actually verdict <agent-action question>:主張を調査し、必要なアクションの証拠を実行または調査したうえで、裏付けのある判定を下し、成果物を検証します。
手順
- アクションを
[a]として定義します。機会またはトリガー、固定したシステム、観測可能なアクションまたは棄権、タスク分布、環境、期間、予算、実際の障害、比較対象、独立した読み戻しを明記します。不明点によって証拠計画が変わる場合に限り、質問を1つだけします。それ以外は前提を明記します。 - モデル識別子とバージョン、プロバイダー経路、プロンプト、ランタイム、プランナー、ルーター、検証器、再試行、フォールバック、ツール、スキーマ、権限、承認ゲート、メモリ、コンテキスト、チェックポイント、環境、依存関係、タスクのサンプリング、予算を固定します。重要な変更があれば、新たなシステム層として扱います。
- 調査や試行の前に、支持、矛盾、不十分な証拠の条件を定めます。対象の結果、対象のトレース、条件を一致させた類似事例、コンポーネントの確認、メカニズムの証拠、推論を分けて扱います。最新の報告や急速に変化するランタイムの挙動が重要な場合は、recent-public-signal.md を読み込みます。
- 判定の根拠となるすべての情報源を、一次記録で検証します。verdict-protocol.md の情報源カードとトレースカードを完成させます。判定または確信度に必要なすべての前提について、独立した2つのチーム、タスクセット、またはデータセットを必須とします。共有するタスク、実行、評価者、言い換えは1件として数えます。
- 外部アクションは、独立した環境の読み戻し後にのみ計上します。計画、最終的な主張、ツール呼び出しの試行、受理されたリクエスト、長いトレースは、結果の証明にはなりません。モデル起因とインフラ起因の診断を分けつつ、運用上の判定には両方を含めます。
- 結果を読む前に参照クラスを定義します。アクション、タスク、期間、ツール、権限、状態、ランタイム、モデルバージョン、環境、評価者、予算、障害、脅威条件、時期を一致させます。モデル名だけを根拠にスコアを他へ適用してはいけません。
- 証拠収集後に frameworks.md を読み込み、機会、選択、試行、受領、状態、制約、検証、停止、再現性、適用可能性を診断します。能力、実行傾向、信頼性、コンプライアンス、レジリエンス、棄権、運用適合性は分けて扱います。
- verdict-protocol.md に従い、
LIKELY、UNLIKELY、UNCERTAIN、INSUFFICIENT EVIDENCEのいずれかを選びます。ライブ調査を利用できない、または禁止されている場合は、UNVALIDATED HYPOTHESISを使用します。実行、トレース、ツール呼び出し、状態変更、評価結果、割合、費用、引用、情報源、URLを捏造してはいけません。 - 最小権限で本番環境に近いテストを設計します。代表的なタスク、ホールドアウト、試行、分母、比較対象、評価者、予算、権限、障害、停止ルール、読み戻し、ロールバック、クリーンアップ、変更する意思決定を事前に定めます。承認済みまたは合成データと、偽の、または取り消し可能な副作用を使用します。
- output-template.md を使って結果をまとめ、インストール済みスキルの外部に保存してから、
mise run validate-verdict --input <verdict.md>を実行します。終了コード0は、成果物が必要な形式を満たしていることを示します。終了コード1は、不完全であることを示します。終了コード2は、コマンドまたは入力パスが誤っていることを示します。 - 重要な各手順の後、クエリ、情報源、システム固定情報、タスクの識別情報、除外した実行、失敗、読み戻し、前提、検証結果を外部の調査ログに追記します。判定の根拠となる情報源、権限、読み戻し、安全制御を検証できない場合は、作業を中止し、不足項目を報告します。
読み込み条件
- ベンチマーク、試験、評価者、またはトランスポートのエビデンスが分析に役立つ可能性がある場合は、evidence-base.md を読み込み、使用前にすべての一次ソースを再確認します。
- 判定を作成する場合は、verdict-template.md を読み込みます。
assets/の外にコピーし、インストール済みのテンプレートは編集しないでください。 - ヘルプコマンドについては help.md、調査済みの判定については verdict-insufficient-evidence.md、システムのピン留めまたはライブ調査が欠けている場合は failure-unvalidated.md を読み込みます。
- 成果物の作成後、
mise run validate-verdictを実行します。バリデーターの契約を変更する場合に限り、mise run tests-test-validate-verdictを読みます。 - 動作、トリガーの境界、または評価ケースを変更する前に、contract.md を読みます。
- このスキルの保守または再パッケージ化を行う場合に限り、generation-contract.md を読み込みます。
注意事項
- コンポーネントのチェックに成功しても、アクション全体が成功したことの証明にはなりません。
pass@k、pass^k、単一実行での成功、アクションの傾向、デプロイの信頼性は、それぞれ異なる問いに答えるものです。- 結果の評価者、トレースの評価者、制約の評価者、インフラストラクチャの評価者は、互いに置き換えることはできません。
- 両方の見方を報告せずに、運用上の分母からセットアップ、依存関係、トランスポート、タイムアウト、権限、レート制限に関する失敗を除外しないでください。
- テストを現実的にするためだけに、認証情報、支払い権限、破壊的なアクセス権、または広範な権限を決して追加しないでください。
- 機微な領域では、定義されたアクションのみを評価します。全体的な安全性、有効性、合法性、受給資格、認可、コンプライアンス、または行動の許可を推測しないでください。
完了条件
[a]で、システム、アクション、機会、タスク、期間、コスト、比較対象、読み戻しを固定します。- 重要な前提はすべて、独立性ゲートを通過します。
- 結果、トレース、制約、評価者の妥当性、インフラストラクチャ、コスト、トランスポートは、それぞれ分けて扱います。
- 試行数、対象となる分母、除外された実行、不確実性、タスクの集中度を明示します。
- 信頼度は、最も弱い前提、評価者、独立性チェック、トランスポートの橋渡しによって上限が決まります。
- 次のテストでは、最小権限、予算、停止ルール、読み戻し、ロールバック、クリーンアップを使用します。
- 重要なソースはすべて、URLが確認できるようにします。
- バリデーターが
"status": "PASS"を出力し、終了コード 0 で終了します。
ファクトリー実行契約
受け入れられる結果は、実際のツールトレース、環境の証拠、実行を阻む要因に基づいて、エージェントが指定されたアクションを完了できるかを判断することです。現在のエージェントアクション判定の動作を維持しながら、変更対象を最小のオーナーに限定します。
mise run ciで現在のパッケージを固定し、そのダイジェストを記録します。mise run domain-research-policyを実行し、現在のエージェントアクション判定のソースと反証材料を評価します。- 指定されたエージェントアクション判定の操作に対して
mise run agentic-requestを実行します。意味上の選択はモデルに任せます。 mise run decision-policy、mise run ci、および動作評価を実行します。失敗した場合は、最も低い階層のオーナーに戻ります。mise run invocation-policy -- <receipt>を実行し、すべてのタスク、またはその領域固有の不使用理由を説明します。- 任意で
mise run improvement-policyを実行します。保護対象の次元が後退しない場合に限り、変更する次元を1つに限定します。
契約が必要な場合に限り、mise run use-case-policy を通じて assets/use-case-contract.json を読み込み、mise run evals を通じて evals/evals.json を読み込みます。
Mise は、繰り返し可能な仕組み、順序付け、レシート、チェックを担います。モデルは、解釈、因果関係の判断、創造的な作業、コードでは補えない直接的な知覚を担います。権限の欠如、古いエビデンス、またはゲートの失敗があれば停止します。
コメント
Markdown 対応