automate-tests

スキル：自動テストの実行

目的

対象リポジトリで自動テストを実行する方法（コマンド、フレームワーク、前提条件、対象範囲）を調べ、安全性を最優先する対話ポリシーのもとで、最も適切なテストスイートを実行します。

---

中核となる目標

主な目標：根拠に基づいてコマンドを選択し、安全対策を講じたうえでテストを実行し、その結果を提示します。

成功基準（以下をすべて満たす必要があります）：

1. ✅ テスト計画の特定：根拠となる情報源（ドキュメント、CI 設定、またはビルドマニフェスト）を特定している
2. ✅ コマンドの選択：モード（fast／ci／full）と制約に適したテストコマンドを選択している
3. ✅ ユーザーの確認取得：依存関係のインストール、ネットワークの使用、またはサービスの起動を行う前に承認を得ている
4. ✅ テストの実行：コマンドを実行し、出力と終了コードを記録している
5. ✅ 結果の要約：根拠、コマンド、実行状況、失敗（ある場合）を含むテスト計画の要約を作成している

受け入れテスト：テスト計画の要約に従うだけで、開発者は追加の情報なしにテスト実行を再現できますか？

---

対象範囲の境界

このスキルの担当範囲：

• リポジトリ内の根拠（ドキュメント、CI、ビルドマニフェスト）からテストコマンドを特定する
• モードと制約に適したテストコマンドを選択する
• 安全対策とユーザー確認のもとでテストを実行する
• 根拠と失敗の診断情報を含めてテスト結果を要約する

このスキルの担当範囲外：

• テスト品質の評価やカバレッジ分析（review-testing を使用してください）
• 失敗したテストの修正やデバッグ（orchestrate-repair-loop を使用してください）
• 新しいテストやテストインフラストラクチャの作成（開発スキルを使用してください）
• ベストプラクティスに照らしたテストコードのレビュー（review-testing を使用してください）

引き継ぎのタイミング：テストが終了したら（成功・失敗を問わず）、失敗の修正は orchestrate-repair-loop に、品質評価は review-testing に引き継ぎます。

ユースケース

• リポジトリをクローンし、推測に頼らず適切なテストコマンドを知りたい。
• リポジトリに複数のテスト層（単体／統合／E2E）があり、安全なデフォルトの実行計画が必要。
• CI が失敗し、ワークフローで使用されているものと同じコマンドを実行して、ローカルで再現したい。

動作

1. 範囲と制約を確認する（不明な場合は質問する）

   • ユーザーから何も指定がない場合は、高速で、ローカルで、非破壊的な実行をデフォルトにします。
     • ユニットテストのみを実行し、外部サービス、Docker、ネットワーク依存のセットアップは使用しません。
   • 必要に応じて、ユーザーにモードを選んでもらいます。
     • fast：ユニットテストのみ、セットアップは最小限。
     • ci：CI ワークフローのコマンドを可能な限り忠実に再現します。
     • full：統合テスト／e2e テストとサービス依存関係を含めます。
   • Docker の使用、ネットワークアクセス、依存関係のインストールが許可されているかを尋ねます。

2. テスト計画を把握する（証拠に基づく）

   • CLAUDE.md または .ai-cortex/config.yaml が存在する場合は、そこに記録された test_command を優先します。存在しない場合は、以下の情報源から確認します。docs/guides/project-config.md を参照してください。
   • 以下の情報源を順番に読み、明確で曖昧さのないテストコマンドが見つかった時点で、それ以降の確認を打ち切ります。
     • README.md、CONTRIBUTING.md、TESTING.md、docs/testing*、Makefile
     • CI 設定：.github/workflows/*.yml、.gitlab-ci.yml、azure-pipelines.yml、Jenkinsfile
     • ビルドマニフェスト：package.json、pyproject.toml、setup.cfg、tox.ini、go.mod、pom.xml、build.gradle*、*.csproj、Cargo.toml
   • 以下を特定します。
     • 主なテストエントリーポイント（npm test、pnpm test、yarn test、pytest、tox、go test、dotnet test、mvn test、gradle test、cargo test など）
     • テストレイヤーとマーカー（ユニット、統合、e2e）
     • 環境の前提条件（DB、Redis、Docker Compose、必須の環境変数、シークレット）
     • CI での依存関係のセットアップ方法（サービス、キャッシュ、アーティファクト）
   • ヒューリスティックによる推測より、ドキュメントまたは CI にある明示的な記述を優先します。

3. 実行計画を選択する

   • ci モードでは、リポジトリの CI ワークフローのステップから実行順序を導き出します（可能な限り近い手順にします）。
   • fast モードでは、最も直接的で、前提条件が最も少ないユニットテストコマンドを選びます。
   • 複数のスタックがある場合（たとえばバックエンドとフロントエンド）は、スタックごとに分け、順序を固定して実行するよう提案します。
   • 依存関係のインストールやサービスの起動が必要な場合は、続行する前に確認を求めます。

4. ガードレールを設けて実行する

   • 実行前に、これから実行する正確なコマンドを必ず表示します。
   • 作業ディレクトリは対象リポジトリを起点とします（デフォルトは .）。
   • 失敗を記録し、要約します。
     • 最初に失敗したコマンドと終了コード
     • 最も関連性の高いエラー箇所
     • 次の対応（ツールチェーンの不足、環境変数の不足、サービスが未起動など）
   • 破壊的な操作は避けます。
     • ユーザーの明示的な承認なしに、rm -rf、git clean -fdx、docker system prune、データベースの削除／マイグレーションコマンドを実行しないでください。
   • リポジトリでシークレットが必要な場合、チャットに貼り付けるよう求めないでください。.env ファイル、シークレットマネージャー、または文書化されたローカル開発フローを使用してください。

入力と出力

入力

• 対象リポジトリのパス（デフォルトは .）。
• モード：fast（デフォルト）、ci、または full。
• 制約：依存関係のインストールが許可されているか（はい／いいえ）、ネットワークの使用が許可されているか（はい／いいえ）、Docker の使用が許可されているか（はい／いいえ）。

出力

• 以下を含む簡潔な「テスト計画の概要」。
  • 根拠：計画の参考にしたファイル／パス
  • 選択したコマンド（実行順）
  • 前提と前提条件
  • 実行した内容とスキップした内容（およびその理由）
• 失敗のデバッグに必要な範囲のコマンドログ（求められない限り、極端に長いログは出力しないでください）。

制限事項

厳守すべき境界

• 根拠がある場合、テストコマンドを捏造しないでください（ドキュメント／CI を優先します）。
• 確認なしに、依存関係をインストールしたり、Docker を実行したり、外部サービスを起動したりしないでください。
• ユーザーから明示的な依頼がない限り、リポジトリのファイルを変更しないでください（例外：ユーザーが成果物を求めた場合にレポートファイルを生成すること）。
• シークレットを漏らさないでください。また、チャットで機密性の高い認証情報を求めないでください。

スキルの境界（重複を避ける）

以下は行わないでください（ほかのスキルが担当します）：

• テスト品質の評価：テストカバレッジ、テスト設計、テストのベストプラクティスの評価 → review-testing を使用してください
• テスト失敗の修正：失敗するテストのデバッグ、壊れたテストコードの修復、根本原因の特定 → orchestrate-repair-loop を使用してください
• テストの作成：新しいテストケース、テスト基盤、テストフレームワークの作成 → 開発・実装スキルを使用してください
• コードレビュー：品質、保守性、ベストプラクティスの観点からのテストコードのレビュー → review-testing を使用してください
• リポジトリの分析：コードベース全体の構造分析やアーキテクチャレビュー → review-codebase を使用してください

中断して引き継ぐ場合：

• テストが失敗し、ユーザーが「なぜですか？」または「どう修正すればよいですか？」と尋ねた場合 → デバッグと修復のため、orchestrate-repair-loop に引き継いでください
• ユーザーが「これらのテストは十分ですか？」または「カバレッジはどのくらいですか？」と尋ねた場合 → 品質評価のため、review-testing に引き継いでください
• ユーザーが「X のテストを書いてもらえますか？」と尋ねた場合 → テスト実装のため、開発ワークフローに引き継いでください
• テストが成功し、ユーザーが「次は何をテストすべきですか？」と尋ねた場合 → テスト戦略の提案を review-testing に引き継いでください

セルフチェック

中核となる成功基準（すべて満たす必要があります）

• テスト計画を確認済み：根拠となる情報源（ドキュメント、CI 設定、またはビルドマニフェスト）を特定している
• コマンドを選択済み：モード（fast／ci／full）と制約に適したテストコマンドを選択している
• ユーザーの確認を取得済み：依存関係のインストール、ネットワークの使用、またはサービスの起動前に承認を得ている
• テストを実行済み：コマンドを実行し、その出力と終了コードを記録している
• 結果を要約済み：根拠、コマンド、実行状況、失敗（ある場合）を含むテスト計画の要約を作成している

プロセス品質の確認項目

• 根拠に基づく選択：テストコマンドの信頼できる情報源（ドキュメントファイル、CI ワークフロー、またはビルドマニフェスト）を少なくとも 1 つ特定しましたか？
• 安全対策を適用：依存関係のインストール、ネットワークの使用、Docker／サービスの起動、または状態を変更する操作の前に確認を求めましたか？
• コマンドを表示：実行前に正確なコマンドを表示しましたか？
• 失敗を診断：テストが失敗した場合、最初に失敗したコマンド、終了コード、考えられる根本原因の分類を提示しましたか？
• 破壊的な操作を回避：明示的な承認なしに、破壊的なコマンド（rm -rf、git clean、docker system prune、データベースの削除）を実行するのを避けましたか？
• シークレットの漏えいを防止：会話内で機密性の高い認証情報を求めず、代わりに .env ファイルまたは文書化されたローカル開発手順を使用しましたか？

受け入れテスト

テスト計画の要約に従えば、追加情報なしで開発者がテストの実行を再現できますか？

いいえの場合：テスト計画の要約が不完全です。不足している根拠、コマンド、または前提条件を追加してください。

はいの場合：スキルの実行は完了です。必要であれば、引き継ぎを続けてください。

例

例 1：package.json がある JavaScript リポジトリ

ユーザー：「このリポジトリのテストを実行してください。」

エージェント：

1. package.json のスクリプトと .github/workflows/* を確認します。
2. fast モードに決め、次のコマンドを提案します：
   • npm test（または、リポジトリで標準として定められている場合は pnpm test／yarn test）
3. 次のように確認します：「依存関係をインストール（npm ci）し、ネットワークアクセスを許可しますか？」
4. 次を実行します：
   • npm ci
   • npm test
5. 結果を要約し、失敗があれば該当するテスト出力を示します。

例 2（エッジケース）：統合テストに Docker が必要なモノレポ

ユーザー：「CI をローカルで再現して。」

エージェント：

1. .github/workflows/ci.yml を解析し、個別のジョブを特定します：
   • バックエンドのユニットテスト
   • フロントエンドのテスト
   • docker compose を使用する統合テスト
2. 確認を求めます：
   • Docker の使用を許可するか
   • ネットワークの使用を許可するか
   • 実行するジョブ（すべて、または失敗したジョブのみ）
3. 制御された順序で実行します：
   • ジョブごとに依存関係をインストール
   • まずユニットテストを実行
   • 統合テスト用のサービスを起動
4. 統合テストが失敗した場合は、次の点を要約します：
   • サービスのヘルス状態／ポートの競合
   • 不足している環境変数
   • CI の設定とローカルの設定の違い