Initial commit
This commit is contained in:
549
skills/task-decomposer/SKILL.md
Normal file
549
skills/task-decomposer/SKILL.md
Normal file
@@ -0,0 +1,549 @@
|
||||
---
|
||||
name: task-decomposer
|
||||
description: 複雑な作業を単一目的の小さなタスクに分解する。タスク分解時、作業細分化時、スキル設計時、またはユーザーがタスク分解、作業分割、細分化、単一目的、タスク粒度に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Task Decomposer
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供する複雑な作業や大きなタスクを、単一目的の小さなタスクに分解する。ユーザーとの対話を通じてタスクの詳細を理解し、適切な粒度のタスクに分解して、スキルやコマンドの設計を支援する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 複雑なタスクや大きな作業の収集
|
||||
- タスクの複雑度と依存関係の評価
|
||||
- タスクの分解と小タスクへの変換
|
||||
- タスク粒度の調整と最適化
|
||||
- 分解されたタスクリストの提供
|
||||
- タスク実行順序の提案
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: タスク収集
|
||||
|
||||
ユーザーとの対話を通じて、分解対象となる複雑なタスクや大きな作業を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 分解対象のタスクを確認する
|
||||
2. タスクの目的と期待される成果を把握する
|
||||
3. タスクの制約条件を確認する
|
||||
4. タスクに必要なリソースを特定する
|
||||
5. タスクの完了基準を明確にする
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【タスクの確認】
|
||||
分解したい複雑なタスクを教えてください。
|
||||
|
||||
1. タスク名: [タスクの名称]
|
||||
2. 目的: [このタスクで達成したいこと]
|
||||
3. 期待される成果: [タスク完了後の成果物や状態]
|
||||
4. 制約条件: [時間、リソース、技術的制約など]
|
||||
5. 完了基準: [どうなったら完了とするか]
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
タスク名: コードレビュープロセスの自動化
|
||||
目的: コードレビューの効率化と品質向上
|
||||
期待される成果:
|
||||
- 静的解析結果の自動確認
|
||||
- コーディング規約違反の自動検出
|
||||
- レビューコメントの自動生成
|
||||
- レビューレポートの自動作成
|
||||
|
||||
制約条件:
|
||||
- 既存のCI/CDパイプラインと統合する
|
||||
- GitHub APIを使用する
|
||||
- レビュー時間を50%削減する
|
||||
|
||||
完了基準:
|
||||
- 全ての成果物が実装されている
|
||||
- CI/CDパイプラインと統合されている
|
||||
- レビュー時間が50%削減されている
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
タスク名: レビュー
|
||||
目的: 良くする
|
||||
期待される成果: 何か
|
||||
制約条件: 特になし
|
||||
完了基準: 終わったら
|
||||
```
|
||||
|
||||
### フェーズ2: 複雑度評価
|
||||
|
||||
収集したタスクの複雑度を評価し、分解の必要性と方針を決定する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. タスクの規模を評価する(工数、影響範囲)
|
||||
2. タスクの複雑度を評価する(技術的難易度、依存関係)
|
||||
3. タスクの依存関係を特定する
|
||||
4. 分解の必要性を判断する
|
||||
5. 分解の方針を決定する
|
||||
|
||||
**評価基準:**
|
||||
|
||||
- **規模**: 小/中/大
|
||||
- 小: 1〜2時間で完了
|
||||
- 中: 半日〜1日で完了
|
||||
- 大: 2日以上必要
|
||||
- **複雑度**: 低/中/高
|
||||
- 低: 明確な手順があり、判断が不要
|
||||
- 中: 一部判断が必要だが、手順は明確
|
||||
- 高: 複雑な判断や技術的課題がある
|
||||
- **依存関係**: 独立/一部依存/強依存
|
||||
- 独立: 他のタスクに依存しない
|
||||
- 一部依存: 一部のタスクに依存する
|
||||
- 強依存: 多くのタスクに依存する
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【複雑度評価結果】
|
||||
|
||||
タスク: コードレビュープロセスの自動化
|
||||
|
||||
規模: 大
|
||||
- 工数: 5〜7日程度
|
||||
- 影響範囲: CI/CDパイプライン、レビュープロセス全体
|
||||
|
||||
複雑度: 高
|
||||
- 技術的課題: GitHub API連携、静的解析ツール統合、自然言語処理
|
||||
- 判断の必要性: レビューコメントの適切性、優先度判断
|
||||
|
||||
依存関係: 一部依存
|
||||
- CI/CDパイプラインの整備(前提条件)
|
||||
- GitHub リポジトリへのアクセス権限(前提条件)
|
||||
- 静的解析ツールの導入(並行作業可能)
|
||||
|
||||
分解の必要性: 必要
|
||||
- 理由: 規模が大きく、複雑度が高いため、小さなタスクに分解すべき
|
||||
|
||||
分解の方針:
|
||||
- 機能別に分解する(静的解析確認、規約違反検出、コメント生成など)
|
||||
- 各機能を独立したタスクとして実装する
|
||||
- 依存関係を明確にして実装順序を決定する
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【複雑度評価結果】
|
||||
|
||||
規模: 大きい
|
||||
複雑度: 難しい
|
||||
依存関係: ある
|
||||
分解の必要性: たぶん必要
|
||||
```
|
||||
|
||||
### フェーズ3: タスク分解
|
||||
|
||||
複雑なタスクを、単一目的の小さなタスクに分解する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. タスクを機能別に分解する
|
||||
2. 各小タスクの目的を明確にする
|
||||
3. 各小タスクの入力と出力を定義する
|
||||
4. 小タスク間の依存関係を整理する
|
||||
5. 小タスクの実行順序を決定する
|
||||
|
||||
**分解基準:**
|
||||
|
||||
- 1タスクは1つの明確な目的を持つ
|
||||
- タスクの完了基準が明確である
|
||||
- タスクの入力と出力が明確である
|
||||
- タスクは半日〜1日で完了できる粒度である
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【タスク分解結果】
|
||||
|
||||
元のタスク: コードレビュープロセスの自動化
|
||||
|
||||
分解されたタスク:
|
||||
|
||||
タスク1: プルリクエスト情報取得
|
||||
- 目的: GitHub APIからプルリクエスト情報を取得する
|
||||
- 入力: プルリクエストURL
|
||||
- 出力: PR情報(タイトル、説明、変更ファイル、コミットリスト)
|
||||
- 依存関係: なし
|
||||
- 工数: 半日
|
||||
|
||||
タスク2: 静的解析結果確認
|
||||
- 目的: CI/CDパイプラインの静的解析結果を確認する
|
||||
- 入力: CI/CDパイプライン結果
|
||||
- 出力: 静的解析問題リスト(linter、型チェック、セキュリティスキャン)
|
||||
- 依存関係: なし
|
||||
- 工数: 半日
|
||||
|
||||
タスク3: コーディング規約違反検出
|
||||
- 目的: コード変更がコーディング規約に違反していないか確認する
|
||||
- 入力: 変更されたコード、コーディング規約定義
|
||||
- 出力: 規約違反リスト(違反箇所、違反内容、重要度)
|
||||
- 依存関係: タスク1(変更ファイル情報が必要)
|
||||
- 工数: 1日
|
||||
|
||||
タスク4: テストカバレッジ確認
|
||||
- 目的: テストカバレッジを確認し、不足箇所を特定する
|
||||
- 入力: テスト実行結果、カバレッジレポート
|
||||
- 出力: カバレッジ分析結果(カバレッジ率、未カバー箇所)
|
||||
- 依存関係: なし
|
||||
- 工数: 半日
|
||||
|
||||
タスク5: レビューコメント生成
|
||||
- 目的: 検出された問題からレビューコメントを生成する
|
||||
- 入力: 静的解析問題リスト、規約違反リスト、カバレッジ分析結果
|
||||
- 出力: レビューコメント(問題箇所、修正提案、優先度)
|
||||
- 依存関係: タスク2、タスク3、タスク4
|
||||
- 工数: 1日
|
||||
|
||||
タスク6: レビューレポート作成
|
||||
- 目的: レビュー結果をまとめたレポートを作成する
|
||||
- 入力: レビューコメント、PR情報
|
||||
- 出力: レビューレポート(Markdown形式)
|
||||
- 依存関係: タスク1、タスク5
|
||||
- 工数: 半日
|
||||
|
||||
タスク7: CI/CDパイプライン統合
|
||||
- 目的: 自動化されたレビュープロセスをCI/CDパイプラインに統合する
|
||||
- 入力: 全タスクの成果物
|
||||
- 出力: CI/CD設定ファイル、統合ドキュメント
|
||||
- 依存関係: タスク1〜6(全タスク完了後)
|
||||
- 工数: 1日
|
||||
|
||||
合計工数: 5.5日
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【タスク分解結果】
|
||||
|
||||
タスク1: 準備する
|
||||
タスク2: 実装する
|
||||
タスク3: 終わらせる
|
||||
```
|
||||
|
||||
### フェーズ4: 粒度調整
|
||||
|
||||
分解されたタスクの粒度を確認し、必要に応じて調整する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 各タスクの粒度を確認する
|
||||
2. 大きすぎるタスクをさらに分解する
|
||||
3. 小さすぎるタスクを統合する
|
||||
4. タスクの完了基準を明確にする
|
||||
5. タスクの優先順位を付ける
|
||||
|
||||
**調整基準:**
|
||||
|
||||
- **適切な粒度**: 半日〜1日で完了できる
|
||||
- **大きすぎる**: 2日以上かかる場合は分解を検討
|
||||
- **小さすぎる**: 1〜2時間で完了する場合は統合を検討
|
||||
- **単一責任**: 1タスクは1つの明確な目的を持つ
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【粒度調整結果】
|
||||
|
||||
調整対象: タスク3(コーディング規約違反検出)
|
||||
|
||||
調整前:
|
||||
- 工数: 1日
|
||||
- 粒度評価: 適切
|
||||
|
||||
調整内容: なし(粒度は適切)
|
||||
|
||||
調整対象: タスク5(レビューコメント生成)
|
||||
|
||||
調整前:
|
||||
- 工数: 1日
|
||||
- 粒度評価: やや大きい
|
||||
|
||||
調整後:
|
||||
タスク5-1: 問題の優先度付け
|
||||
- 目的: 検出された問題に優先度を付ける
|
||||
- 入力: 静的解析問題リスト、規約違反リスト、カバレッジ分析結果
|
||||
- 出力: 優先度付き問題リスト
|
||||
- 工数: 半日
|
||||
|
||||
タスク5-2: レビューコメント生成
|
||||
- 目的: 優先度付き問題からレビューコメントを生成する
|
||||
- 入力: 優先度付き問題リスト
|
||||
- 出力: レビューコメント
|
||||
- 工数: 半日
|
||||
|
||||
調整理由: 優先度付けとコメント生成を分離することで、責任が明確になり、実装しやすくなる
|
||||
|
||||
【最終タスクリスト】
|
||||
|
||||
1. プルリクエスト情報取得(半日)
|
||||
2. 静的解析結果確認(半日)
|
||||
3. コーディング規約違反検出(1日)
|
||||
4. テストカバレッジ確認(半日)
|
||||
5-1. 問題の優先度付け(半日)
|
||||
5-2. レビューコメント生成(半日)
|
||||
6. レビューレポート作成(半日)
|
||||
7. CI/CDパイプライン統合(1日)
|
||||
|
||||
合計工数: 5.5日
|
||||
|
||||
【優先順位】
|
||||
|
||||
優先度1(必須):
|
||||
- タスク1: プルリクエスト情報取得
|
||||
- タスク2: 静的解析結果確認
|
||||
- タスク3: コーディング規約違反検出
|
||||
|
||||
優先度2(推奨):
|
||||
- タスク4: テストカバレッジ確認
|
||||
- タスク5-1: 問題の優先度付け
|
||||
- タスク5-2: レビューコメント生成
|
||||
|
||||
優先度3(オプション):
|
||||
- タスク6: レビューレポート作成
|
||||
- タスク7: CI/CDパイプライン統合
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【粒度調整結果】
|
||||
|
||||
調整なし
|
||||
```
|
||||
|
||||
### フェーズ5: 推奨提示
|
||||
|
||||
分解されたタスクリストをユーザーに提示し、実装の指針を提供する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 最終タスクリストを提示する
|
||||
2. タスクの実行順序を明示する
|
||||
3. タスク間の依存関係を図示する
|
||||
4. 実装の優先順位を提案する
|
||||
5. 次のステップを案内する
|
||||
|
||||
**提示形式:**
|
||||
|
||||
```markdown
|
||||
【分解されたタスクリスト】
|
||||
|
||||
合計タスク数: 8個
|
||||
合計工数: 5.5日
|
||||
|
||||
タスク一覧:
|
||||
|
||||
1. プルリクエスト情報取得(半日)
|
||||
- GitHub APIからプルリクエスト情報を取得する
|
||||
- 依存: なし
|
||||
|
||||
2. 静的解析結果確認(半日)
|
||||
- CI/CDパイプラインの静的解析結果を確認する
|
||||
- 依存: なし
|
||||
|
||||
3. コーディング規約違反検出(1日)
|
||||
- コード変更がコーディング規約に違反していないか確認する
|
||||
- 依存: タスク1
|
||||
|
||||
4. テストカバレッジ確認(半日)
|
||||
- テストカバレッジを確認し、不足箇所を特定する
|
||||
- 依存: なし
|
||||
|
||||
5-1. 問題の優先度付け(半日)
|
||||
- 検出された問題に優先度を付ける
|
||||
- 依存: タスク2、タスク3、タスク4
|
||||
|
||||
5-2. レビューコメント生成(半日)
|
||||
- 優先度付き問題からレビューコメントを生成する
|
||||
- 依存: タスク5-1
|
||||
|
||||
6. レビューレポート作成(半日)
|
||||
- レビュー結果をまとめたレポートを作成する
|
||||
- 依存: タスク1、タスク5-2
|
||||
|
||||
7. CI/CDパイプライン統合(1日)
|
||||
- 自動化されたレビュープロセスをCI/CDパイプラインに統合する
|
||||
- 依存: タスク1〜6
|
||||
|
||||
【実行順序】
|
||||
|
||||
フェーズ1(並列実行可能):
|
||||
- タスク1: プルリクエスト情報取得
|
||||
- タスク2: 静的解析結果確認
|
||||
- タスク4: テストカバレッジ確認
|
||||
|
||||
フェーズ2:
|
||||
- タスク3: コーディング規約違反検出(タスク1完了後)
|
||||
|
||||
フェーズ3:
|
||||
- タスク5-1: 問題の優先度付け(タスク2、3、4完了後)
|
||||
|
||||
フェーズ4:
|
||||
- タスク5-2: レビューコメント生成(タスク5-1完了後)
|
||||
|
||||
フェーズ5:
|
||||
- タスク6: レビューレポート作成(タスク1、5-2完了後)
|
||||
|
||||
フェーズ6:
|
||||
- タスク7: CI/CDパイプライン統合(全タスク完了後)
|
||||
|
||||
【スキル・コマンドへのマッピング】
|
||||
|
||||
各タスクはワークフロースキルとして実装することを推奨:
|
||||
|
||||
- pull-request-analyzer(タスク1)
|
||||
- static-analysis-checker(タスク2)
|
||||
- code-quality-reviewer(タスク3)
|
||||
- test-coverage-analyzer(タスク4)
|
||||
- issue-prioritizer(タスク5-1)
|
||||
- review-comment-generator(タスク5-2)
|
||||
- review-report-writer(タスク6)
|
||||
- cicd-integrator(タスク7)
|
||||
|
||||
【次のステップ】
|
||||
|
||||
1. 各タスクをワークフロースキルとして設計(workflow-analyzer スキルを使用)
|
||||
2. 必要なコンベンションスキルを特定(coding-conventionsなど)
|
||||
3. エージェントを設計(responsibility-mapper スキルを使用)
|
||||
4. コマンドを設計(command-generator スキルを使用)
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
タスクリストが明確で、実行順序、依存関係、スキルへのマッピングが示されており、次のステップが案内されている。
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
タスクをいくつか作った
|
||||
```
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **分解されたタスクリスト**: 単一目的の小さなタスクのリスト(目的、入力、出力、工数を含む)
|
||||
- **タスク実行順序**: タスクの依存関係と実行順序を明示したドキュメント
|
||||
- **スキル・コマンドへのマッピング**: 各タスクをスキルやコマンドにマッピングした推奨案
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: タスクが大きすぎる
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
タスク: システム全体を実装する(10日)
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- タスクを機能別に分解する
|
||||
- 1タスクは半日〜1日で完了できる粒度にする
|
||||
- タスクの完了基準を明確にする
|
||||
|
||||
### エラー2: タスクが小さすぎる
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
タスク: 変数名を変更する(10分)
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 小さなタスクを統合する
|
||||
- 関連するタスクをまとめて1つのタスクにする
|
||||
- タスクの粒度を調整する
|
||||
|
||||
### エラー3: タスクの依存関係が不明確
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
タスク間の依存関係: よくわからない
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 各タスクの入力と出力を明確にする
|
||||
- どのタスクの出力がどのタスクの入力になるかを整理する
|
||||
- 依存関係を図示する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- タスクは単一目的にする(1タスク1目的)
|
||||
- タスクの粒度は半日〜1日で完了できるようにする
|
||||
- タスクの完了基準を明確にする
|
||||
- タスクの入力と出力を明示する
|
||||
- タスク間の依存関係を明確にする
|
||||
- 実行順序を明示する(並列実行可能なタスクを特定)
|
||||
- スキルやコマンドへのマッピングを提供する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### タスク収集完了時
|
||||
|
||||
- [ ] 分解対象のタスクが確認されている
|
||||
- [ ] タスクの目的と期待される成果が把握されている
|
||||
- [ ] タスクの制約条件が確認されている
|
||||
- [ ] タスクに必要なリソースが特定されている
|
||||
- [ ] タスクの完了基準が明確になっている
|
||||
|
||||
### 複雑度評価完了時
|
||||
|
||||
- [ ] タスクの規模が評価されている
|
||||
- [ ] タスクの複雑度が評価されている
|
||||
- [ ] タスクの依存関係が特定されている
|
||||
- [ ] 分解の必要性が判断されている
|
||||
- [ ] 分解の方針が決定されている
|
||||
|
||||
### タスク分解完了時
|
||||
|
||||
- [ ] タスクが機能別に分解されている
|
||||
- [ ] 各小タスクの目的が明確になっている
|
||||
- [ ] 各小タスクの入力と出力が定義されている
|
||||
- [ ] 小タスク間の依存関係が整理されている
|
||||
- [ ] 小タスクの実行順序が決定されている
|
||||
|
||||
### 粒度調整完了時
|
||||
|
||||
- [ ] 各タスクの粒度が確認されている
|
||||
- [ ] 大きすぎるタスクが分解されている
|
||||
- [ ] 小さすぎるタスクが統合されている
|
||||
- [ ] タスクの完了基準が明確になっている
|
||||
- [ ] タスクの優先順位が付けられている
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 最終タスクリストが提示されている
|
||||
- [ ] タスクの実行順序が明示されている
|
||||
- [ ] タスク間の依存関係が図示されている
|
||||
- [ ] 実装の優先順位が提案されている
|
||||
- [ ] スキル・コマンドへのマッピングが提供されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 分解されたタスクリストが作成されている
|
||||
- [ ] タスク実行順序が作成されている
|
||||
- [ ] スキル・コマンドへのマッピングが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
Reference in New Issue
Block a user