ln-523-auto-test-planner

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

自動テストプランナー

タイプ： L3 ワーカー

リスクベーステストの方法論と実際の手動テスト結果に基づいて、包括的な自動テストカバレッジ（E2E／統合／単体）を備えた Story テストタスクを作成します。

入力

入力	必須	ソース	説明
storyId	はい	args、git ブランチ、kanban、ユーザー	処理する Story

解決方法： Story 解決チェーン。 ステータスフィルター： To Review

目的と範囲

• Story の自動テスト用に包括的なテストタスクを作成します
• リスクベースの優先度（影響度 × 発生確率）を算出します
• 手動テスト結果から11セクションのテスト計画を生成します
• ln-301-task-creator（CREATE）または ln-302-task-replanner（REPLAN）に委任します
• 対象外： 手動テスト、調査、オーケストレーション

使用するタイミング

• 実装作業が完了し、自動テストカバレッジの計画が必要な場合に使用します
• Story のすべての実装 Task のステータスが Done である場合
• ln-521 の調査：利用可能な場合は使用し、ない場合は最小限の調査をインラインで生成します
• ln-522 の手動テスト：利用可能な場合は使用し、ない場合は「ポリシーによりスキップ」として扱います

自動化： 管理対象の実行では autoApprove: true をサポートし、手動確認を省略できます。

ワークフロー

フェーズ 0：ツール設定

必須の読み込み： references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md を読み込みます

抽出項目：task_provider = Task Management → Provider（linear | file）。

フェーズ 1：検出（自動）

1. storyId を解決： ガイドに従って Story 解決チェーンを実行します（ステータスフィルター：[To Review]）。
2. docs/tasks/kanban_board.md から Team ID を自動検出します（CLAUDE.md の「Configuration Auto-Discovery」を参照）

フェーズ 2：Story と Task の分析（ダイアログなし）

ステップ 0：プロジェクトのテストファイルを確認

1. テスト関連ファイルをスキャンします：
   • tests/README.md（コマンド、セットアップ、環境）
   • テスト設定ファイル（jest.config.js、vitest.config.ts、pytest.ini）
   • 既存のテスト構成（tests/、tests/ ディレクトリ）
   • カバレッジ設定（.coveragerc、coverage.json）
2. テストコマンド、フレームワーク、パターン、カバレッジのしきい値を抽出します
3. テスト計画がプロジェクトの慣例に沿うようにします

ステップ 1：調査と手動テスト結果を読み込む

1. Story を取得します（「user-story」ラベルが必須です）：
   • task_provider = linear の場合：get_issue(storyId) — Story.id（UUID、短縮 ID ではありません）を抽出します
   • task_provider = file の場合：Read story.md — Story のメタデータを抽出します
2. 調査コメント（ln-521 から）を読み込みます：「## Test Research: {Feature}」
   • task_provider = linear の場合：list_comments(issueId=storyId) → 一致するコメントを検索します
   • task_provider = file の場合：Glob("docs/tasks/epics/*/stories/*/comments/*.md") → 一致するコメントを検索します
   • 調査コメントが見つからない場合：Story の AC と Task の説明に基づき、テストの主要領域を3～5項目の箇条書きで生成します（外部調査なし、インラインで実施）。
3. 手動テスト結果のコメント（ln-522 から）を読み込みます：「## Manual Testing Results」
   • 上記の調査コメントと同じ方法を使用します
   • 手動テスト結果が見つからない場合：手動テストカバレッジの分析をスキップします。出力に「Manual testing: skipped by policy (simplified mode).」と記載します。
4. セクションを解析します：AC の結果（PASS／FAIL）、エッジケース、エラー処理、統合フロー
5. テスト設計にマッピングします：PASS の AC → E2E、エッジケース → 単体、エラー → エラー処理、フロー → 統合

ステップ 2：Story と Task を分析

1. Story を解析します：目標、テスト戦略、技術メモ
2. すべての子 Task を取得します（ステータス = Done）：
   • task_provider = linear の場合：list_issues(parentId=Story.id, state="Done")
   • task_provider = file の場合：Glob("docs/tasks/epics/*/stories/*/tasks/*.md") → **Status:** Done で絞り込みます
3. 各 Task を分析します：
   • 実装されたコンポーネント
   • 追加されたビジネスロジック
   • 作成された統合ポイント
   • 条件分岐（if/else/switch）
4. テストが必要な対象を特定します

フェーズ 3：手動テスト結果の解析戦略

プロセス：「Manual Testing Results」ヘッダーがある Linear のコメントを検索 -> フォーマットのバージョン 1.0 を確認 -> 正規表現を使用して構造化されたセクション（Acceptance Criteria、Test Results by AC、Edge Cases、Error Handling、Integration Testing）を抽出 -> 検証（PASSED の AC が 1 件以上あること、AC の数が Story と一致すること、完全性の確認） -> 解析したデータをテスト設計の構造にマッピング

エラー処理： コメントがない場合 -> フォールバックを使用（インライン調査、またはフェーズ 2 のロジックに従ってスキップ）、フォーマットのバージョンがない場合 -> WARNING（レガシー形式での解析を試行）、必須セクションがない場合 -> フォールバックを使用、PASSED の AC がない場合 -> ERROR（実装を修正）

フェーズ 4：リスクベースのテスト計画（自動化）

必読： references/risk_based_testing_guide.md を読み込み、スコアリングと有用性の判定条件を確認します。 条件付きで読む：テスト戦略全体を計画する場合、またはリスク／有用性の判断が曖昧な場合に限り、references/risk_based_testing_methodology.md を読み込みます。

E2E ファーストのアプローチ： カバレッジ指標ではなく、ビジネスリスク（優先度 = 影響度 x 発生確率）に基づいて優先順位を決定します。

ワークフロー：

ステップ 1：リスク評価

手動テストの各シナリオについて、優先度を算出します。

Priority = Business Impact (1-5) x Probability (1-5)

判定基準：

• 優先度 ≥15 -> 必ずテスト
• 優先度 9-14 -> 未カバーの場合はテストすべき
• 優先度 <=8 -> スキップ（手動テストで十分）

ステップ 2：E2E テストの選択（2-5）： 基準となる 2 件（ポジティブ + ネガティブ）は必須 + 追加の 0-3 件（優先度 ≥15 のみ）

ステップ 3：ユニットテストの選択（0-15）： デフォルトは 0 件。複雑なビジネスロジック（優先度 ≥15）の場合のみ追加します：金融、セキュリティ、アルゴリズム

ステップ 4：統合テストの選択： デフォルトは 0 件。E2E の不足があり、かつ優先度 ≥15 の場合のみ追加します：ロールバック、同時実行、外部 API エラー

ステップ 5：検証： 各テストが有用性の基準（優先度 ≥15、ROI の確信度、振る舞いに関するもの、予測可能、具体的、重複なし）を満たすこと

フェーズ 5：テストタスクの生成（自動化）

test_task_template.md に従って、テストタスク全体（11 セクション）を生成します。

セクション 1-7： コンテキスト、リスクマトリックス、E2E／統合／ユニットテスト（優先度スコアと根拠を含む）、カバレッジ、DoD

セクション 8： 修正が必要な既存テスト（実装タスクの影響を受けるテストの分析）

セクション 9： インフラストラクチャの変更（パッケージ、Docker、設定。テストの依存関係に基づく）

セクション 10： ドキュメントの更新（README、CHANGELOG、tests/README、設定ドキュメント）

セクション 11： レガシーコードのクリーンアップ（サポート対象外のパターン、後方互換性、デッドコード）

レビュー用のプレビューを表示します。

フェーズ 6: 確認と委任

ステップ 1: 生成されたテスト計画をプレビューする（透明性のため常に表示されます）

ステップ 2: 確認ロジック:

• autoApprove: true -> 自動的に続行します
• 手動実行 -> ユーザーに「confirm」と入力するよう促します

ステップ 3: 既存のテストタスクを確認する

• task_provider = linear の場合: list_issues(parentId=Story.id, label="tests")
• task_provider = file の場合: Glob("docs/tasks/epics/*/stories/*/tasks/*.md") → **Labels:** に tests を含むものでフィルタリングします

判定:

• 件数 = 0 -> CREATE モード（ステップ 4a）
• 件数 >= 1 -> REPLAN モード（ステップ 4b）

ステップ 4a: CREATE モード（件数 = 0 の場合）

管理された委任シーケンス:

1. childRunId = {parent_run_id}--ln-301--{storyId} を計算します
2. childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/task-plan/ln-301--{storyId}.json を計算します
3. .hex-skills/test-planning/ln-301--{storyId}_manifest.json に子マニフェストを実体化します
4. 両方の転送入力で task-plan-worker-runtime を起動します
5. PHASE_6_DELEGATE_TASK_PLAN に child_run メタデータをチェックポイントします
6. --run-id と --summary-artifact-path を指定して ln-301-task-creator を呼び出します
7. 結果として得られた子の task-plan アーティファクトのみを読み取ります

ワーカーに渡すもの:

• taskType, teamId, storyData（Story.id、title、AC、Technical Notes、Context）
• researchFindings（ln-521 のコメントから）
• manualTestResults（ln-522 のコメントから）
• testPlan（e2eTests、integrationTests、unitTests、riskPriorityMatrix）
• infrastructureChanges、documentationUpdates、legacyCleanup

ワーカーが返すもの: タスク URL + task-plan アーティファクト

ステップ 4b: REPLAN モード（件数 >= 1 の場合）

管理された委任シーケンス:

1. childRunId = {parent_run_id}--ln-302--{storyId} を計算します
2. childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/task-plan/ln-302--{storyId}.json を計算します
3. .hex-skills/test-planning/ln-302--{storyId}_manifest.json に子マニフェストを実体化します
4. 両方の転送入力で task-plan-worker-runtime を起動します
5. PHASE_6_DELEGATE_TASK_PLAN に child_run メタデータをチェックポイントします
6. --run-id と --summary-artifact-path を指定して ln-302-task-replanner を呼び出します
7. 結果として得られた子の task-plan アーティファクトのみを読み取ります

ワーカーに渡すもの:

• CREATE モードと同じデータ + existingTaskIds

ワーカーが返すもの: 操作のサマリー + 子の task-plan アーティファクト

ステップ 5: 呼び出し元に構造化されたサマリーを返します

---

ランタイムサマリーアーティファクト

必読: references/test_planning_summary_contract.md、references/test_planning_worker_runtime_contract.md、references/task_plan_worker_runtime_contract.md を読み込んでください

ランタイムプロファイル:

• family: test-planning-worker
• worker: ln-523
• summary kind: test-planning-worker
• コーディネーターが使用するペイロードフィールド: worker、status、warnings、test_task_id、test_task_url、coverage_summary、planned_scenarios

呼び出しルール:

• スタンドアロン: runId と summaryArtifactPath を省略します
• 管理対象: runId と正確な summaryArtifactPath の両方を渡します
• 終了結果の前に、必ず検証済みのサマリーを書き込みます

委任された子ワーカーのルール:

• ln-301 または ln-302 に委任する場合、ln-523 が親ランタイムになります
• 委任の前に task-plan-worker-runtime を起動します
• 子 Skill の呼び出し前に child_run メタデータをチェックポイントします
• 子の task-plan アーティファクトのみを消費し、子の散文は決して消費しません

完了の定義

調査結果と手動テスト結果の読み込み：

• 調査コメント「## Test Research: {Feature}」が見つかっている（ln-521 から）
• 手動テスト結果「## Manual Testing Results」が見つかっている（ln-522 から）
• 少なくとも 1 つの AC が PASSED とマークされている

リスクベースのテスト計画の作成：

• すべてのシナリオについてリスク優先度マトリックスを算出している
• E2E テスト：ベースラインの正常系 + 異常系。追加するのは優先度 ≥15 の場合のみ
• 統合テスト：E2E でカバーされず、かつ優先度 ≥15 の場合のみ
• 単体テスト：複雑なビジネスロジックがあり、優先度 ≥15 の場合のみ
• 各テストが 6 つすべての有用性基準を満たしている
• フレームワーク／ライブラリのテストがない：各テストでは自社のビジネスロジックのみを検証している

テストタスクの説明の完成（11 セクション）：

• テンプレートに従って 11 セクションすべてに記入している
• リスク優先度マトリックスを含めている
• ベースラインの 2 テストを超える各テストの追加理由を説明している

ワーカーへの委任の実行：

• CREATE MODE：task-plan-worker-runtime を通じて ln-301-task-creator に委任している
• REPLAN MODE：task-plan-worker-runtime を通じて ln-302-task-replanner に委任している
• 委任前に子実行のメタデータをチェックポイントに保存している
• 最終サマリーの前に子の task-plan アーティファクトを取得している
• トラッカーの Issue／Story URL を返している

出力：

• CREATE MODE： トラッカーの Issue／Story URL + 確認
• REPLAN MODE： 操作サマリー + URL

参照ファイル

• 環境状態： references/environment_state_contract.md
• ストレージモードの操作： references/storage_mode_detection.md
• リスクベーステストの契約： references/risk_based_testing_guide.md
• 任意の手法カタログ： references/risk_based_testing_methodology.md
• 自動検出パターン： references/auto_discovery_pattern.md
• テストタスクのテンプレート： references/templates/test_task_template.md（ワーカー ln-301／ln-302 がテンプレートの読み込みを通じて読み込みます）
• テストの例： references/risk_based_testing_examples.md
• 必須の読み込み： references/research_tool_fallback.md を読み込みます

重要なルール

• 手動テスト結果を優先： 利用可能な場合は ln-522 の手動テスト結果を使用します。見つからない場合（簡易モード）は、最小限のインライン調査を生成し、手動テストをスキップしたとマークします
• 単体テストより E2E を優先： ベースラインは常に E2E 2 件（正常系 + 異常系）です。単体テスト／統合テストを追加するのは優先度が 15 以上の場合のみです
• フレームワークのテスト禁止： すべてのテストで自社のビジネスロジックを検証する必要があります。ライブラリ／フレームワークの動作をテストしてはいけません
• 有用性の徹底： ベースラインを超える各テストは、6 つすべての有用性基準を満たす必要があります（risk_based_testing_guide.md を参照）
• 作成せずに委任： タスクの作成は ln-301／ln-302 ワーカーを通じて行います。このスキルでは計画のみを作成します
• 管理された子実行のみ： ln-301／ln-302 への親子委任では、task-plan-worker-runtime、決定的な子の runId、正確な子の summaryArtifactPath を使用し、アーティファクトのみを取得する必要があります

ベストプラクティス

最小限の実用的なテスト： ベースラインの E2E（正常系 + 異常系）から始めます。追加する各テストは、6 つすべての有用性基準を満たす必要があります。

リスクベーステスト： ビジネスへの影響度 × 発生確率に基づいて優先順位を付けます。実際の手動テスト結果を基に、E2E を優先します。優先度 15 以上のシナリオをテストでカバーします。

期待値ベースのテスト： 決定論的なテストでは、diff を使って実際の結果と期待値を比較します。必須の読み込み： ../ln-522-manual-tester/SKILL.md の「テスト設計の原則」セクションを読み込みます。

---

バージョン： 1.0.0 最終更新日： 2026-01-15