decomposition

name	decomposition
description	複雑なタスクを詳細で実行可能な小さなタスク一覧に分解するスキル。「タスクを分解して」「ToDoに落とし込んで」「実装計画を立てて」「タスクを細かくして」「何から始めればいい」「作業リストを作って」「実装ステップを教えて」「チケットに分けて」などで発動する。各タスクは独立して実行できるよう、必要な情報を網羅した豊富な説明付きで生成する。
metadata	{"version":"1.0.0","tier":"stable","category":"planning","tags":["decomposition","planning","todos","task-breakdown","actionable"]}

タスク分解スキル

概要

複雑なタスクを、独立して実行できる具体的なToDoの一覧に変換する。 各ToDoは「What / Where / How / Why / 完了条件」を含む豊富な説明付きで生成し、担当者が文脈なしで作業を開始できる状態にする。

適用条件

以下にいずれも該当する場合に実行する。1つでも外れる場合は中断してユーザーに確認する。

• タスクが2ステップ以上の作業を含む
• 実装方針が未確定（既に設計ドキュメントが承認済みの場合はそちらを使う）
• タスクをToDoリスト形式で管理することがユーザーの意図である

---

プロセス

以下のステップを順番に実行する。

Step 1: コードベースの探索

分解を始める前に、必ずプロジェクトの現状を把握する。

1. CLAUDE.md / AGENTS.md / README.md を読んでプロジェクトの概要と規約を把握する
2. 影響を受けるファイル・ディレクトリ・設定を特定する
3. 既存のパターン（命名規則・テスト方法・ディレクトリ構造）を確認する
4. docs/plans/ などの設計ドキュメントが存在する場合は参照する

コードベースの探索を完了するまで、ToDoの作成を開始してはならない。 「シンプルに見えるタスク」も含め、必ず探索してから分解する。

Step 2: 主要コンポーネントの特定

タスクを内部的に分析し、以下をマッピングする（この段階では出力しない）:

• 作業フェーズと実施順序
• 各フェーズ間の依存関係
• 並列実行できる作業 vs 順次実行が必要な作業
• リスクが高い・調査が必要な箇所

Step 3: 不明点の整理（任意）

真の曖昧さがある場合のみ実施する。以下のいずれかに該当する場合にユーザーへ質問する:

• スコープの境界が不明確（含む / 除外する）
• 実装アプローチが複数あり選択が必要
• タスクの順序や並列化の方針が不明
• 完了基準が曖昧

質問は一度に2〜4つに絞り、各質問に選択肢と簡潔なトレードオフを提示する。 曖昧さがない場合はこのステップをスキップして Step 4 へ進む。

Step 4: 詳細なToDoの作成

各ToDoは以下の品質基準を満たすこと:

基準	定義
具体的	明確なアクション動詞から始まる。実装場所と期待される結果が明示されている
達成可能	外部依存なしに単独で完結できる
小さい	単一責務。20〜60分で完了できる粒度

ToDoの記述テンプレート

[タスクタイトル（動詞+目的語）]

What: 実行する具体的な操作
Where: ファイルパス・関数名・クラス名
How: 実装アプローチ（既存パターンへの参照を含む）
Why: このToDoの目的とシステム全体への位置づけ
完了条件: 具体的な検証コマンドまたは手動確認手順

アンチパターン（避けるべき記述）

• ❌ 「認証機能を実装する」（範囲が広すぎる）
• ❌ 「必要に応じてエラーハンドリングを追加」（曖昧）
• ❌ 「テストを書く」（場所・対象が不明）
• ✅ 「src/auth/login.ts の validateCredentials 関数にJWTトークン検証を追加する」

Step 5: ToDoの出力

Markdown形式でToDoリストを出力する。

• タイトルは命令形・動詞始まり（「〜を追加する」「〜を修正する」「〜を作成する」）
• 依存関係がある場合は順序を明示する
• 並列実行可能なタスクには [並列可] と付記する

Step 6: 計画ドキュメントの更新

docs/plans/YYYY-MM-DD-<トピック>-plan.md に以下を書き出してコミットする:

# [タスク名] 実装計画

## 元のタスク
（ユーザーからの依頼をそのまま記載）

## 分解したToDoリスト
（Step 5の出力）

## 依存関係
（ToDoの前後関係を箇条書きまたは図で示す）

## オープンクエスチョン
（未解決の判断が必要な事項）

---

実行例

依頼: 「ユーザー登録APIを実装して」

分解後のToDoリスト（例）:

1. src/routes/auth.ts に POST /api/users/register エンドポイントを追加する

   • What: ルート定義とリクエストハンドラを追加
   • Where: src/routes/auth.ts（既存の loginRouter パターンに倣う）
   • How: express.Router() を使い、バリデーションミドルウェア適用後にサービス層へ委譲
   • Why: APIエントリポイントの定義
   • 完了条件: curl -X POST /api/users/register でルートが到達できる

2. src/services/userService.ts にユーザー作成ロジックを実装する（Step 1 の完了後）

   • What: メールアドレス重複チェック、パスワードハッシュ化、DBへの保存
   • Where: src/services/userService.ts（createUser(dto) として追加）
   • How: 既存の updateUser の実装パターンを踏襲し、bcrypt.hash() を使用
   • Why: ビジネスロジックの実装
   • 完了条件: userService.createUser({ email, password }) がユーザーレコードを返す

---

注意事項

• 過度な分解を避ける: 自明な1行の変更は独立したToDoにしない
• パターンを参照する: 既存コードのパターンを How に具体的に記載する
• 独立性を担保する: 各ToDoはそれ単体で意味が通じ、検証できること
• コードベース探索を怠らない: 先に探索することで、的外れな分解を防ぐ