/edgecase-analysis

description: システムの各レイヤーにおける包括的なエッジケース・エラー状態を詳細に分析し、見落としがちな異常系シナリオを洗い出します
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite, AskUserQuestion
argument-hint: [要件名]

システムの各レイヤーにおける包括的なエッジケース・エラー状態を分析します。アプリケーション・UI・データ・ネットワーク・非同期・認証などの各層で発生する複合的なエッジケースを詳細に洗い出します。

context

出力ディレクトリ=".dcs" カレントディレクトリ={{プロジェクトルート}} 分析モード="" # "requirements-based" or "source-based" 要件名="" # 要件定義書ベースの場合 分析対象="" # ソースコードベースの場合 収集情報={} # 要件定義書の内容 or ソースコードから収集した情報 分析ファイルリスト=[] チェックリストパス="" # check_list.md のパス 既存チェックリスト=[] # 既に登録されているチェックリスト項目 調査段階=1 エッジケースカテゴリ=[ "アプリケーション層ビジネスロジック", "UI状態", "データ管理層", "ネットワーク通信層", "非同期処理・メッセージング", "認証・認可", "エラーハンドリング", "データモデル状態組み合わせ", "複合的なエッジケース" ]

step

• $1 がない場合、「引数に要件名または分析対象を指定してください（例: /tsumiki:dcs:kairo-edgecase-analysis ユーザー認証システム）」と言って終了する
• $1 の内容を context に保存する
• context の内容をユーザに宣言する
• step0 を実行する

step0: 分析モードの判定

• 要件定義書の確認
• `docs/spec/{$1}/requirements.md` が存在するか確認
• 存在する場合:
• 要件定義書ベースの分析を実施
• context を更新:
• 分析モード = "requirements-based"
• 要件名 = $1
• 「要件定義書「{{要件名}}」に基づいてエッジケース分析を実施します」と宣言
• step1 を実行する（要件定義書ベースの分析）
• 存在しない場合:
• AskUserQuestion ツールを使って分析方法を質問する:
• question: "要件定義書が見つかりません。どのように分析を進めますか?"
• header: "分析方法"
• multiSelect: false
• options:
• label: "ソースコードから分析（推奨）"

description: "既存のソースコードを分析してエッジケースを特定します"

• label: "要件定義書を作成してから分析"

description: "先に要件定義書を作成し、その後エッジケース分析を実施します"

• ユーザーの選択に応じて分岐:
• "ソースコードから分析" を選択した場合:
• ソースコードベースの分析を実施
• context を更新:
• 分析モード = "source-based"
• 分析対象 = $1
• step1-source を実行する（ソースコードベースの分析）
• "要件定義書を作成してから分析" を選択した場合:
• 「要件定義書の作成が必要です。先に `/tsumiki:dev-plan {要件名} "{要件概要}"`（Full-spec モードで EARS 要件定義を作成）を実行してください」とメッセージを表示
• 終了する

step1: 要件情報の収集（要件定義書ベース）

• 要件定義書の確認
• `docs/spec/{要件名}/requirements.md` を Read で読み込み
• 読み込んだ内容を一時変数に保存

• 設計文書の確認
• `docs/spec/{要件名}/design.md` が存在する場合は読み込み
• `docs/design/` ディレクトリ内の関連設計文書を検索・読み込み
• 読み込んだ内容を一時変数に保存

• タスクノートの確認
• `docs/spec/{要件名}/note.md` が存在する場合は読み込み
• 読み込んだ内容を一時変数に保存

• 既存のエッジケース分析の確認
• {{出力ディレクトリ}}/{{timestamp}}_*_edgecase/ を検索
• 既存の分析がある場合は最新のものを参照

• 収集した情報のサマリーを作成し、context の収集情報に保存
• 要件の概要
• 主要機能リスト
• 既知の制約事項
• 技術スタック
• 要件定義書の内容
• 設計文書の内容
• タスクノートの内容

• step2 を実行する

step1-source: ソースコードからの対象特定と情報収集

• ユーザーに分析内容を確認する
• 「ソースコードから「{{分析対象}}」に関連するエッジケースを分析します」と宣言

• Task ツールで関連ファイル・情報の特定を実行する
• subagent_type: "Explore"
• model: "haiku"
• description: "エッジケース分析対象の特定"
• prompt: 以下の内容でエージェントに依頼

    「{{分析対象}}」に関連する以下の情報を収集してください：

    1. 関連するソースコードファイルの特定
       - メインロジック（ビジネスロジック、コントローラー、サービス等）
       - データモデル・スキーマ定義
       - API エンドポイント定義
       - UI コンポーネント（該当する場合）
       - テストコード
       - 設定ファイル

    2. 技術スタックの把握
       - 使用されているフレームワーク
       - ライブラリ・パッケージ
       - データベース・ストレージ
       - 外部API・サービス連携

    3. アーキテクチャパターンの理解
       - レイヤー構造
       - データフロー
       - エラーハンドリング方針
       - 非同期処理の有無
       - 認証・認可の仕組み

    4. 既存のエラーハンドリング状況
       - try-catch の使用箇所
       - バリデーションの実装
       - リトライ・フォールバック処理
       - ログ出力

    収集した情報を構造化してまとめてください。

• Explore エージェントの結果を受け取る

• 収集した情報のサマリーを作成し、context の収集情報に保存
• 分析対象の概要
• 関連ファイルリスト（相対パスで記載）
• 技術スタック
• アーキテクチャパターン
• データフロー
• 既存のエラーハンドリング状況
• 非同期処理の実装状況
• 認証・認可の仕組み

• ユーザーに収集結果を報告し、続行確認を得る
• 「以下の情報を収集しました。この内容でエッジケース分析を続行しますか？」
• サマリーを表示（主要なファイル、技術スタック、識別されたリスク領域など）

• step2 を実行する

step2: 分析スコープの決定

• AskUserQuestion ツールを使って分析スコープを質問する：
• question: "エッジケース分析のスコープを選択してください"
• header: "分析スコープ"
• multiSelect: false
• options:
• label: "包括的分析（推奨）"

description: "全レイヤーのエッジケースを網羅的に分析。発生可能性・影響度を詳細評価"

• label: "重点分析"

description: "主要レイヤーのみ分析。Must Have要件に集中"

• label: "カスタム"

description: "分析対象レイヤーを個別に選択"

• ユーザーの選択を context に保存

• カスタムを選択した場合は、AskUserQuestion ツールを使って分析対象レイヤーを質問：
• question: "分析対象のレイヤーを選択してください（複数選択可）"
• header: "対象レイヤー"
• multiSelect: true
• options:
• label: "アプリケーション層"

description: "ビジネスロジックの状態遷移・バリデーション"

• label: "UI層"

description: "画面状態・ユーザー操作の組み合わせ"

• label: "データ管理層"

description: "トランザクション・同期・キャッシュ"

• label: "ネットワーク通信層"

description: "HTTPエラー・タイムアウト・リトライ"

• label: "非同期処理層"

description: "ジョブキュー・ワークフロー・並行処理"

• label: "認証・認可層"

description: "セッション・権限・トークン"

• label: "複合的エッジケース"

description: "複数レイヤーにまたがる複雑なケース"

• step3 を実行する

step3: 初期分析の実行とチェックリスト初期化

• 出力ディレクトリの決定
• Bash ツールで現在のタイムスタンプを取得する
• `date +%Y%m%d%H%M%S` で yyyyMMddHHmmss 形式のタイムスタンプを取得
• {{出力ディレクトリ}}/{{timestamp}}_*/ を検索して既存の分析を確認
• 分析対象を英語化する
• 要件定義書ベースの場合: 要件名を英語化（例: "user_auth_edgecase"）
• ソースコードベースの場合: 分析対象を英語化（例: "task_manager_edgecase"）
• **カレントディレクトリからの相対パスとして**ベースディレクトリを決定する
• 相対パス形式: "{{出力ディレクトリ}}/{{timestamp}}_{{英語化名}}_edgecase"
• 例: ".dcs/20251219103045_user_auth_edgecase"
• **絶対パスは使用しない**（例: `/Users/kuroeda.makoto/projects/ensemble/.dcs/...` のような形式は使わない）

• チェックリストファイルのパス設定
• チェックリストパス = "{{ベースディレクトリ}}/check_list.md" （相対パス）

• 既存チェックリストの読み込み（オプション）
• ユーザーが他のチェックリストファイルを指定している場合、Read で読み込む
• 読み込んだチェックリスト項目を 既存チェックリスト に追加
• 形式: "- [ ] P0 説明 [リンク](path)"

• 分析結果ファイルのリストを準備する（すべて相対パスで記述）
• インデックスファイル: "{{ベースディレクトリ}}/index.md"
• チェックリストファイル: "{{ベースディレクトリ}}/check_list.md"
• 初期分析ファイル: "{{ベースディレクトリ}}/initial_analysis.md"
• レイヤー別分析ファイル（500行超過時は枝番付き）:
• "{{ベースディレクトリ}}/layer_analysis_app.md" (アプリケーション層)
• "{{ベースディレクトリ}}/layer_analysis_ui.md" (UI層)
• "{{ベースディレクトリ}}/layer_analysis_data.md" (データ管理層)
• "{{ベースディレクトリ}}/layer_analysis_network.md" (ネットワーク通信層)
• "{{ベースディレクトリ}}/layer_analysis_async.md" (非同期処理層)
• "{{ベースディレクトリ}}/layer_analysis_auth.md" (認証・認可層)
• "{{ベースディレクトリ}}/layer_analysis_summary.md" (サマリー)
• 複合分析ファイル（500行超過時は枝番付き）:
• "{{ベースディレクトリ}}/combined_analysis_data_state.md" (データモデル状態組み合わせ)
• "{{ベースディレクトリ}}/combined_analysis_multi_layer.md" (複数レイヤー)
• "{{ベースディレクトリ}}/combined_