name: task-analysis description: タスク分解・調査フェーズで使用する分析スキル。Issue仕様の構造化、コードベース調査の手法、タスク粒度の判断基準を定義する。Issue分析・コード調査・タスク設計時に使用する。 allowed-tools: Read, Glob, Grep, TaskCreate, TaskUpdate, TaskGet, TaskList

タスク分析スキル

Issue仕様の構造化

Issue仕様を以下の観点で構造化して把握する。

機能要件の抽出

• 目的: この変更で何を達成するか
• ユーザーストーリー: 誰が、何を、なぜ行うか
• 受け入れ条件: 完了の判定基準
• 制約条件: 技術的・ビジネス的な制約

技術要件の抽出

• 変更種別: 新規追加 / 修正 / 削除 / リファクタリング
• 影響範囲: フロントエンド / バックエンド / インフラ / DB
• データモデル変更: スキーマ変更の有無
• API変更: エンドポイントの追加・変更の有無

コードベース調査の手法

ドメイン概念の検索

1. Issue内のキーワードからドメイン概念を抽出する
2. src/domain/ 配下で関連するエンティティ・値オブジェクトを検索する
3. src/domain/ports/ で関連するPortインターフェースを確認する
4. src/domain/usecases/ で関連するUseCaseを確認する

既存パターンの調査

1. 類似機能の実装を見つける（同じ種類のエンティティやユースケース）
2. ディレクトリ構造とファイル命名のパターンを把握する
3. テストの書き方のパターンを把握する
4. NestJSモジュールのDI設定パターンを把握する

影響範囲の調査

1. 変更対象ファイルのimport/exportを追跡する
2. TypeORMエンティティの関連テーブルを確認する
3. NestJSモジュールの依存関係を確認する

タスク粒度の判断基準

適切な粒度

• 1つのテストファイルで検証できる範囲
• 1つのDDD層内で完結する変更
• diffが概ね200行以内に収まる変更
• レビュアーが短時間で理解できる変更

粒度が大きすぎるサイン

• 複数のDDD層にまたがる変更が1タスクに含まれている
• テストケースが10個以上必要になる
• 変更ファイルが5個以上ある

粒度が小さすぎるサイン

• 単体ではテストできない（依存する実装が別タスク）
• 変更がインターフェース定義のみで振る舞いがない
• 他のタスクと必ずセットでないと意味がない