gh-revtechstudio-rts-plugins-rts-plugin-generator/skills/task-decomposer/SKILL.md

---
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日で完了できるようにする
- タスクの完了基準を明確にする
- タスクの入力と出力を明示する
- タスク間の依存関係を明確にする
- 実行順序を明示する（並列実行可能なタスクを特定）
- スキルやコマンドへのマッピングを提供する

## チェックリスト

### タスク収集完了時

- [ ] 分解対象のタスクが確認されている
- [ ] タスクの目的と期待される成果が把握されている
- [ ] タスクの制約条件が確認されている
- [ ] タスクに必要なリソースが特定されている
- [ ] タスクの完了基準が明確になっている

### 複雑度評価完了時

- [ ] タスクの規模が評価されている
- [ ] タスクの複雑度が評価されている
- [ ] タスクの依存関係が特定されている
- [ ] 分解の必要性が判断されている
- [ ] 分解の方針が決定されている

### タスク分解完了時

- [ ] タスクが機能別に分解されている
- [ ] 各小タスクの目的が明確になっている
- [ ] 各小タスクの入力と出力が定義されている
- [ ] 小タスク間の依存関係が整理されている
- [ ] 小タスクの実行順序が決定されている

### 粒度調整完了時

- [ ] 各タスクの粒度が確認されている
- [ ] 大きすぎるタスクが分解されている
- [ ] 小さすぎるタスクが統合されている
- [ ] タスクの完了基準が明確になっている
- [ ] タスクの優先順位が付けられている

### 推奨提示完了時

- [ ] 最終タスクリストが提示されている
- [ ] タスクの実行順序が明示されている
- [ ] タスク間の依存関係が図示されている
- [ ] 実装の優先順位が提案されている
- [ ] スキル・コマンドへのマッピングが提供されている
- [ ] 次のステップが案内されている
- [ ] ユーザーの承認を得ている

### 最終確認

- [ ] 分解されたタスクリストが作成されている
- [ ] タスク実行順序が作成されている
- [ ] スキル・コマンドへのマッピングが作成されている
- [ ] すべてのアウトプットが明確で理解しやすい
- [ ] ユーザーが次のステップに進める状態になっている