← Back to list

task-planning
by windschord
⭐ 1🍴 1📅 Jan 25, 2026
SKILL.md
name: task-planning description: 実装タスク管理書を作成・編集します。設計書からタスク分解、AIエージェント向けの具体的な実装指示、TDD手順の定義が必要な場合に使用してください。requirements/、design/との整合性を逆順レビューで確認します。 version: "1.0.0"
タスク計画スキル
設計書を基に、AIエージェント(Claude Code等)が実行可能な具体的なタスクに分解します。
概要
このスキルは、以下の成果物を作成・管理します:
- docs/tasks/index.md: タスク一覧(目次・進捗サマリ)
- docs/tasks/[phase]/TASK-XXX.md: 個別タスク詳細
ドキュメント構成
docs/tasks/
├── index.md # 目次・進捗サマリ
├── phase-1/
│ ├── TASK-001.md # タスク詳細
│ └── TASK-002.md
├── phase-2/
│ ├── TASK-003.md
│ └── TASK-004.md
└── phase-3/
└── TASK-005.md
このスキルを使用する場面
新規作成時
- 設計書からタスクを分解したい場合
- AIエージェント向けの実装指示を作成したい場合
- TDD(テスト駆動開発)の手順を定義したい場合
- 実装の優先順位・依存関係を整理したい場合
既存ドキュメントの修正時
- docs/tasks/にタスクを追加・修正する場合
- タスクのステータスを更新する場合
- 依存関係や見積もりを修正する場合
前提条件
前段スキルとの連携
docs/requirements/、docs/design/が存在する場合:
- 両方のドキュメントを読み込む
- タスクが設計・要件と整合しているか確認
- 逆順レビュー(タスク → 設計 → 要件)を実施
AIエージェント向けタスク設計
タスク粒度の目安
| 分類 | 作業時間 | 内容例 |
|---|---|---|
| シンプル | 10-20分 | 単一ファイル作成、基本関数実装、設定追加 |
| 標準 | 20-40分 | 複数ファイル、APIエンドポイント、基本テスト |
| 複雑 | 40-90分 | 複数コンポーネント統合、包括的テスト |
| 要分解 | 90分以上 | さらに小さいタスクに分解 |
タスク定義の必須要素
#### タスク1.1: [タスクタイトル]
**説明**:
- 対象ファイルパス: `src/components/Button.tsx`
- 実装する機能の詳細
- 使用する技術・ライブラリ
**技術的文脈**:
- フレームワーク: Next.js 14 (App Router)
- スタイリング: Tailwind CSS
- 参照すべき既存コード: `src/components/Card.tsx`
**情報の明確性**:
| 分類 | 内容 |
|------|------|
| 明示された情報 | [ユーザーから明確に指定された仕様] |
| 不明/要確認の情報 | [推測が必要な項目] |
**実装手順(TDD)**:
1. テスト作成: `src/components/Button.test.tsx`
2. テスト実行: 失敗を確認
3. テストコミット
4. 実装: テストを通過させる
5. 実装コミット
**受入基準**:
- [ ] `src/components/Button.tsx`が存在する
- [ ] TypeScriptの型定義が含まれている
- [ ] テストが3つ以上ある
- [ ] `npm test`で全テスト通過
- [ ] ESLintエラーがゼロ
**依存関係**: なし
**推定工数**: 30分(AIエージェント作業時間)
**ステータス**: `TODO`
TDD(テスト駆動開発)の原則
基本サイクル
1. テストを書く
↓
2. テスト実行(失敗確認)
↓
3. テストをコミット
↓
4. 最小限の実装
↓
5. テスト通過を確認
↓
6. 実装をコミット
↓
7. リファクタリング(必要に応じて)
TDD適用のタスク記述例
**実装手順(TDD)**:
1. テスト作成: `src/auth/authenticate.test.ts`にテストケースを作成
- 正常な認証のテスト
- 無効な認証情報のテスト
- 空の入力のテスト
2. テスト実行: すべてのテストが失敗することを確認
3. テストコミット: テストのみをコミット
4. 実装: `authenticate.ts`を実装してテストを通過させる
5. 実装コミット: すべてのテストが通過したらコミット
ワークフロー
新規作成フロー
- ドキュメント確認: docs/requirements/、docs/design/を読み込む
- 情報分類: 明示された情報と不明な情報を分類
- 不明点確認: 必要な情報をユーザーに確認
- ディレクトリ作成:
docs/tasks/以下にフェーズ別ディレクトリを作成 - index.md作成: 目次と進捗サマリを記述
- フェーズ分け: 作業を論理的なフェーズに分割
- タスク分解: 各フェーズのタスクを
[phase]/TASK-XXX.mdとして作成 - index.md更新: 作成したタスクへのリンクを追加
- 依存関係整理: タスク間の依存関係を明確化
- 逆順レビュー: タスク → 設計 → 要件の整合性確認
- ユーザー確認: 承認を得て完了
タスク追加フロー
- 新規ファイル作成:
[phase]/TASK-XXX.mdを作成 - タスクテンプレートに従う: 情報の明確性・受入基準・TDD手順を記述
- index.md更新: タスク一覧テーブルにリンクを追加
- 依存関係更新: 関連タスクの依存関係を更新
逆順レビュープロセス
レビューの流れ
docs/tasks/ → docs/design/ → docs/requirements/
(実装計画) (技術設計) (要件定義)
ステップ1: タスク → 設計の整合性チェック
| チェック項目 | 確認内容 |
|---|---|
| コンポーネント対応 | タスクが参照するコンポーネントはdesign/components/に定義されているか |
| API対応 | タスクで実装するAPIはdesign/api/と一致しているか |
| データモデル対応 | タスクで使用するデータ構造はdesign/database/と一致しているか |
| 技術スタック | タスクで使用する技術はdesign/decisions/と一致しているか |
ステップ2: 設計 → 要件の整合性チェック
| チェック項目 | 確認内容 |
|---|---|
| 機能カバレッジ | すべての要件(REQ-XXX)に対応する設計要素があるか |
| 非機能要件対応 | NFR-XXXの要件が設計に反映されているか |
| 過剰設計チェック | requirements/にない機能が設計に含まれていないか |
不整合発見時の報告
ドキュメントの整合性チェックで以下の不整合を発見しました:
【タスク → 設計の不整合】
1. tasks/phase-2/TASK-003.mdで「PaymentService」を実装するとありますが、
design/components/にPaymentServiceの定義がありません。
【設計 → 要件の不整合】
2. design/components/に「通知機能」がありますが、
requirements/stories/に対応する要件がありません。
【過不足】
3. REQ-005(レポート出力機能)に対応するタスクがありません。
これらについて確認させてください:
1. PaymentServiceの設計を追加しますか?
2. 通知機能は必要ですか?
3. REQ-005のタスクを追加しますか?
検証チェックリスト
- タスクが適切な粒度に分解されている(20-40分程度)
- 各タスクに受入基準がある
- 依存関係が明確である
- 推定工数が記載されている
- ステータスが有効な値である
- 各タスクの「情報の明確性」セクションが記載されている
- 推測に基づく実装指示が含まれていない
- TDD手順が含まれている
- すべてのタスクがdesign/のコンポーネント/APIに対応している
- すべての設計要素がrequirements/に対応している
ユーザーとの対話ガイドライン
確認が必要な場面
- タスクの粒度
- 優先順位
- 見積もり時間
- 実装の順序
- テストカバレッジの目標
- 使用するライブラリのバージョン
サブエージェント向け情報の完全性
各タスクに以下が含まれているか確認:
技術仕様:
- 対象ファイルの絶対パス
- 使用するライブラリ/フレームワークのバージョン
- 関数/クラスのシグネチャ
- 型定義(TypeScriptの場合)
実装詳細:
- 入力の形式と型
- 出力の形式と型
- エラーケースとその処理方法
テスト仕様:
- テストファイルのパス
- テストケースの具体的な内容
- 期待される入出力の具体例
フェーズ分けの考え方
- 基盤構築: 環境設定、基本構造
- コア機能: 主要な機能の実装
- 拡張機能: 追加機能、改善
- 統合・テスト: 結合、品質保証
- リリース準備: デプロイ、文書化
リソース
テンプレート
- 目次テンプレート:
assets/templates/tasks_index_template_ja.md - タスク詳細テンプレート:
assets/templates/task_detail_template_ja.md
リファレンス
- タスクガイドライン:
references/task_guidelines_ja.md
命名規則
| ファイル種別 | 命名規則 | 例 |
|---|---|---|
| フェーズディレクトリ | phase-N | phase-1, phase-2 |
| タスクファイル | TASK-XXX.md | TASK-001.md, TASK-002.md |
タスクIDの採番ルール
- プロジェクト全体で一意のIDを割り当て
- フェーズをまたいでも連番を維持
- 例: Phase 1で TASK-001〜003、Phase 2で TASK-004〜 と続ける
リンク形式
index.mdから個別ファイルへのリンクは、マークダウン形式と@形式の両方を記載:
| TASK-001 | タイトル | TODO | - | 30min | [詳細](phase-1/TASK-001.md) @phase-1/TASK-001.md |
- マークダウン形式:
[詳細](phase-1/TASK-001.md)- GitHub等での閲覧用 - @形式:
@phase-1/TASK-001.md- Claude Codeがファイルを参照する際に使用
Score
Total Score
55/100
Based on repository quality metrics
✓SKILL.md
SKILL.mdファイルが含まれている
+20
✓LICENSE
ライセンスが設定されている
+10
○説明文
100文字以上の説明がある
0/10
○人気
GitHub Stars 100以上
0/15
○最近の活動
3ヶ月以内に更新がある
0/10
○フォーク
10回以上フォークされている
0/5
✓Issue管理
オープンIssueが50未満
+5
○言語
プログラミング言語が設定されている
0/5
○タグ
1つ以上のタグが設定されている
0/5
Reviews
💬
Reviews coming soon