mcpField
O
openclaw-behavior-validator

openclaw-behavior-validator

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

openclaw-behavior-validator について

openclaw-behavior-validator は、ソースコードを調べずに、実行中の製品を動作契約に照らしてテストするスキルです。ブラウザーや CLI など利用者・運用者向けの窓口でブラックボックス検証を行い、契約条項ごとに結果をまとめます。

主な機能

  1. 01契約に基づく動作検証
  2. 02ソースを見ないテスト手順
  3. 03ブラウザー、CLI、API での操作
  4. 04不正動作の検証と証拠の記録
  5. 05構造化レポートと再テスト

活用シーン

  1. 01ユーザー要求に対する機能検証
  2. 02CLI や API の動作確認
  3. 03生成物のテスト
  4. 04修正後の検証の再実行

インストール

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

$npx skills add https://github.com/theangrypit/theangryskills --skill openclaw-behavior-validator

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

同梱ファイル

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

LICENSE
MIRROR.md
agents/
openai.yaml
references/
contract-template.md
report-schema.md

詳細

動作検証ツール

ソースを調べずに、観察可能な動作を検証します。コードを考慮したレビューを補完するブラックボックス検証として使用してください。autoreview は変更一式を評価し、behavior-validator は動作中の製品、CLI、API、または生成された成果物を動作契約に照らして評価します。

契約

  • 最初に動作契約を読みます。存在しない場合は、テストの前にユーザーの依頼をもとに簡潔な契約を作成します。references/contract-template.md を参照してください。
  • ソースを参照しません。ソースファイル、差分、テスト、git 履歴、実装メモ、ビルドの内部情報、レビュー用データは調べないでください。
  • ユーザーまたは運用担当者から見えるインターフェースのみを通じて操作します。ブラウザー、CLI、API、生成ファイル、公開ログ、スクリーンショット、アクセシビリティツリー、またはドキュメントに記載された実行時出力が対象です。
  • 実装をうかがわせる証拠は汚染として扱います。続行にソースへのアクセスが必要な場合は中止し、blocked_source_required と報告します。
  • コードの場所ではなく、契約の条項と観察可能な手順に照らして指摘事項を報告します。
  • 関連する契約条項すべてを pass、fail、blocked、または out of scope に分類するまで、ワークフローを合格としないでください。

分離

ソースを参照しないワークスペースを優先します。

validator_dir="$(mktemp -d "${TMPDIR:-/tmp}/behavior-validator-run.XXXXXX")"
chmod 700 "$validator_dir"
cp behavior-contract.md "$validator_dir/"
cd "$validator_dir"

契約で指定された対象を起動するか、接続します。プライベートな検証用ワークスペースには、契約、許可されたテスト用データ、秘匿情報を除いた取得済み証拠のみを保管します。認証情報は、承認済みのシークレット管理ツールまたは指定された環境変数を通じて渡します。認証情報の値をワークスペース、レポート、スクリーンショット、ログにコピーしてはいけません。契約や取得済み証拠に、固定された共有パスを使用しないでください。ソースのチェックアウトからアプリを起動する必要がある場合は、別のターミナルから起動し、検証中にソースを読まないでください。

ワークフロー

  1. 契約を、ユーザータスク、期待される動作、不正対策の検証、セットアップ、証拠要件に分解します。
  2. 実行時のアクセスを準備します。対象 URL、CLI コマンド、API エンドポイント、テスト用データ、認証情報、または生成された成果物のパスが対象です。
  3. ユーザーまたは運用担当者が実際に行うように、各ユーザータスクを実行します。
  4. 不正対策の検証を行います。テスト用データを変える、更新や再試行を行う、空の入力と無効な入力をテストする、状態が保持されることを確かめる、生成された出力を調べる、ボタンやコマンドが成功メッセージを表示するだけでなく実際に動作することを確認します。
  5. 簡潔で秘匿情報を除いたメモ、スクリーンショット、ターミナルの抜粋、応答の要約、ファイルの要約、またはアクセシビリティの観察結果として証拠を記録します。認証情報、トークン、Cookie、ユーザーの個人データ、無関係なログ内容は含めないでください。
  6. 構造化レポートを出力します。機械可読形式のレポートが役立つ場合は、references/report-schema.md を使用してください。
  7. オーケストレーターが指摘事項を修正した場合は、該当する契約条項と、近接する回帰検証のみを再実行します。

指摘事項のルール

  • 観察可能な動作が契約に違反している場合、タスクを完了できない場合、期待される状態が偽物または静的な場合、あるいは合格とするための証拠が不十分な場合は、fail とします。
  • 必要な実行時アクセス、認証情報、テスト用データ、ネットワーク、またはツールが不足している場合は、blocked とします。
  • 契約で動作が明示的に除外されている場合、またはタスクがユーザー所有の製品上の判断に依存する場合に限り、out of scope とします。
  • 純粋に美観、コード品質、または実装スタイルに関する懸念は受け付けません。これらはコードを考慮したレビューの対象です。

最終レポート

以下を含めます。

  • 検証した対象
  • 使用した契約ファイルまたはインライン契約
  • pass／fail／blocked／out of scope の要約
  • 再現手順と証拠を含む、採用された動作上の指摘事項
  • 実施した不正対策の検証
  • 残っているブロッカー（あれば）

コメント

Markdown 対応