Task Analyzer

タスクアナライザー

メタ認知的タスク分析とスキル選択ガイダンスを提供。

スキルインデックス

利用可能なスキルのメタデータは skills-index.yaml を参照。

タスク分析プロセス

1. タスク本質の理解

表面的な作業を超えた根本目的を特定：

| 表面的な作業 | 根本目的 |

|-------------|---------|

| 「このバグを直して」 | 問題解決、根本原因分析 |

| 「この機能を実装して」 | 機能追加、価値提供 |

| 「このコードをリファクタリングして」 | 品質改善、保守性向上 |

| 「このファイルを更新して」 | 変更管理、一貫性確保 |

キーとなる質問：

• 本当に解決しようとしている問題は何か？
• 期待される成果は何か？
• 表面的にアプローチした場合、何が問題になり得るか？

2. タスク規模の見積もり

ファイル数は判断材料の1つであり、決定ルールではない。以下の軸をすべて評価し、観測したいずれかの軸が示す最も高い規模を選択する。

| 軸 | 小規模 | 中規模 | 大規模 |

|----|-------|-------|-------|

| 見積もりファイル数 | 1〜2 | 3〜5 | 6以上 |

| 観測可能な成果 | 1つの振る舞い | 関連する複数の振る舞い | 独立して検証できる複数の成果 |

| 契約・データ | 公開契約または永続データの変更なし | 後方互換性のある契約変更 | 破壊的な契約変更、schema migration、永続データmigration |

| 境界 | 1つのローカルモジュール/コンポーネント | 同一レイヤー内の複数モジュール | レイヤー間、サービス間、外部システムとの境界 |

| 判断リスク | 既存パターンをそのまま適用可能 | 境界の明確な技術判断が1つ | アーキテクチャ、セキュリティ、コンプライアンス、不可逆な運用判断 |

最終規模を決めた軸を記録する。機械的な生成ファイル更新だけでファイル数が多い場合は、振る舞いと検証経路が1つであることをリポジトリのワークフローから証明できれば規模を下げられる。その根拠をscaleRationaleに記録する。

規模がスキル優先度に影響：

• 大規模 → プロセス/ドキュメントスキルがより重要
• 小規模 → 実装スキルに集中

3. タスクタイプの特定

| タイプ | 特徴 | キースキル |

|--------|------|-----------|

| implementation | 新規コードまたはユーザーに見える振る舞い | coding-standards, typescript-testing |

| fix | 不具合またはリグレッションの解消 | coding-standards, typescript-testing |

| refactoring | 振る舞いを保った構造改善 | coding-standards, implementation-approach |

| design | アーキテクチャまたは契約の判断 | documentation-criteria, implementation-approach |

| quality | テスト、レビュー、検証 | typescript-testing, integration-e2e-testing |

| documentation | PRD、ADR、Design Doc、UI Spec、計画書、指示文 | documentation-criteria |

| investigation | 実装を伴わない根拠収集 | project-contextとindexから選んだドメインスキル |

| migration | データ、schema、API、依存、runtimeの移行 | implementation-approach, documentation-criteria |

| operations | 環境、デプロイ、runtimeの運用 | technical-specとindexから選んだドメインスキル |

| security | セキュリティ設計またはレビュー | coding-standardsと実装ドメインのスキル |

| skill | スキル作成、プロンプト品質レビュー、スキルmetadata変更 | skill-optimization, llm-friendly-context |

複数のtypeに該当する場合は、依頼された成果を担うtypeをprimaryとし、残りをsecondaryTypesに記録する。

4. タグベースのスキルマッチング

タスク説明から関連タグを抽出し、skills-index.yamlとマッチング：

Task: "Implement user authentication with tests"
Extracted tags: [implementation, testing, security]
Matched skills:
  - coding-standards (implementation, security)
  - typescript-testing (testing)
  - typescript-rules (implementation)

5. 暗黙的な関連性

隠れた依存関係を考慮：

| タスクに含まれる | 追加で含める |

|-----------------|-------------|

| エラーハンドリング | デバッグ、テスト |

| 新機能 | 設計、実装、ドキュメント |

| パフォーマンス | プロファイリング、最適化、テスト |

| フロントエンド | typescript-rules, typescript-testing |

| API/統合 | integration-e2e-testing |

出力形式

skills-index.yamlからのスキルメタデータを含む構造化された分析を返却：

taskAnalysis:
  essence: <string>  # 特定された根本目的
  type: <implementation|fix|refactoring|design|quality|documentation|investigation|migration|operations|security|skill>
  secondaryTypes: [<task-type>, ...]
  scale: <small|medium|large>
  estimatedFiles: <number>
  scaleRationale:
    decidingAxis: <files|outcomes|contracts-data|boundaries|decision-risk>
    evidence: <string>
  tags: [<string>, ...]  # タスク説明から抽出

selectedSkills:
  - skill: <skill-name>  # skills-index.yamlから
    priority: <high|medium|low>
    reason: <string>  # このスキルが選択された理由
    # skills-index.yamlからメタデータを引き継ぐ
    tags: [...]
    typical-use: <string>
    size: <small|medium|large>
    sections: [...]  # yamlからの全セクション（フィルタなし）

注意: セクション選択（どのセクションが関連するかの選定）は、実際のSKILL.mdファイルを読み込んだ後に別途行う。

プロセスゲート

• 意図ゲート: essence、primary type、該当するsecondaryTypesを記録したら規模見積もりへ進む。依頼された成果が曖昧な場合は、必要な成果判断を具体的に記録する。
• 規模ゲート: すべての規模軸について、観測済み、推測、不明のいずれかの根拠があり、scaleRationaleに決定軸が示されたらスキル照合へ進む。
• 選択ゲート: 選択したスキルがすべてskills-index.yamlに存在し、タスクに結び付いた理由があり、metadataを作り出さずそのまま転記できた場合に確定する。

見積もりファイル数または重要な契約・境界の判断が不明な場合はunknownとする。観測済みの根拠が示す最も高い規模を使用する。不明点によって規模が上がり、必要なワークフローが変わり得る場合は作業を止め、必要なリポジトリ内の根拠またはユーザー判断を具体的に求める。

スキル選択の優先順位

• 必須 - タスクタイプに直接関連
• 品質 - テストと品質保証
• プロセス - ワークフローとドキュメント
• 補助 - タスクに直接関係する追加の制約または根拠

メタ認知質問の設計

意図の分類、規模、選択するskill、必須制約、検証方法のいずれかを変え得る質問だけを生成する。リポジトリ内の根拠ですでに解決している場合は質問を返さない。各質問について、それが制御する判断を記録する。

| タスクタイプ | 質問の焦点 |

|-------------|-----------|

| implementation | 設計の妥当性、エッジケース、パフォーマンス |

| fix | 根本原因（5 Whys）、影響範囲、回帰テスト |

| refactoring | 現状の問題、目標状態、段階的計画 |

| design | 要件の明確性、将来の拡張性、トレードオフ |

| documentation | 読み手、正規の情報源、承認・利用側の契約 |

| investigation | 解決する主張、根拠の境界、停止条件 |

| migration | 互換期間、データ・契約の移行、ロールバック |

| operations | 対象環境、権限境界、復旧の証跡 |

| security | 信頼境界、保護対象、脅威・受け入れ条件の情報源 |

| skill | 発火させる意図、単独実行に必要なコンテキスト、出力の利用側 |

警告パターン

これらのパターンを検出してフラグを立てる：

| パターン | 警告 | 緩和策 |

|---------|------|--------|

| 1つのステップに独立して検証可能な成果が複数ある | 移行とロールバックのリスク | 観測可能な検証境界で分割 |

| 振る舞いの変更にテストまたは明記された実行可能な検証がない | リグレッションの証跡がない | 変更した契約を観測できる最も低コストなチェックを追加 |

| 修正案と失敗の間に観測済みの因果関係がない | 根本原因が推測のまま | 修正を選ぶ前に再現証跡と最初の因果境界を記録 |

| 中規模・大規模の実装に規模上必要な計画成果物がない | スコープと依存の契約がない | 実装を振り分ける前に必要な成果物を作成 |