shinpr タスクアナライザー
メタ認知的タスク分析とスキル選択ガイダンスを提供。
スキルインデックス
利用可能なスキルのメタデータは skills-index.yaml を参照。
タスク分析プロセス
1. タスク本質の理解
表面的な作業を超えた根本目的を特定：
| 表面的な作業 | 根本目的 |
|---|---|
| 「このバグを直して」 | 問題解決、根本原因分析 |
| 「この機能を実装して」 | 機能追加、価値提供 |
| 「このコードをリファクタリングして」 | 品質改善、保守性向上 |
| 「このファイルを更新して」 | 変更管理、一貫性確保 |
キーとなる質問：
- 本当に解決しようとしている問題は何か？
- 期待される成果は何か？
- 表面的にアプローチした場合、何が問題になり得るか？
2. 構造スケールの見積もり
意図された成果と責務境界から判断負荷を分類する。ファイル数は補助的なエビデンスにとどまる。
| スケール | 判断負荷 |
|---|---|
| 小規模 | まとまった成果が1つで、1つの責務境界の中にリポジトリの根拠がある明白な実装が1つあり、後続作業に長く影響する未解決の選択がない |
| 中規模 | まとまった成果が1つで、境界をまたいだ調整を伴うか、後続作業に長く影響しうる選択を含む |
| 大規模 | 独立して価値を持つ成果が複数あり、それぞれ別個の設計判断を要する |
レイヤーをまたぐ実装であっても、まとまった成果1つに資する場合は中規模のままでよい。documentation-criteria のADR両フィルタを通過する決定ポイントがある場合、スケールは最低でも中規模に引き上げられる。成果と境界の分類を成立させたエビデンスを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 または unknown> # 補助的なエビデンスのみ
scaleRationale:
decidingAxis: <outcomes|responsibility-boundaries|durable-choice>
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、primarytype、該当するsecondaryTypesを記録したら規模見積もりへ進む。依頼された成果が曖昧な場合は、必要な成果判断を具体的に記録する。 - 規模ゲート: 構造スケールを判断できるだけの成果と責務境界の根拠が揃い、
scaleRationaleに決定軸が示されたらスキル照合へ進む。 - 選択ゲート: 選択したスキルがすべて
skills-index.yamlに存在し、タスクに結び付いた理由があり、metadataを作り出さずそのまま転記できた場合に確定する。
不明点が成果の境界・ADRの適格性・必要なワークフローを変えうる場合は、必要なリポジトリ内の根拠またはユーザー判断を具体的に求める。ファイル数が不明であることだけでは構造スケールの判断は妨げられない。
スキル選択の優先順位
- 必須 - タスクタイプに直接関連
- 品質 - テストと品質保証
- プロセス - ワークフローとドキュメント
- 補助 - タスクに直接関係する追加の制約または根拠
メタ認知質問の設計
意図の分類、規模、選択するskill、必須制約、検証方法のいずれかを変え得る質問だけを生成する。リポジトリ内の根拠ですでに解決している場合は質問を返さない。各質問について、それが制御する判断を記録する。
| タスクタイプ | 質問の焦点 |
|---|---|
| implementation | 設計の妥当性、エッジケース、パフォーマンス |
| fix | 根本原因（5 Whys）、影響範囲、回帰テスト |
| refactoring | 現状の問題、目標状態、段階的計画 |
| design | 要件の明確性、トレードオフ |
| documentation | 読み手、正規の情報源、承認・利用側の契約 |
| investigation | 解決する主張、根拠の境界、停止条件 |
| migration | 互換期間、データ・契約の移行、ロールバック |
| operations | 対象環境、権限境界、復旧のエビデンス |
| security | 信頼境界、保護対象、脅威の発生源、リスク受容の決定権者 |
| skill | 発火させる意図、単独実行に必要なコンテキスト、出力の利用側 |
警告パターン
これらのパターンを検出してフラグを立てる：
| パターン | 警告 | 緩和策 |
|---|---|---|
| 1つのステップに独立して検証可能な成果が複数ある | 移行とロールバックのリスク | 観測可能な検証境界で分割 |
| 振る舞いの変更にテストまたは明記された実行可能な検証がない | リグレッションのエビデンスがない | 変更した契約を観測できる最も低コストなチェックを追加 |
| 修正案と失敗の間に観測済みの因果関係がない | 根本原因が推測のまま | 修正を選ぶ前に再現エビデンスと最初の因果境界を記録 |
| 中規模・大規模の実装に規模上必要な計画成果物がない | スコープと依存の契約がない | 実装を振り分ける前に必要な成果物を作成 |