gh-windschord-claude-skils-task-executor/skills/task-executor/SKILL.md

---
name: task-executor
description: docs/tasks.mdに記載されたタスクを読み取り、サブエージェントを使用して実装を自動実行します。並列実装可能なタスクは並列で処理し、タスクごとにコミットを作成します。タスク完了後はtasks.mdを更新して完了をマークします。
---

# Task Executor スキル

docs/tasks.mdに記載されたタスクを自動的に実行するスキルです。サブエージェントを活用して効率的に実装を進め、適切なコミット管理を行います。

## 概要

このスキルは以下の機能を提供します：
- docs/tasks.mdからタスクを読み取り、実行順序を決定
- サブエージェントを使用した自動実装
- 並列実行可能なタスクの並列処理
- タスクごとの自動コミット
- 重要な変更前の安全なコミット作成
- タスク完了時のtasks.md自動更新

## このスキルを使用する場面

以下の状況でこのスキルを有効にしてください：

### タスク実行時
- docs/tasks.mdに記載されたタスクを実行する場合
- 次のタスクを自動的に実行してほしい場合
- 複数のタスクを効率的に処理したい場合
- タスクの実装を自動化したい場合

### プロジェクト管理時
- タスクの進捗を自動的に追跡したい場合
- タスク完了後にtasks.mdを更新したい場合
- 実装とドキュメントの同期を保ちたい場合

## 基本的な使い方

### タスクの実行

「次のタスクを実行してください」「tasks.mdのタスクを進めてください」などと依頼されたら：

1. **tasks.mdの読み取り**
   - docs/tasks.mdの内容を確認
   - TODO状態のタスクを特定
   - 依存関係を確認

2. **実行計画の作成**
   - 実行可能なタスクを特定
   - 並列実行可能なタスクをグループ化
   - 実行順序を決定

3. **タスクの実行**
   - サブエージェントを使用して実装
   - 並列実行可能な場合は複数のサブエージェントを同時起動
   - タスクごとにコミットを作成

4. **tasks.mdの更新**
   - 完了したタスクを1行に要約
   - ステータスをDONEに変更
   - 変更をコミット

## タスク実行の原則

### 1. サブエージェントの活用

すべての実装タスクはサブエージェント（Task tool）を使用して実行します：

**使用方法**：
```
サブエージェントに以下のタスクを実行させます：
- タスク内容：[tasks.mdから抽出したタスク説明]
- 受入基準：[tasks.mdから抽出した受入基準]
- 技術的文脈：[tasks.mdから抽出した技術情報]
```

**サブエージェントへの指示**：
- タスクの完全な説明を提供
- 受入基準を明確に伝える
- 必要な技術的文脈を共有
- 実装のみを依頼（コミットは含めない）

### 2. 並列実行

依存関係のないタスクは並列で実行します：

**並列実行の条件**：
- 依存関係フィールドが空、または「なし」
- 前提となるタスクがすべて完了済み
- 異なるファイル・コンポーネントを対象とする

**並列実行の方法**：
```
複数のサブエージェントを同時に起動します：
- サブエージェント1: タスク1.1を実行
- サブエージェント2: タスク1.2を実行
- サブエージェント3: タスク1.3を実行
```

### 3. コミット管理

#### 基本ルール

**タスクごとのコミット**：
- 各タスク完了後、必ずコミットを作成
- コミットメッセージにはタスクの内容を記載
- 補足情報があれば追加

**コミットメッセージの形式**：
```
[タスクID] タスクの要約

tasks.mdに記載されたタスクの詳細説明。
実装した内容の補足情報。

関連: docs/tasks.md [タスクID]
```

**例**：
```
[Task 1.1] ユーザー認証APIエンドポイントの実装

POST /api/auth/login と POST /api/auth/logout エンドポイントを実装。
JWTトークンを使用した認証方式を採用し、bcryptでパスワードをハッシュ化。

関連: docs/tasks.md Task 1.1
```

#### 重要な変更前のコミット

以下の場合は、変更前に安全なコミットを作成します：

**重要な変更の例**：
- アーキテクチャの大幅な変更
- 複数のファイルにまたがる大規模なリファクタリング
- データベーススキーマの変更
- 既存のAPIインターフェースの変更
- 依存ライブラリのメジャーバージョンアップ

**手順**：
1. 現在の安定した状態をコミット
2. コミットメッセージに「変更前の安全なポイント」と記載
3. 変更を実施
4. 変更完了後にタスクのコミットを作成

**例**：
```
# 変更前のコミット
[Task 2.3] 認証システムリファクタリング前の安全なポイント

大規模なリファクタリングを開始する前の安定した状態を保存。

# 変更後のコミット
[Task 2.3] 認証システムのリファクタリング

認証ロジックをミドルウェアに分離し、コードの再利用性を向上。
既存のテストはすべて通過することを確認。

関連: docs/tasks.md Task 2.3
```

### 4. tasks.mdの更新

タスク完了後、以下の手順でtasks.mdを更新します：

#### 更新内容

1. **タスクの要約**
   - タスクの説明を1行に要約
   - 実装した内容の要点を含める
   - 簡潔かつ明確に記述

2. **ステータスの変更**
   - `TODO` → `DONE`
   - 完了日時は不要（gitのコミット履歴で確認可能）

3. **フォーマット**
```markdown
#### タスク1.1: [タイトル]
**説明**: [元の説明]
**受入基準**: [元の受入基準]
**ステータス**: `DONE`
**完了サマリー**: [1行の要約]
```

#### 更新のコミット

tasks.mdの更新は独立したコミットとして作成します：

```
Update tasks.md: Mark Task 1.1 as completed

タスク1.1（ユーザー認証APIエンドポイントの実装）を完了としてマーク。
```

### 5. 絵文字の使用禁止

すべてのメッセージ、コミットメッセージ、ドキュメントで絵文字を使用しません：

**禁止事項**：
- コミットメッセージに絵文字を含めない
- ユーザーへのメッセージに絵文字を使わない
- tasks.mdの更新に絵文字を含めない
- ログやエラーメッセージに絵文字を使わない

**良い例**：
```
[Task 1.1] ユーザー認証APIエンドポイントの実装

関連: docs/tasks.md Task 1.1
```

**悪い例**：
```
✅ [Task 1.1] ユーザー認証APIエンドポイントの実装 🚀

関連: docs/tasks.md Task 1.1 📝
```

## ワークフロー

### 基本的な実行フロー

```
1. tasks.mdを読み取る
   ↓
2. 実行可能なタスクを特定
   ↓
3. 並列実行可能か判断
   ↓
4. サブエージェントを起動（並列または順次）
   ↓
5. 各タスクの実装を監視
   ↓
6. タスクごとにコミット作成
   ↓
7. tasks.mdを更新
   ↓
8. tasks.md更新をコミット
   ↓
9. 次のタスクへ（または完了）
```

### 詳細な実行手順

#### ステップ1: タスクの読み取りと分析

```markdown
1. docs/tasks.mdを読み取る
2. 各タスクの情報を抽出：
   - タスクID
   - タスクタイトル
   - 説明
   - 受入基準
   - 依存関係
   - ステータス
   - 推定工数
3. TODO状態のタスクをフィルタリング
4. 依存関係グラフを作成
```

#### ステップ2: 実行計画の作成

```markdown
1. 依存関係のないタスクを特定
2. 並列実行グループを作成
3. 実行順序を決定
4. ユーザーに実行計画を提示
```

**実行計画の例**：
```
以下のタスクを実行します：

並列実行グループ1（依存関係なし）：
- Task 1.1: ユーザー認証APIエンドポイントの実装
- Task 1.2: データモデルの定義
- Task 1.3: 設定ファイルの作成

順次実行（Task 1.1, 1.2に依存）：
- Task 2.1: 認証ミドルウェアの実装

実行を開始してよろしいですか？
```

#### ステップ3: タスクの実行

```markdown
1. サブエージェントを起動
2. タスクの完全な情報を提供
3. 実装の完了を待つ
4. 受入基準の確認
5. コミットを作成
```

#### ステップ4: tasks.mdの更新

```markdown
1. 完了したタスクを1行に要約
2. ステータスをDONEに変更
3. 完了サマリーを追加
4. 変更をコミット
```

## エラーハンドリング

### タスク実行中のエラー

**エラーが発生した場合**：
1. エラー内容をユーザーに報告
2. 部分的に完了した作業をコミット
3. タスクのステータスをBLOCKEDに変更
4. エラー原因と対処方法を記録
5. ユーザーに次の行動を確認

**例**：
```
Task 1.1の実行中にエラーが発生しました：

エラー内容：
npm install時に依存関係の競合が発生

実施した内容：
- 基本的なファイル構造を作成（コミット済み）
- パッケージのインストールは未完了

次の行動：
1. 依存関係の競合を解決してから再実行
2. このタスクをスキップして次のタスクへ進む

どちらにしますか？
```

### 依存関係の問題

**前提タスクが未完了の場合**：
1. 依存関係を確認
2. 前提タスクの実行を提案
3. ユーザーに確認

## 制約事項

### 実行の制限

以下の場合は自動実行を行いません：

1. **タスクの曖昧性**
   - 受入基準が明確でない
   - 実装方法が複数考えられる
   - 技術的文脈が不足している

2. **リスクの高い操作**
   - 本番環境への直接的な変更
   - データベースの削除操作
   - 認証情報の変更

3. **ユーザーの判断が必要な場合**
   - 技術選択が必要
   - アーキテクチャの決定が必要
   - トレードオフの判断が必要

これらの場合は、ユーザーに確認を求めます。

## ベストプラクティス

### 1. タスクの粒度

tasks.mdのタスクは以下の粒度が推奨されます：
- サブエージェント1回の実行で完了できる範囲
- 20-90分程度の作業量
- 明確な受入基準を持つ

### 2. 依存関係の明示

tasks.mdでは依存関係を明確に記載してください：
```markdown
**依存関係**: Task 1.1, Task 1.2
```

### 3. 受入基準の具体化

受入基準は検証可能な形で記載してください：
```markdown
**受入基準**:
- [ ] `src/api/auth.ts`が存在する
- [ ] すべてのテストが通過する（npm test）
- [ ] ESLintエラーがゼロ
```

### 4. 技術的文脈の提供

サブエージェントが実装しやすいよう、技術的文脈を提供してください：
```markdown
**技術的文脈**:
- フレームワーク: Next.js 14
- 認証: JWT + bcrypt
- 参照実装: src/api/users.ts
```

## トラブルシューティング

### よくある問題と解決方法

**問題1: タスクが並列実行されない**
- 原因: 依存関係が設定されている
- 解決: tasks.mdの依存関係フィールドを確認

**問題2: コミットが作成されない**
- 原因: git作業ディレクトリが汚れている
- 解決: 未コミットの変更を確認し、適切にコミット

**問題3: サブエージェントがタスクを完了できない**
- 原因: タスクの説明が不十分
- 解決: tasks.mdのタスク説明を詳細化

## 今後の拡張

このスキルは将来的に以下の機能を追加予定です：

- タスクの優先順位付け
- 実行時間の推定と実績の記録
- タスク実行のロールバック機能
- 複数プロジェクトの並行管理
- GitHub Issuesとの連携