菜单
探索的テストの自動実施。プロジェクトのインターフェース（CLI/API/Web API/GUI）を 自動判定し、テスト計画作成・テスト実装・実行・レポート生成までを包括的に実施する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
プリントデバッグによるハンズオン問題分析モード。 1ステップ1確認の積み重ねで、ユーザーが自分の手でprintln/console.logを仕込み、 実行結果を観察しながら問題の原因とプロジェクト構造を同時に理解する。 AIはコードを書かず、どこに何を出力すべきかをガイドする。 以下の場合に使用: (1) バグの原因をプリントデバッグで追いたい (2) 未知のコードベースの処理フローを実行時の観察で理解したい (3) 「この入力がどう処理されるか」を実際に追跡したい (4) フォーマッター/パーサー/コンパイラ等の変換パイプラインの挙動を理解したい (5) 自分の仮説を実行結果で検証したい
PR〜エピック単位のシステム設計 + dry-coding。要件→多角的評価→設計ドキュメント(.claude/plans/)。plan mode wrapper。Explore/Plan subagent並列 + Schema Contract。コード変更は行わず、設計ドキュメントとレビュー可能な実装コードを出力。(1)新機能設計 (2)リファクタ設計 (3)PR前設計レビュー (4)アーキ判断文書化 (5)アプローチ比較 (6)エピック段階計画 (7)実装コードのdry提示
OSSのissue・バグレポート・機能提案を4フェーズで段階的に分析し、 TDDベースの実装計画を作成する。コード変更は行わず調査・分析・計画のみ。 独立並列調査→仮説-反証サイクル→証拠スコアリングにより、 確証バイアス・アンカリング等の認知バイアスを排除した課題特定を行う。 ハルシネーション防止のためソース実在確認・WebSearchによる裏取りを実施。 推論過程・論拠・Next Actionを含む構造化レポートを出力する。 以下の場合に使用: (1) OSSバグの原因特定と修正計画立案 (2) OSSへの機能追加の設計と計画 (3) GitHub Issue/Discussionの深掘り分析 (4) OSSコントリビューション前の学習と理解 (5) issueの真の原因を特定したい（表面的症状と根本原因を区別） (6) 複数の可能性がある問題の切り分け (7) 既存の分析が正しいか検証したい
Property-Based Testing（PBT）の自動設計・実装支援。テスト対象コードを静的分析し、 プロパティパターン選定・ジェネレータ合成・テストコード生成・実行・レポートを自動実行する。 フレームワーク自動検出。サブエージェント並列調査。
ガイド付きコーディングモード。ユーザーが自分の手でコードを書きながら学べるようにサポートする。 AIはコードを直接書かず、何を・どこに書くべきかをガイドする。 フェーズ制の進捗管理で、完了まで導く。
macOSの不要ファイルやキャッシュを削除してストレージを最適化する。 Docker、開発キャッシュ、アプリケーションキャッシュ、ダウンロード整理、 システムキャッシュ等を対話的に選択して安全にクリーンアップ。
| name | test:exploratory |
| description | 探索的テストの自動実施。プロジェクトのインターフェース（CLI/API/Web API/GUI）を 自動判定し、テスト計画作成・テスト実装・実行・レポート生成までを包括的に実施する。 |
| disable-model-invocation | true |
あなたは探索的テストの専門家です。プロジェクトのインターフェースを自動判定し、包括的なテストを実施してください。
まず最初に、AskUserQuestion ツールを使って以下を質問してください:
質問: "探索的テストの成果物をどこに配置しますか？"
選択肢:
1. "docspriv/" - プライベートドキュメント用ディレクトリ（推奨）
2. "test/exploratory/" - テストディレクトリ配下
3. "tmp/exploratory_test/" - 一時ディレクトリ（Git管理外）
4. "カスタムパス" - 任意のパスを指定
ユーザーの回答に基づいて、以下の変数を設定してください:
TEST_OUTPUT_DIR: 成果物の配置ディレクトリ（例: "docspriv", "test/exploratory"）TEST_CASES_DIR: テストケースのディレクトリ（例: "{TEST_OUTPUT_DIR}/test_cases"）TEST_RESULTS_DIR: テスト結果のディレクトリ（例: "{TEST_OUTPUT_DIR}/test_results"）SCRIPTS_DIR: スクリプトのディレクトリ（例: "{TEST_OUTPUT_DIR}/scripts"）質問: "テスト成果物を .gitignore に追加しますか？"
選択肢:
1. "はい" - Git管理から除外する
2. "いいえ" - Git管理に含める
「はい」の場合、.gitignore に以下を追加:
# Exploratory testing
{TEST_OUTPUT_DIR}/
質問: ".claude/settings.json に自動承認設定を追加しますか？"
選択肢:
1. "はい" - テスト実行時の承認を不要にする（推奨）
2. "いいえ" - 各操作ごとに確認する
「はい」の場合、.claude/settings.json に以下を追加:
{
"approvalRequired": {
"bash": {
"patterns": [
{
"pattern": "^ruby {TEST_OUTPUT_DIR}/.*$",
"behavior": "accept",
"reason": "Exploratory testing scripts"
},
{
"pattern": "^python {TEST_OUTPUT_DIR}/.*$",
"behavior": "accept",
"reason": "Exploratory testing scripts"
},
{
"pattern": "^node {TEST_OUTPUT_DIR}/.*$",
"behavior": "accept",
"reason": "Exploratory testing scripts"
}
]
},
"write": {
"patterns": [
{
"pattern": "^{TEST_OUTPUT_DIR}/.*$",
"behavior": "accept",
"reason": "Exploratory testing files"
}
]
},
"edit": {
"patterns": [
{
"pattern": "^{TEST_OUTPUT_DIR}/.*$",
"behavior": "accept",
"reason": "Exploratory testing files"
}
]
}
}
}
これらの質問に対する回答を取得してから、次のフェーズに進んでください。
以下を調査してプロジェクトの性質を判定してください:
以下のパターンでインターフェースタイプを判定してください:
判定基準:
bin/ または exe/ ディレクトリにコマンドファイルがあるcli.rb, cli.py, cli.js 等のファイルが存在Thor, Commander, Click, argparse, clap 等のCLIライブラリを使用$ command --option 形式）があるテスト対象:
判定基準:
lib/ または src/ ディレクトリに公開APIがあるrequire, import, use 等）があるテスト対象:
判定基準:
app/, routes/, controllers/ ディレクトリがあるexpress, sinatra, flask, actix-web 等のWebフレームワークを使用swagger.yml, openapi.json があるテスト対象:
複数のインターフェースが混在している場合、すべてを検出してください。
判定したインターフェースに基づいて、{TEST_OUTPUT_DIR}/exploratory_testing_plan.md を作成してください。
{SCRIPTS_DIR}/run_exploratory_tests.rb (または適切な言語) を作成してください。
作成したスクリプトを実行。
summary.json, bugs.md, improvements.md を自動生成。
テスト完了後、プロジェクト名、インターフェース、テスト結果統計、発見バグ、推奨アクションを報告。
{TEST_OUTPUT_DIR}/ 配下で実行