mcpField
A
agent-tool-testing

agent-tool-testing

github.com/naodengテスト・品質28539 回インストール今日更新
リポジトリ

agent-tool-testing について

Agent Tool Testingは、AIエージェントのツール選択、引数、認可、障害復旧、副作用の境界を評価するスキルです。事実・仮定・不足情報を区別し、証拠に基づいて優先順位を付けた実行可能なテスト資料の作成を支援します。

主な機能

  1. 01ツール選択と引数を評価
  2. 02認可と障害復旧を確認
  3. 03副作用の境界とリトライを検証
  4. 04リスクと証拠に基づき所見を順位付け
  5. 05事実、仮定、不足情報を区別

活用シーン

  1. 01エージェントのツールテスト計画を監査
  2. 02テスト結果と根拠となる証拠をレビュー
  3. 03情報が不完全な状況で限定的な初期評価を作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/naodeng/awesome-qa-skills --skill agent-tool-testing

インストール後、Claude Code で/agent-tool-testingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
evals/
eval.yaml
evals/cases/
basic-success.yaml
edge-incomplete-input.yaml
edge-risk-priority.yaml
review-tool-schema-trace.yaml
evals/graders/
review-tool-schema-trace.py
prompts/
agent-tool-testing.md

詳細

エージェントツールのテスト

使用するタイミング

  • AI エージェントのツール選択、引数の契約、認可、失敗からの復旧、副作用の境界を検証する必要がある場合に、このスキルを使用します。
  • 既存の計画、結果、証拠一式をレビューし、実行可能な改善策を提示する場合に使用します。
  • コンテキストが不完全でも、範囲を限定した初回の検討に価値がある場合に使用します。

出力形式の選択肢

  • レビュー、実行、段階的な改善には、デフォルトで Markdown を使用します。
  • ユーザーが表、CSV、JSON、またはチケットのフィールドを要求した場合は、リスク、証拠、優先度、境界に関する情報を保持します。
  • 機械処理される出力では、まずスキーマ、列挙値、必須フィールドを確認します。

使用方法

  1. prompts/agent-tool-testing.md を読み、入力契約、実行ルール、最低限の網羅範囲、出力順序を含め、その指示に従います。
  2. 判断に影響するコンテキストのみを追加します。対象範囲、環境、バージョン、制約、証拠、成功基準などです。
  3. 入力を監査し、確認済みの事実、作業上の仮定、未解決の疑問を分けます。
  4. リスクと証拠の強さに基づいて優先順位を付け、実行または直接レビューできる成果物を作成します。
  5. 情報が不足している場合は、範囲を限定した初回の検討結果を提示し、どの結論に根拠が不足しているかを明示します。

参考ファイル

  • 常に prompts/agent-tool-testing.md を読みます。このスキルの実行仕様がすべて記載されています。
  • 評価または回帰テストでは、evals/eval.yaml と evals/cases/ にある関連ケースを読みます。
  • references/、examples/、scripts/、output-formats.md は、それらのディレクトリが存在し、タスクに必要な場合にのみ読み込みます。

主な制約

  • デフォルトでは、モック、ドライラン、または分離された環境を使用します
  • 認可なしに実際の書き込みを実行してはいけません
  • 再試行テストでは、副作用の重複を検出する必要があります
  • 証拠にないシステムの動作、フィールド、データ、メトリクス、根本原因を捏造してはいけません。
  • 重要な結論は証拠と結び付けます。根拠のない結論は仮説として示し、検証方法を記載します。
  • ビジネスへの影響、発生可能性、または検出可能性を使って優先度を説明します。

提出前チェックリスト

  • 網羅済み:ツール選択の正確性、引数の生成と検証、認可、タイムアウトと再試行、冪等性、副作用の分離、結果の解釈、監査証拠。
  • 事実、仮定、ギャップ、推奨事項を区別した。
  • 高リスク項目に優先度、根拠となる証拠、担当者または次のアクションを設定した。
  • 一般論ではなく、検証可能な判断基準を定めた。
  • 認可されていない本番環境への書き込みや破壊的な操作を行っていない。

よくある落とし穴

  • 前提条件、期待される結果、証拠を示さずにチェック項目を列挙する。
  • すべてを高優先度にし、トレードオフを避ける。
  • ドメインに即した推論の代わりに、ツール名や一般論を使う。
  • 不完全な入力を理由に対応を拒む、または不完全な証拠で確実な結論が得られるかのように扱う。

ベストプラクティス

  • ビジネス上の損失、安全上の問題、リリースの阻害につながる可能性が最も高い経路から着手します。
  • 最小限の検証可能な実験で不確実性を減らし、再現条件を記録します。
  • 成果物は、別のエンジニアが実行でき、独立してレビューできるものにします。

コメント