wio

WIO

WIO は、5 つのコマンドモードを備えたテストワークフローのスキルです。

• scan：コードベース、変更、または対象範囲について、最も価値の高いテスト候補を見つけます。
• test：選択した動作、コードパス、または回帰リスクに対して、焦点を絞った価値の高いテストを 1 つ作成します。
• workload：制御されたばらつき、再生、正しさの不変条件を備え、新たな障害の発生面、オラクル、シーケンス、またはカバレッジの観点を追加する、現実的かつ敵対的なワークロードを生成します。
• review：新規または既存のテストを、顧客にとっての価値、開発者にとっての価値、シグナル品質、保守性の観点からレビューします。
• doctor：コードベースまたは対象範囲におけるテストスイートの健全性の問題を診断します。

コマンドには $wio からアクセスします。

コマンド	機能	デフォルトのリファレンス
$wio scan [target]	コードベース、変更、または対象範囲について、最も価値の高いテスト候補を見つけます。	Behavior To Test Map
$wio test [target]	価値のある候補を見つけ、戦略を選択し、テストを 1 つ作成して検証・レビューし、価値がある場合にのみ残します。	Test Level Selection
$wio workload [target]	重要なユーザータスク、敵対的なエッジケース、アサーション、不変条件、制御されたばらつきを備え、既存のワークロードを超える新たなバグ検出価値をもたらす、現実的なワークロードを生成します。	Workload Modeling
$wio review [target]	テストが顧客または開発者にとって有意義な価値をもたらすかレビューし、KEEP、REDO、または REMOVE を返します。	Test Oracles And Assertions
$wio doctor [target]	コードベースまたは対象範囲におけるテストスイートの健全性の問題を診断します。	Test Suite Health Diagnostics

コードの証拠や候補となる障害モードから適切な戦略リファレンスを探すには、references/index.md を使用してください。

リファレンスの読み込み

記憶や、最も近い既存テストだけを頼りにテスト戦略を選ばないでください。まず、対象コード、公開されている動作、既存のテスト、フィクスチャ、テストコマンドを確認します。次に、候補となる動作やワークロードと、それらで起こりうる故障メカニズムを特定します。戦略を選ぶために必要なリファレンスを読み込むのは、候補を特定した後にしてください。

選んだ候補ごとに、テストを推奨または作成する前に、故障メカニズムに合致する戦略リファレンスを少なくとも1つ読み込んでください。

• 優先順位、顧客への影響、セキュリティ／ビジネス上のリスク、または限られたテスト容量によって着手順が決まる場合は、リスクベーステストを読み込みます。
• 対象の動作がユーザージャーニー、製品のワークフロー、API 利用者のフロー、または運用担当者のタスクである場合は、ユーザー行動テストを読み込みます。
• ユニット、コンポーネント、統合、コントラクト、E2E、ワークロード、シンセティック、またはモニタリングのカバレッジを選ぶ前に、テストレベルの選択を読み込みます。
• アサーション、不変条件、スナップショット、ワークロードのチェック、または失敗のシグナルが不明瞭なテストを作成またはレビューする前に、テストオラクルとアサーションを読み込みます。
• 状態のセットアップ、シード、ファクトリー、クリーンアップ、権限、またはデータの現実性がシグナルに影響する場合は、テストデータとフィクスチャを読み込みます。
• モック、フェイク、スタブ、エミュレーター、または実際の依存関係を使うかどうかの判断によって、保持されるリスクが変わる場合は、モックとテストダブルを読み込みます。
• ローカル、PR CI、ナイトリー、リリース、カナリア、シンセティック、または本番モニタリングのどこに配置するかを選ぶ場合は、テストのフィードバックループを読み込みます。
• 特殊なリファレンスは、故障メカニズムに応じてのみ読み込みます。広範な決定論的入力空間にはプロパティベーステスト、パーサーや信頼できない入力にはファジング、弱いアサーションにはミューテーションテスト、レイテンシーや飽和にはパフォーマンステスト、依存関係の障害にはレジリエンステスト、悪用やテナント／認証のリスクにはセキュリティテスト、コードや設定の形状に関する欠陥には静的解析、テストスイート全体の実行が遅すぎる場合にはリグレッションテストの選定を用います。

トピックに関するコマンドやリポジトリのシグナルについては、該当する overview.md でそのトピックが関連すると確認した後に、同じ階層の tools.md を読み込みます。選んだ戦略の根拠となったリファレンスファイルを明記してください。

コマンドの選択

ユーザーが次にテストすべき対象、カバレッジが重要な箇所、テスト作業の優先順位、またはユーザー、運用環境、サポート、チームのリスクを低減するテストについて尋ねた場合は、scan を使用します。

ユーザーがテストの追加、特定のテストの改善、バグのカバー、または意義のある自動テストによる変更の検証を求めた場合は、test を使用します。

ユーザーが現実的なユーザーセッションのワークロード、シナリオジェネレーター、トラフィックモデル、負荷／パフォーマンスシナリオ、ブラウザジャーニーの構成、合成ユーザーフロー、または安定したタスク目標を維持しながら変化に富んだワークロードを求めた場合は、workload を使用します。

ユーザーがワークロードの generate を求めた場合、既存のワークロードは成果物ではなく、証拠や再利用可能な基盤として扱います。生成するワークロードでは、少なくとも1つの新しい障害サーフェス、敵対的クラス、オラクル／不変条件、状態モデル、依存関係の障害、ユーザー／セッション経路、またはカバレッジの観点を追加する必要があります。既存のワークロードに対するラッパー、ランナー、シードのスイープ、パラメーターの拡張、またはドキュメントのみの変更は、ユーザーが明示的にランナーを求めている場合、またはラッパーが新しいオラクルや敵対的モデルを追加する場合を除き、生成されたワークロードとは見なしません。

テストを残す価値があるか尋ねられた場合、テストレビューを求められた場合、または $wio test がテストを作成もしくは変更した後には、review を使用します。

テストの監査、テストスイートの品質レビュー、不安定なテストや価値の低いテストの検出、CI のテスト状況の調査、またはテストスイートが遅い、ノイズが多い、シグナルが弱い理由の説明を求められた場合は、doctor を使用します。

ユーザーが WIO コマンドを明示的に指定した場合は、そのモードに従います。コマンドが省略されている場合は、依頼内容からモードを推測します。コマンドも対象も指定されていない場合は、コマンド表を表示して、何をしたいか尋ねます。複数のモードが該当する場合は、test または workload の前に scan を開始し、既存のテストスイートの健全性を調べる場合に限り doctor を使用します。

共通ルール

• カバレッジの数値ではなく、意味のある動作を保護します。
• 何がすでに壊れたかを尋ねる前に、何がうまくいかない可能性があるかを尋ねます。その答えを使ってテストを選び、設計の変更がまだ容易な段階で対処します。
• テストを推奨または作成する前に、プロダクト、ユーザー、運用環境、サポート、デバッグ、レビュー、リリースのリスクを確認します。
• バグがよく発生する対象を優先します。境界、権限、状態遷移、永続化、外部依存関係、並行処理／時間、検証／解析、マイグレーション、設定、キャッシュ、再試行／冪等性、UI ワークフローの結合点、最近変更が多い箇所などです。
• テストに価値があるのは、意味のあるリグレッションを検出する、開発者の時間を節約する、リリースへの確信を高める、または実際の運用上／顧客の障害モードを明らかにする場合に限られます。
• テストやワークロードを残す前に、それが検出できる現実的なバグを少なくとも1つ挙げ、失敗するアサーションまたは不変条件を示します。
• 正常なケース、無効なケース、それらの間の境界遷移を含め、動作に対するメンタルモデルを表現するアサーションと不変条件を優先します。
• リポジトリ標準のフレームワーク、ヘルパー、フィクスチャ、コマンド、命名規則を優先します。
• 実際の障害メカニズムを保てる範囲で、最も狭いテストレベルを選択します。
• 方針を決める前にコードとテストを読みます。候補となる障害モードが判明してから、対象を絞ったリファレンスを読み込みます。
• 確認した証拠、実行したコマンド、実行していないコマンド、残存するリスクを明記します。
• 価値の低いテストには KEEP ではなく、REDO または REMOVE を付けます。

注意点

• カバレッジを増やすだけの目的で、テストを書いたり残したりしないでください。アサーションが弱いコードのカバレッジは、誤った安心感につながります。
• 実際のリスクを生み出す境界、状態、権限、タイミング、データ、依存関係の振る舞いを、モックで取り除かないでください。
• レビュー対象のスナップショットが保護対象の契約であり、更新手順が厳格に管理されている場合を除き、広範なスナップショットを受け入れないでください。
• より小さなコマンドで同等の検証ができる場合は、全テストスイートを実行するコマンドを使わないでください。
• 不安定なテストを直すためにアサーションを弱めないでください。まず、非決定性、共有状態、タイミング、再試行、実行順序への依存、外部サービスを確認してください。
• CI が成功したことを、テストに価値がある証拠として扱わないでください。重要なリグレッションが発生した場合、そのテストが失敗するかどうかが重要です。
• 完了したこと、真偽値、オブジェクトの存在、ステータス 200、広範なスナップショットの一致、モックの呼び出し回数だけを証明するテストやワークロードは、その弱いシグナルが保護対象の契約として明示されている場合を除き、受け入れないでください。
• 既存のワークロードを薄くラップしただけのものを、$wio workload generate として提示しないでください。変更内容が既存のワークロードの再実行、パラメーター化、ドキュメント化、または反復実行だけなら、ランナーと呼び、新たな障害が発生する箇所がないことを説明してください。
• サブエージェントにテストを書かせたり、最終的な価値判断をさせたりしないでください。編集と最終的な KEEP、REDO、REMOVE の判断は、メインエージェントが担います。

利用可能なスクリプト

• scripts/test-review-reminder.py：テストファイルの変更後、アクティブなエージェントに検証と $wio review の適用を促すフックヘルパーです。
• scripts/check-wio-report.py：保存した Markdown レポート用の任意のチェッカーです。WIO の出力をファイルに書き込み、構造を手早く確認する場合は、python3 scripts/check-wio-report.py review report.md を使用してください。

サブエージェントのワークフロー

ホストがサブエージェントや並列エージェントに対応しており、ユーザー／ホストのポリシーで許可されている場合は、ガイダンスの重複を避けて品質を高めるため、公式ホストの場所にある WIO サブエージェント仕様を使用してください。

• wio-candidate-scout：高価値なテスト候補と実際のリスクを読み取り専用で調査します。
• wio-strategy-critic：実装前に、選択したテストレベル、オラクル、テストダブル、フィクスチャ、検証ループを読み取り専用で検討します。
• wio-test-reviewer：実装後のレビューを行い、KEEP、REDO、REMOVE を返します。

サブエージェントは、対象の WIO リファレンスを読み込む前に、対象となるコードとテストを確認する必要があります。調査結果をメインエージェントに返しますが、レポートの作成やリファレンス内容の複製は行いません。Claude プラグインのサブエージェントは plugins/wio/agents/ に、Claude プロジェクトのサブエージェントは .claude/agents/ に、Codex のカスタムエージェントは .codex/agents/ に配置できます。skills add で WIO をインストールしても、これらのランタイムファイルは作成されません。

$wio test では、次の手順に従ってください。

1. リポジトリと対象コードを確認します。公開されている振る舞い、変更されたパス、既存のテスト、フィクスチャ、コマンド、依存関係、状態、副作用、境界を調べます。
2. 振る舞い、リスク、バグが発生しやすい箇所、既存のカバレッジの不足、コード上の証拠に基づいて、価値のある候補を見つけます。利用可能な場合は wio-candidate-scout を使用してください。
3. 選択した候補の障害メカニズムに合ったリファレンスを読み込み、テストレベル、オラクル、フィクスチャ／データの設定、テストダブル、敵対的な境界ケースの網羅性、検証コマンドといった戦略を選びます。
4. 利用可能な場合は、編集前に wio-strategy-critic を使って提案した戦略を検討します。
5. メインエージェントで、リポジトリ標準のパターンに従って、焦点を絞ったテストを 1 つ作成します。
6. 関連する最小のコマンドで検証します。
7. 作成したテストをレビューします。利用可能な場合は wio-test-reviewer を使用してください。
8. レビュー結果が KEEP の場合にのみテストを残します。それ以外の場合は修正する（REDO）か、削除します（REMOVE）。

サブエージェントを利用できない場合は、同じ段階をメインエージェントで実施し、レビュー段階であることを明示してください。

scan

次にテストすべき最適な箇所、それぞれに適した戦略、そしてテストの ROI を見つけます。このモードは読み取り専用です。戦略のリファレンスを読み込む前にリポジトリと既存のテストを調査してください。ファイルは編集しないでください。

まずコードの根拠を確認します： プロダクトの機能領域、対象の実装、既存のテスト、フィクスチャ、コマンドを調査します。その後、候補を整理するには Behavior To Test Map を、優先順位のトレードオフを判断するには Risk-Based Testing を使い、候補が決まってから Test Level Selection を使います。

ワークフロー：

1. リポジトリの根拠から、プロダクトや顧客に関するコンテキストを把握します。
2. 既存のテストフレームワーク、コマンド、フィクスチャ、CI、テストレイヤーを一覧にします。
3. 戦略を選ぶ前に、対象の実装と周辺のテストを調査します。
4. 低レベルのヘルパーよりも、価値の高い振る舞いを先にマッピングします。
5. 対象範囲内でバグが発生しやすい箇所を特定します。
6. 各候補の故障メカニズムに合ったリファレンスを読み込み、実際のユーザーや本番環境のリスクを保てる範囲で最も限定的な戦略を選びます。
7. 影響度、発生可能性、確信度のギャップ、コストに基づいて候補に順位を付けます。

出力テンプレート：

## Scope And Evidence
[target, files/commands inspected, tests/CI found]

## Ranked Candidates
1. [behavior] - impact: [why it matters], risk: [fault mechanism], references: [files used], strategy: [level/tool], cost: [small/medium/large]

## Best Next Test
[first investment and why it beats the alternatives]

## Avoid
[coverage-padding or low-signal tests to skip]

## Open Questions
[only questions that would materially change the ranking]

test

意味のある振る舞いを守る場合に限ってテストを書きます。有用なテストは、将来のユーザーエラー、本番環境のインシデント、サポート作業、デバッグ時間、レビュー時間、またはリリースリスクを減らします。実装や戦略の選定にいきなり取りかからないでください。

まずコードの根拠を確認します： 対象の振る舞い、実装、既存のテスト、フィクスチャ、コマンドを調査します。候補を選んだ後、テストレイヤーを選ぶ前に Test Level Selection を、アサーションを書く前に Test Oracles And Assertions を読み込みます。シグナルに影響する判断がある場合は、データ、テストダブル、フィードバック、または専門的なリファレンスを追加します。

ワークフロー：

1. 対象範囲内のコード、公開される振る舞い、既存のテスト、フィクスチャ、CI、テストコマンドを調査します。
2. プロダクトリスク、バグが発生しやすい箇所、コードの構造、既存のカバレッジのギャップ、ユーザーや開発者への影響から、対象範囲内で最も価値の高い候補を見つけます。
3. その候補の故障メカニズムに適した戦略のリファレンスを読み込みます。
4. コードの根拠とリファレンスをもとに、戦略を選びます。テストレベル、オラクル、データやフィクスチャのセットアップ、テストダブル、専門的なアプローチ、フィードバックループを決定します。
5. 編集前に、保護する振る舞い、検出可能な現実的な回帰、失敗するアサーションまたは不変条件、重要である理由、使用したリファレンス、検証コマンドを明示します。
6. リポジトリに適したスタイルと既存のヘルパーを使い、対象を絞ったテストを1つ書きます。
7. 最小限の関連コマンドで検証します。安全でない場合や不明確な場合は、推測せずその旨を記載します。
8. テストの価値、シグナル、保守性、開発者の作業フローへの影響を確認します。
9. 最終決定の前に価値ゲートを適用し、KEEP、REDO、REMOVE のいずれかを選びます。

出力テンプレート：

## Candidate
[behavior/failure mode chosen and why it beat alternatives]

## Strategy
[test level, oracle, data/fixtures, doubles, feedback loop, references used, and why this preserves the real risk]

## Changes
[files changed and concise implementation summary]

## Validation
[command run and result, or why it was not run]

## Review
Verdict: KEEP | REDO | REMOVE
Protected behavior: [...]
Value: [...]
Signal strengths: [...]
False-confidence risks: [...]
Falsification check: [plausible bug and assertion/invariant that would fail]

## Remaining Risk
[what this test does not cover]

workload

一度限りのハッピーパステストや既存ランナーのラッパーではなく、ユーザーにとって意味のあるセッションを実行するワークロードを生成します。ワークロードでは、実際のユーザー、API クライアント、オペレーター、またはバックグラウンドプロセスがセッション中に行う重要なタスクを扱い、現実的ながら敵対的な誤用と、同じコアタスクを維持しつつデータ、順序、規模、タイミング、または任意の分岐を変える、制御された変動を含めます。

まずコードの根拠を確認します： ユーザー／セッションのエントリーポイント、実装、既存のテスト、フィクスチャ、コマンド、ワークロード／E2E ツールを調べます。既存のワークロードはギャップを明らかにするために使い、実装のデフォルトにはしません。アクター、目標、バグが発生しやすい相互作用、既存のワークロードのカバレッジを特定した後、Workload Modeling と Test Oracles And Assertions を読み込みます。パフォーマンス、レジリエンス、セキュリティ、ユーザー行動、プロパティベーステスト、ファジング、またはデータに関する参考資料は、ワークロードのリスクがそれらの側面に依存する場合にのみ追加します。

独自性のゲート： 編集を始める前に、既存のワークロードがすでにカバーしている内容と、新しいワークロードが追加する内容を述べます。新しいワークロードでは、少なくとも次のいずれかを導入する必要があります：新たな障害発生箇所、敵対的なケースの種類、オラクル／不変条件、状態モデル、依存関係の障害、ユーザー／セッションの経路、データ形状、タイミング／順序の側面、または再生用アーティファクト。次の最善策が単なるラッパー、ランナー、シードの一括実行、またはパラメーターの拡張にすぎない場合は、その旨を明確に述べ、ユーザーから依頼されていない限り、それを生成されたワークロードとは呼びません。

ワークフロー：

1. ユーザー／セッションのエントリーポイント、実装、既存のテスト、フィクスチャ、コマンド、ワークロード／E2E ツールを調べます。
2. 既存のワークロードを一覧にし、それぞれのアクター、障害発生箇所、オラクル／不変条件、変動、再生動作を要約します。
3. ユーザー／セッションの目標と、新しいワークロードで明らかにすべき、バグが発生しやすい相互作用を特定します。
4. カバレッジのギャップを示します：既存のワークロードが見落としていることと、そのギャップが重要な理由を説明します。
5. ワークロードの障害メカニズムに合った参考資料を読み込みます。
6. ワークロードの種類を選びます：ブラウザーでの一連の操作、API シナリオ、CLI／セッションスクリプト、バックグラウンドジョブのフロー、負荷プロファイル、合成モニター、またはプロパティ／状態を持つ一連の操作。
7. 完了だけでなく正しさを検証する、安定した不変条件とアサーションを定義し、各ステップの後、終端状態、または最終的に実行するチェックを決めます。
8. 敵対的なケースを意図的に追加します：無効な状態遷移、重複／再生された操作、古い状態、権限／テナントの境界、不正な形式ながら有効なデータ、境界サイズ、依存関係の障害、タイミング／順序の変更、部分的な失敗または復旧、明示的なエラー処理の経路。
9. シード、パラメーター範囲、任意の分岐、データ形状の変更、記録された再生情報を用いて、制御された変動を追加します。
10. 必要に応じて、リポジトリ標準のライブラリ、フィクスチャ、ヘルパー、またはワークロードツールを使って実装します。ただし、既存のワークロードを変更せずに、生成するワークロードとして再利用してはいけません。
11. 最も小さく安全なコマンドで検証し、シード、相互作用のカバレッジ、制限事項、残存リスクを報告します。

出力テンプレート：

## Workload
Actor: [...]
Goal: [...]
Shape: [browser/API/CLI/job/load/synthetic/stateful]
References used: [...]

## Existing Coverage
Existing workloads found: [...]
What they cover: [...]
Gap this workload fills: [...]
Why this is not only a wrapper/runner/seed sweep: [...]

## Coverage
Interactions: [...]
Bug-prone areas: [...]
New failure surface/adversarial class/oracle: [...]
Invariants/assertions: [...]

## Adversarial Model
Misuse paths: [...]
Invalid transitions: [...]
Boundary inputs: [...]
Duplicate/replayed actions: [...]
Permission/tenant edges: [...]
Dependency/time/concurrency faults: [...]

## Variance And Replay
Seed: [...]
Variable inputs/branches/timing/scale: [...]
Replay command or notes: [...]

## Implementation And Validation
Tooling: [...]
Files changed: [...]
Command/result: [...]

## Falsification Check
Plausible bug caught: [...]
Assertion/invariant that fails: [...]
Manual mutation or fault tried, if any: [...]

## Limits
[environment, data, dependency, runtime, cleanup, or flake risk]

レビュー

テストは形式的に承認するのではなく、品質ゲートとしてレビューします。テストの存在意義は、顧客価値、本番環境での価値、サポートやデバッグでの価値、レビューでの価値、またはリリースへの信頼によって裏付けられている必要があります。

まずコードの証拠を確認します： テストの差分と、保護対象となる本番環境の動作を調べます。次に、テストのオラクルとアサーションを読み込みます。テストの価値がそれらの懸念に左右される場合に限り、データ、テストダブル、フィードバックループ、またはミューテーションに関する参照を追加します。

ワークフロー：

1. テストの差分と、保護対象となる本番環境の動作を調べます。
2. テストが保護するとしている動作または障害モードを特定します。
3. テストの戦略、オラクル、セットアップ、テストダブル、フィードバックループを判断するために必要な参照を読み込みます。
4. その動作が、ユーザー、運用担当者、顧客、API 利用者、リリース、サポートやデバッグのサイクル、または開発者のワークフローにとって重要かを確認します。
5. 意味のあるリグレッションでアサーションが失敗するかを確認し、失敗を引き起こす可能性のあるバグを特定します。
6. セットアップ、フィクスチャ、モック、データが実際の障害メカニズムを維持しているかを確認します。
7. 検証コマンドが最小限で有用なフィードバックループか、また CI への配置が適切かを確認します。
8. 根拠を示して KEEP、REDO、または REMOVE を返します。

出力テンプレート：

Verdict: KEEP | REDO | REMOVE

Protected behavior:
[what behavior or failure mode this test claims to protect]

Value:
[customer, operator, production, support, release, review, or developer-flow value]

Signal strengths:
[why it would fail for the meaningful regression]

False-confidence risks:
[weak assertions, unrealistic setup, over-mocking, snapshots, flake risk, wrong feedback loop]

References used:
[files that informed the decision]

Falsification check:
[plausible bug and assertion/invariant that would fail]

Required action:
[none for KEEP; exact redesign for REDO; removal reason for REMOVE]

doctor

読み取り専用でテストスイートの健全性をスキャンし、懸念事項とその根拠を報告します。テストの編集、削除、書き換え、隔離、無効化は行いません。

まず確認するもの： テストスイートの健全性診断。スイートの証拠から必要性が示された場合に限り、フレーク、フィードバックループ、ピラミッド、ミューテーション、データ、テストダブル、オラクルに関する参照を追加します。

ワークフロー：

1. リポジトリのルート、言語／フレームワークの構成、テストランナー、CI システム、命名規則、テストレイヤーを特定します。
2. スイートの構成とテストコマンドを一覧化します。
3. 弱いアサーション、過剰なモック、タイミングに起因する不安定さ、共有状態、広範なスナップショット、遅いテスト、スキップ／隔離されたテスト、重要なリスクに対するカバレッジ不足を調べます。
4. 入手可能な場合は、CI とモニタリングのシグナルを調べます。
5. 信頼性、速度、シグナル、診断価値、保守性、リスクカバレッジ、モニタリングを評価します。

出力テンプレート：

## Scope And Evidence
[stack, frameworks, CI, test commands, files inspected, tests run/not run]

## Overall
Grade: [A-F or Low/Medium/High trust]
Confidence: [low/medium/high with reason]

## Top Concerns
1. Severity: [P0-P3]
   Concern: [...]
   Evidence: [...]
   Why it matters: [...]
   Suggested action: [...]

## Rubric
Reliability: [...]
Speed: [...]
Signal: [...]
Diagnostic value: [...]
Maintainability: [...]
Risk coverage: [...]
Monitoring/CI fit: [...]

## Quick Wins And Questions
[small actions and only material follow-up questions]