Back to list
windschord

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/が存在する場合:

  1. 両方のドキュメントを読み込む
  2. タスクが設計・要件と整合しているか確認
  3. 逆順レビュー(タスク → 設計 → 要件)を実施

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. 実装コミット: すべてのテストが通過したらコミット

ワークフロー

新規作成フロー

  1. ドキュメント確認: docs/requirements/、docs/design/を読み込む
  2. 情報分類: 明示された情報と不明な情報を分類
  3. 不明点確認: 必要な情報をユーザーに確認
  4. ディレクトリ作成: docs/tasks/ 以下にフェーズ別ディレクトリを作成
  5. index.md作成: 目次と進捗サマリを記述
  6. フェーズ分け: 作業を論理的なフェーズに分割
  7. タスク分解: 各フェーズのタスクを [phase]/TASK-XXX.md として作成
  8. index.md更新: 作成したタスクへのリンクを追加
  9. 依存関係整理: タスク間の依存関係を明確化
  10. 逆順レビュー: タスク → 設計 → 要件の整合性確認
  11. ユーザー確認: 承認を得て完了

タスク追加フロー

  1. 新規ファイル作成: [phase]/TASK-XXX.md を作成
  2. タスクテンプレートに従う: 情報の明確性・受入基準・TDD手順を記述
  3. index.md更新: タスク一覧テーブルにリンクを追加
  4. 依存関係更新: 関連タスクの依存関係を更新

逆順レビュープロセス

レビューの流れ

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の場合)

実装詳細:

  • 入力の形式と型
  • 出力の形式と型
  • エラーケースとその処理方法

テスト仕様:

  • テストファイルのパス
  • テストケースの具体的な内容
  • 期待される入出力の具体例

フェーズ分けの考え方

  1. 基盤構築: 環境設定、基本構造
  2. コア機能: 主要な機能の実装
  3. 拡張機能: 追加機能、改善
  4. 統合・テスト: 結合、品質保証
  5. リリース準備: デプロイ、文書化

リソース

テンプレート

  • 目次テンプレート: assets/templates/tasks_index_template_ja.md
  • タスク詳細テンプレート: assets/templates/task_detail_template_ja.md

リファレンス

  • タスクガイドライン: references/task_guidelines_ja.md

命名規則

ファイル種別命名規則
フェーズディレクトリphase-Nphase-1, phase-2
タスクファイルTASK-XXX.mdTASK-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