Agent skill
task-planning
設計書から実装タスクへの分解と管理書を作成・編集する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理(sdd-documentationを使用すること)。
Install this agent skill to your Project
npx add-skill https://github.com/windschord/claude_skils/tree/main/task-planning
Metadata
Additional technical details for this skill
- version
- 1.0.0
SKILL.md
タスク計画スキル
設計書を基に、AIエージェント(Claude Code等)が実行可能な具体的なタスクに分解します。
概要
このスキルは、以下の成果物を作成・管理します:
- docs/sdd/tasks/index.md: タスク一覧(目次・進捗サマリ)
- docs/sdd/tasks/[phase]/TASK-XXX.md: 個別タスク詳細
ドキュメント構成
docs/sdd/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/sdd/tasks/にタスクを追加・修正する場合
- タスクのステータスを更新する場合
- 依存関係や見積もりを修正する場合
前提条件
前段スキルとの連携
docs/sdd/requirements/、docs/sdd/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(テスト駆動開発)
各タスクにTDD手順(テスト作成 → 失敗確認 → テストコミット → 実装 → 通過確認 → 実装コミット)を記載する。具体的なテストファイルパスとテストケースを明記すること。
実行効率に関する注意
- テンプレートは使用直前に読み込む: index用テンプレートとタスク詳細テンプレートを一括読み込みしない
- requirements/とdesign/は概要レベルで参照: index.mdを先に読み、必要な個別ファイルのみ詳細を確認する
- 作業完了後は速やかに結果を報告: 長時間無応答にならないよう、作成したタスク一覧をユーザーに提示する
- 進捗をステップごとに出力する: 各処理ステップの開始時に進捗メッセージを出力する
進捗出力の例
[task-planning] ステップ 1/5: 要件定義・設計を確認中...
[task-planning] ステップ 2/5: フェーズ分けを策定中...
[task-planning] ステップ 3/5: タスク分解中...
[task-planning] ステップ 4/5: 依存関係を整理中...
[task-planning] ステップ 5/5: index.mdを作成中...
[task-planning] 完了: Nタスク作成
ワークフロー
新規作成フロー
- ドキュメント確認: docs/sdd/requirements/、docs/sdd/design/を読み込む
- 情報分類: 明示された情報と不明な情報を分類
- 不明点確認: 必要な情報をユーザーに確認
- ディレクトリ作成:
docs/sdd/tasks/以下にフェーズ別ディレクトリを作成 - index.md作成: 目次と進捗サマリを記述
- フェーズ分け: 作業を論理的なフェーズに分割
- タスク分解: 各フェーズのタスクを
[phase]/TASK-XXX.mdとして作成 - index.md更新: 作成したタスクへのリンクを追加
- 依存関係整理: タスク間の依存関係を明確化
- 逆順レビュー: タスク → 設計 → 要件の整合性確認
- ユーザー確認: 承認を得て完了
タスク追加フロー
- 新規ファイル作成:
[phase]/TASK-XXX.mdを作成 - タスクテンプレートに従う: 情報の明確性・受入基準・TDD手順を記述
- index.md更新: タスク一覧テーブルにリンクを追加
- 依存関係更新: 関連タスクの依存関係を更新
逆順レビュープロセス
タスク → 設計 → 要件の整合性を確認する。詳細チェック項目は sdd-documentation/references/checklist_ja.md を参照。不整合発見時はリストアップしてユーザーに確認してから修正する。
タスク同期(TodoWrite連携)
タスク計画完了時にTodoWriteへ同期する。ステータスマッピングと運用ルールは sdd-documentation/references/task_sync_guide_ja.md を参照。
エージェントチーム向けタスク設計(必須考慮事項)
**タスク計画時は常にエージェントチームでの並列実行を前提として設計する。**並列実行可能なタスクが3つ以上になるようタスクを分割・構成することを目指す。
注意: 並列化のためだけにタスクを過剰に分割しないこと。各タスクの粒度(20-40分目安)を維持することを優先し、自然に3つ以上に分かれない場合は順次実行で問題ない。
設計原則
- ファイル独立性(最重要): 各タスクが異なるファイルセットを対象とするよう分割する。同一ファイルを複数タスクが編集する設計は禁止。
- 並列実行グループの明示: index.mdに並列実行可能なタスクグループを明記する(必須)
- 依存関係の最小化: 可能な限り並列実行可能なタスク数を最大化する
- コンテキストの完全性: 各タスクがスポーンプロンプトだけで実行できるよう、以下を必ず記載:
- 対象ファイルの絶対パス
- 参照すべき設計ドキュメントのパス
- 使用する技術スタック・ライブラリ
- テスト要件
index.mdでの並列実行グループ記載例
## 並列実行グループ
### グループA(並列実行可能)
| タスク | 対象ファイル | 依存 |
|--------|-------------|------|
| TASK-001 | src/auth/** | なし |
| TASK-002 | src/api/** | なし |
| TASK-003 | src/models/** | なし |
### グループB(グループA完了後に並列実行可能)
| タスク | 対象ファイル | 依存 |
|--------|-------------|------|
| TASK-004 | src/services/auth-service.ts | TASK-001 |
| TASK-005 | src/services/api-service.ts | TASK-002 |
詳細: sdd-documentation/references/agent_teams_guide_ja.md
検証チェックリスト
- タスクが適切な粒度に分解されている(20-40分程度)
- 各タスクに受入基準がある
- 依存関係が明確である
- 推定工数が記載されている
- ステータスが有効な値である
- 各タスクの「情報の明確性」セクションが記載されている
- 推測に基づく実装指示が含まれていない
- TDD手順が含まれている
- すべてのタスクがdesign/のコンポーネント/APIに対応している
- すべての設計要素がrequirements/に対応している
- TodoWriteにタスク一覧が同期されている
- 並列実行グループが明示されている(チーム実行時)
ユーザーとの対話ガイドライン
確認が必要な場面
- タスクの粒度
- 優先順位
- 見積もり時間
- 実装の順序
- テストカバレッジの目標
- 使用するライブラリのバージョン
サブエージェント向け情報の完全性
各タスクに以下が含まれているか確認:
技術仕様:
- 対象ファイルの絶対パス
- 使用するライブラリ/フレームワークのバージョン
- 関数/クラスのシグネチャ
- 型定義(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がファイルを参照する際に使用
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
orchestrating-agents
Orchestrates multi-step tasks autonomously using a 3-tier agent hierarchy (Director/Manager/Worker). Use when user says "run this end-to-end", "handle everything", "execute all tasks", or needs parallel task execution with queuing, course correction, and session resume. Provides FIFO task queue, escalation policy, git worktree isolation, and context persistence across agent sessions.
sdd-documentation
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業(requirements-defining、software-designing、task-planningを直接使用すること)。
sdd-troubleshooting
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正(typo、設定値変更、フォーマット修正など)。
self-review
ローカルの変更差分(git diff)を3つのサブエージェントで並列レビューし、結果を統合して修正を適用する。PR作成前やタスク完了前のローカル品質チェックに使用する。ai-code-reviewと同一の6観点・重大度基準を適用する。
depth-interviewing-career
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ(depth-interviewing-productを使用すること)。
saas-spec-document
SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ(可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス)に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。
Didn't find tool you were looking for?