ynitto タスク分解スキル
概要
複雑なタスクを、独立して実行できる具体的なToDoの一覧に変換する。 各ToDoは「What / Where / How / Why / 完了条件」を含む豊富な説明付きで生成し、担当者が文脈なしで作業を開始できる状態にする。
適用条件
以下にいずれも該当する場合に実行する。1つでも外れる場合は中断してユーザーに確認する。
- タスクが2ステップ以上の作業を含む
- 実装方針が未確定（既に設計ドキュメントが承認済みの場合はそちらを使う）
- タスクをToDoリスト形式で管理することがユーザーの意図である
プロセス
以下のステップを順番に実行する。
Step 1: コードベースの探索
分解を始める前に、必ずプロジェクトの現状を把握する。
CLAUDE.md/AGENTS.md/README.mdを読んでプロジェクトの概要と規約を把握する- 影響を受けるファイル・ディレクトリ・設定を特定する
- 既存のパターン（命名規則・テスト方法・ディレクトリ構造）を確認する
docs/plans/などの設計ドキュメントが存在する場合は参照する
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リスト（例）:
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でルートが到達できる
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はそれ単体で意味が通じ、検証できること
- コードベース探索を怠らない: 先に探索することで、的外れな分解を防ぐ