AgentSkillsCN

planning-tasks

根据已批准的设计文档（DESIGN.md）生成符合 TDD 的 TODO.md。在 analyzing-requirements 技能设计完成并批准后使用。生成 developping 技能可实现形式的任务列表。

SKILL.md
--- frontmatter
name: planning-tasks
description: 承認済みの設計書（DESIGN.md）からTDD準拠のTODO.mdを作成します。analyzing-requirementsスキルで設計が完了・承認された後に使用します。developingスキルで実装できる形式のタスクリストを生成します。

タスク計画

概要

承認済みの設計書（DESIGN.md）を読み込み、TDD（テスト駆動開発）に準拠したTODO.mdを作成する。生成されるTODO.mdはdevelopingスキルで直接使用できる形式となる。

前提条件: analyzing-requirementsスキルで作成されたDESIGN.mdが存在し、ユーザーに承認されていること。

コアワークフロー

ステップ1: 設計書の確認

DESIGN.mdを読み込み、全体を確認する：

javascript
Read(file_path="docs/DESIGN.md")

設計書の全セクションを把握し、タスク分解に必要な情報を抽出する。

ステップ2: タスク分解

設計書から実装タスクを抽出し、TDDサイクルに従って分解する：

分解の原則

  1. •機能単位で分割: 1つの機能 = 1つのTDDサイクル
  2. •依存関係を考慮: 基盤 → コア機能 → 拡張機能の順
  3. •テストファースト: 各機能でRED→GREEN→REFACTORを明示

タスクの粒度

  • •1タスク = 1-4時間で完了可能
  • •テスト1つ + 実装1つ = 1セット
  • •リファクタリングは独立したタスク

ステップ3: TODO.md生成

以下の形式でTODO.mdを生成する：

markdown
# TODO: [プロジェクト名]

作成日: [日付]
生成元: planning-tasks
設計書: docs/DESIGN.md

## 概要

[設計書から抽出した目的と範囲]

## 実装タスク

### フェーズ1: 基盤構築

- [ ] プロジェクト構造のセットアップ
- [ ] 依存パッケージのインストール
- [ ] 開発環境の設定

### フェーズ2: [機能名A] の実装

- [ ] [RED] [機能A]の動作テストを作成
- [ ] [GREEN] テストを通過させる最小限の実装
- [ ] [REFACTOR] コード品質の改善
- [ ] [CHECK] lint/format/build の実行と確認

### フェーズ3: [機能名B] の実装

- [ ] [RED] [機能B]の動作テストを作成
- [ ] [GREEN] テストを通過させる最小限の実装
- [ ] [REFACTOR] コード品質の改善
- [ ] [CHECK] lint/format/build の実行と確認

### フェーズN: 品質保証

- [ ] [STRUCTURAL] コード整理（動作変更なし）
- [ ] 全テスト実行と確認
- [ ] lint/format/buildの確認

## 実装ノート

### MUSTルール遵守事項
- TDD: RED → GREEN → REFACTOR → CHECK サイクルを厳守
- CHECK: 各フェーズ完了時に lint/format/build を実行
- Tidy First: 構造変更と動作変更を分離
- コミット: [BEHAVIORAL] または [STRUCTURAL] プレフィックス必須

### 参照ドキュメント
- 設計書: docs/DESIGN.md
- MUSTルール: 参照 shared/references/must-rules.md

ステップ4: ファイル出力

TODO.mdをdocsディレクトリに出力する：

javascript
Write(
    file_path="docs/TODO.md",
    content=todoContent
)

ステップ5: セルフレビュー

生成したTODO.mdをセルフレビューし、問題がなくなるまで修正を繰り返す。

レビュー観点

  1. •完全性: DESIGN.mdのすべての要件がタスク化されているか
  2. •TDD準拠: 各タスクにRED/GREEN/REFACTOR/CHECKフェーズが明示されているか
  3. •依存関係: タスクの順序が依存関係を正しく反映しているか
  4. •粒度: 各タスクが適切なサイズ（1-4時間）か
  5. •明確性: タスク内容が具体的で実装者が迷わないか

レビュープロセス

code
1. TODO.mdを読み返す
2. 以下のチェックリストで問題を洗い出す
3. 問題があれば修正してファイルを更新
4. 問題がなくなるまで1-3を繰り返す（最大3回）

セルフレビューチェックリスト

設計との整合性

  • • DESIGN.mdの全機能がタスク化されている
  • • 非機能要件（テスト戦略、エラー戦略）が反映されている
  • • 依存関係の順序が正しい

TDD準拠

  • • すべてのタスクにRED/GREEN/REFACTOR/CHECKが明示されている
  • • テストファーストの順序になっている
  • • リファクタリングタスクが適切に配置されている
  • • 各フェーズ末尾に品質チェックステップがある

実装可能性

  • • 各タスクが1-4時間で完了可能な粒度
  • • タスク内容が具体的で曖昧さがない
  • • developingスキルで実装開始できる情報量がある

問題発見時の対応

問題を発見した場合：

  1. •問題箇所を特定
  2. •修正内容を決定
  3. •TODO.mdを更新
  4. •再度レビューを実行

3回のレビューで解決しない問題がある場合は、AskUserQuestionツールでユーザーに確認する。

ステップ6: 完了確認

セルフレビュー完了後、ユーザーに確認する：

javascript
AskUserQuestion({
  questions: [
    {
      question: "TODO.mdを確認しました。このタスクリストで実装を開始しますか？",
      header: "実装開始",
      options: [
        { label: "開始する", description: "developingスキルで実装を開始" },
        { label: "却下", description: "コマンドを終了" }
      ],
      multiSelect: false
    }
  ]
})

ユーザーが修正内容を入力した場合（Other選択）：

  1. •入力された修正内容を反映してTODO.mdを更新
  2. •再度ユーザー確認を取得（このセクションに戻る）
  3. •承認されるまで繰り返す

タスク分解のパターン

パターン1: CRUD機能

markdown
### [エンティティ名] CRUD実装

- [ ] [RED] Create機能のテスト作成
- [ ] [GREEN] Create機能の実装
- [ ] [RED] Read機能のテスト作成
- [ ] [GREEN] Read機能の実装
- [ ] [RED] Update機能のテスト作成
- [ ] [GREEN] Update機能の実装
- [ ] [RED] Delete機能のテスト作成
- [ ] [GREEN] Delete機能の実装
- [ ] [REFACTOR] CRUD処理の共通化
- [ ] [CHECK] lint/format/build の実行と確認

パターン2: API実装

markdown
### [エンドポイント名] API実装

- [ ] [RED] 正常系レスポンスのテスト作成
- [ ] [GREEN] 正常系の実装
- [ ] [RED] バリデーションエラーのテスト作成
- [ ] [GREEN] バリデーションの実装
- [ ] [RED] エラーハンドリングのテスト作成
- [ ] [GREEN] エラーハンドリングの実装
- [ ] [REFACTOR] レスポンス形式の統一
- [ ] [CHECK] lint/format/build の実行と確認

パターン3: UIコンポーネント

markdown
### [コンポーネント名] 実装

- [ ] [RED] レンダリングテスト作成
- [ ] [GREEN] 基本UIの実装
- [ ] [RED] インタラクションテスト作成
- [ ] [GREEN] イベントハンドラの実装
- [ ] [RED] エッジケーステスト作成
- [ ] [GREEN] エッジケース対応
- [ ] [REFACTOR] スタイルとロジックの分離
- [ ] [CHECK] lint/format/build の実行と確認

品質チェックリスト

TODO.md完了前に確認：

  • • すべての設計項目がタスクに反映されている
  • • 各タスクにTDDフェーズ（RED/GREEN/REFACTOR/CHECK）が明示されている
  • • 各フェーズの最後に品質チェック（lint/format/build）ステップが含まれている
  • • タスクの依存関係が順序に反映されている
  • • 各タスクの粒度が適切（1-4時間）
  • • MUSTルール遵守事項が記載されている
  • • セルフレビューが完了し、問題が解消されている

リソース

../shared/references/must-rules.md

すべてのスキルで共有される共通MUSTルール：

  • •TDD方法論の詳細
  • •Tidy First原則
  • •コミット規律

タスク分解時はこのファイルを参照してMUSTルール準拠を確認すること。