test-analyze

テスト分析と修正計画

あらゆるテストフレームワークのテスト結果を分析し、Zen planner を使用して体系的な修正戦略を作成し、適切なサブエージェントに修正を委任します。

このスキルを使用する場面

次の場合はこのスキルを使用します…	次の場合は test-report を使用します…
失敗したテスト結果のディレクトリをトリアージして修正計画にまとめる	キャッシュされたステータスをすばやく確認するだけでよい
不安定なテスト、パフォーマンス、アクセシビリティ、セキュリティに関する失敗を分類する	最初にテストを実行する（test-run を使用）
修正を専門のサブエージェントに委任する	「X をどのようにテストすべきか」といった戦略的な質問をする（test-consult を使用）
JUnit XML またはカバレッジ出力から構造化された計画を作成する	失敗している単一の仕様の修正を繰り返す（test-focus を使用）

使用方法

/test:analyze <results-path> [--type <test-type>] [--focus <area>]

パラメーター

• <results-path>：テスト結果のディレクトリまたはファイルへのパス（必須）

  • 例：./test-results/、./coverage/、pytest-report.xml

• --type <test-type>：テストの種類（任意。省略時は自動検出）

  • accessibility - Playwright a11y、axe-core
  • unit - Jest、pytest、cargo test
  • integration - API テスト、データベーステスト
  • e2e - Playwright、Cypress、Selenium
  • security - OWASP ZAP、Snyk、TruffleHog
  • performance - Lighthouse、k6、JMeter

• --focus <area>：重点的に扱う領域（任意）

  • 例：authentication、api、ui-components、database

例

# Analyze Playwright accessibility test results
/test:analyze ./test-results/ --type accessibility

# Analyze unit test failures with focus on auth
/test:analyze ./coverage/junit.xml --type unit --focus authentication

# Auto-detect test type and analyze all issues
/test:analyze ./test-output/

# Analyze security scan results
/test:analyze ./security-report.json --type security

コマンドの流れ

1. テスト結果を分析する

   • テスト結果ファイル（XML、JSON、HTML、テキスト）を解析する
   • 失敗、エラー、警告を抽出する
   • 問題を種類と重大度別に分類する
   • パターンと根本原因を特定する

2. PAL Planner で修正を計画する

   • 体系的な計画には mcp__pal__planner を使用する
   • 複雑な修正を実行可能な手順に分割する
   • 修正間の依存関係を特定する
   • 作業量と優先度を見積もる

3. サブエージェントに委任する

   • アクセシビリティの問題 → code-review エージェント（WCAG 準拠）
   • セキュリティの脆弱性 → security-audit エージェント
   • パフォーマンスの問題 → system-debugging エージェント
   • コード品質の問題 → code-refactoring エージェント
   • テストインフラストラクチャ → test-architecture エージェント
   • 統合の失敗 → system-debugging エージェント
   • ドキュメントの不足 → documentation エージェント

4. 計画を実行する

   • 依存関係に基づいて順番に実行する
   • 修正ごとに検証する
   • テストを再実行して解決を確認する

サブエージェントの選択ロジック

コマンドは次の判断ツリーを使用して委任します。

• アクセシビリティ違反（WCAG、ARIA、コントラスト） → アクセシビリティに重点を置いた code-review エージェント

• セキュリティの問題（XSS、SQLi、認証のバイパス） → OWASP 分析を行う security-audit エージェント

• パフォーマンスのボトルネック（遅いクエリ、メモリリーク） → プロファイリングを行う system-debugging エージェント

• コードの不吉な兆候（重複、複雑さ、結合度） → SOLID 原則に基づく code-refactoring エージェント

• 不安定なテスト（競合状態、タイミングの問題） → 安定性を分析する test-architecture エージェント

• ビルド／CI の失敗（パイプラインエラー、依存関係の問題） → ワークフローを最適化する cicd-pipelines エージェント

出力

コマンドは次の内容を生成します。

1. サマリーレポート

   • 検出された問題の総数
   • カテゴリ／重大度別の内訳
   • 優先度の高い項目

2. 修正計画（PAL planner による）

   • 段階的な修正戦略
   • 依存関係グラフ
   • 作業量の見積もり

3. サブエージェントへの割り当て

   • 各問題を担当するエージェント
   • 委任の理由
   • 実行順序

4. 実行可能な次のステップ

   • 実行するコマンド
   • 変更するファイル
   • 検証手順

注記

• 構造化された出力を生成するあらゆるテストフレームワークで動作します
• 一般的なテスト結果形式（JUnit XML、JSON、TAP）を自動検出します
• デバッグ用のテスト証跡を保持します
• 自動修正のために /git:smartcommit と連携できます
• TDD ワークフロー（RED → GREEN → REFACTOR）に従います

関連コマンド

• /test:run - フレームワークを検出してテストを実行
• /code:review - テストファイルを手動でコードレビュー
• /docs:update - テストドキュメントを更新
• /git:smartcommit - 修正を規約に沿ったメッセージでコミット

---

プロンプト：

{{ARG1}} のテスト結果を分析し、体系的な修正計画を作成してください。

{{#if ARG2}} テストの種類：{{ARG2}} {{else}} ファイル形式と内容からテストの種類を自動検出してください。 {{/if}}

{{#if ARG3}} 重点領域：{{ARG3}} {{/if}}

ステップ 1：テスト結果を分析する

{{ARG1}} のテスト結果ファイルを読み込み、以下を抽出してください。

• 失敗したテストとエラーメッセージ
• 警告と非推奨事項
• パフォーマンス指標（利用可能な場合）
• カバレッジの不足箇所（利用可能な場合）
• 重要度（critical/high/medium/low）と種類（functional/security/performance/accessibility）で分類

ステップ 2：PAL Planner を使用する

モデル「gemini-2.5-pro」で mcp__pal__planner を呼び出し、体系的な修正計画を作成してください。

• ステップ 1：調査結果を要約し、根本原因を特定する
• ステップ 2：影響度 × 工数のマトリクスで問題に優先順位を付ける
• ステップ 3：修正を実行可能なタスクに分解する
• ステップ 4：修正間の依存関係を特定する
• ステップ 5：修正カテゴリごとに適切なサブエージェントを割り当てる
• 複雑なケースでは、必要に応じて計画ステップを続ける

ステップ 3：サブエージェントへの委任方針

問題のカテゴリに基づいて、以下に委任してください。

• アクセシビリティ違反（WCAG、ARIA、色のコントラスト、キーボード操作） → Task ツールを subagent_type: code-review で使用 → 重点：WCAG 2.1 への準拠、セマンティック HTML、ARIA のベストプラクティス

• セキュリティ脆弱性（XSS、SQLi、CSRF、認証の問題） → Task ツールを subagent_type: security-audit で使用 → 重点：OWASP Top 10、入力検証、認証

• パフォーマンスの問題（テストの遅延、メモリーリーク、タイムアウト） → Task ツールを subagent_type: system-debugging で使用 → 重点：プロファイリング、ボトルネックの特定、最適化

• コード品質（重複、複雑さ、保守性） → Task ツールを subagent_type: code-refactoring で使用 → 重点：SOLID 原則、DRY、コードの問題点

• 不安定なテスト／信頼性の低いテスト（競合状態、タイミング、依存関係） → Task ツールを subagent_type: test-architecture で使用 → 重点：テストの安定性、分離性、決定性

• CI/CD の失敗（ビルドエラー、パイプラインの問題） → Task ツールを subagent_type: cicd-pipelines で使用 → 重点：GitHub Actions、依存関係の管理、キャッシュ

• ドキュメントの不足（ドキュメントの欠落、古い例） → Task ツールを subagent_type: documentation で使用 → 重点：API ドキュメント、テストドキュメント、移行ガイド

ステップ 4：実行計画を作成する

サブエージェントへの各割り当てについて、以下を記載してください。

1. コンテキスト：対応が必要なファイル／領域
2. 目的：具体的な修正目標
3. 成功基準：修正を検証する方法
4. 依存関係：先に実施する必要がある作業
5. 検証：テストを再実行するコマンド

ステップ 5：概要を提示する

以下を提示してください。

• 📊 問題の内訳：カテゴリと重要度ごとの件数
• 🎯 優先事項：最初に修正する上位 3～5 件
• 🤖 サブエージェント計画：どのエージェントが何を担当するか
• ✅ 次のステップ：具体的な対応
• 🔍 検証：修正が機能したことを確認する方法

{{#if ARG3}} {{ARG3}} に関する追加の重点事項：この領域に関連する問題を優先し、該当するサブエージェントに追加のコンテキストを提供してください。 {{/if}}

ドキュメント優先のリマインダー：修正を実装する前に、context7 を使って関連ドキュメントを調査し、以下を確認してください。

• テストフレームワークのベストプラクティス
• アクセシビリティ基準（WCAG 2.1）
• セキュリティパターン（OWASP）
• パフォーマンス最適化の手法

TDD ワークフロー：RED → GREEN → REFACTOR の順に進めてください。

1. テストが失敗することを確認する（RED）✓（すでに実施済み）
2. 最小限の修正を実装する（GREEN）
3. 品質を高めるためにリファクタリングする
4. テストを再実行して確認する

分析と計画を進めますか？それとも、まず計画を確認しますか？