planning-and-task-breakdown

仕様か明確な要件があって、それを実装できる単位に割りたいときに使います。本文の「使うとき」は、仕様を実装の単位に割る、作業が大きすぎるかあいまいで手を付けられない、複数のエージェントやセッションで並行に進めたい、範囲を人に伝えたい、実装の順が明らかでない、の 5 つです。

本文は、良い分解こそが、確実に仕事を終えるエージェントと、もつれたものを作るエージェントの差だ、と書いています。どの作業も、1 回の集中で実装し、試験し、確かめられる大きさにするのが目標です。

計画の進め方

5 段

作業の大きさ（XS〜XL）

5 段階

SKILL.md（2026-10-23 時点）

10,564 バイト

計画は 5 段で進める

1. 計画の型に入る読むだけで動く。仕様とコードを読み、既存の型・部品の依存・危険と未知を書き出す
2. 依存の図を描く何が何に依存するかを描き、土台から下から順に作る
3. 縦に切る層ごとではなく、1 本の機能の道筋ごとに作業にする
4. 作業を書く説明・受け入れの条件・確かめ方・依存・触りそうなファイル・大きさ
5. 並べて区切る依存の順、危険の高いものを先、2〜3 作業ごとに確かめの区切り

計画のあいだはコードを書きません。出すのは計画書と作業の一覧で、実装ではない、と本文は念を押しています。

層ごとではなく、縦に切る

悪い例として挙がっているのは、データベースを全部、次に API を全部、次に画面を全部作り、最後につなぐ、という分け方です。良い例は「利用者がアカウントを作れる」「ログインできる」のように、表・API・画面をまとめて 1 本の機能を通す分け方です。

縦の切れ目なら、作業が終わるたびに動いて試せるものが 1 つ増えます。層ごとに分けると、最後につなぐまで何も確かめられません。

作業 1 件の書式

1 件ごとに、何を達成するかの 1 段落、受け入れの条件、確かめ方、依存する作業の番号、触りそうなファイル、見積もった大きさを書きます。確かめ方は、試験のコマンド、ビルドのコマンド、手での確認の 3 つが雛形に入っています。

並べるときは、依存を満たす、どの作業の後もシステムが動く状態を保つ、2〜3 作業ごとに確かめの区切りを入れる、危険の高い作業を先に置いて早く失敗する、の 4 つを守ります。区切りには、試験が通る、ビルドが通る、主な流れが端から端まで動く、先に進む前に人と見直す、が入ります。

作業の大きさ

L 以上は分けよ、エージェントがいちばんうまくやるのは S と M だ、と本文は書いています。さらに分ける兆しは、1 回の集中（エージェントの作業でおよそ 2 時間以上）で終わらない、受け入れの条件を 3 つ以下で書けない、独立した仕組みを 2 つ以上触る、作業の題に「と」が入る、の 4 つです。

並行にしてよいもの、いけないもの

• 並行にしてよい独立した機能の切れ目、実装済みの機能の試験、文書
• 順番に進めるデータベースの移行、共有の状態の変更、依存の連鎖
• 調整が要るAPI の約束を共有する機能。先に約束を決めてから並行に

計画書の雛形

計画書は、概要、設計の判断と理由、作業の一覧（土台・中核の機能・仕上げの 3 段と、段ごとの区切り）、危険と影響と対策の表、人に答えてほしい未解決の問い、の順に並びます。設計の判断や危険はトラッカーの 1 件ずつにはうまく収まらないので、計画書は常に Markdown のファイルにする、と書かれています。

本文が名指しで外しているのは、範囲が明らかな 1 ファイルの変更と、仕様にすでに作業がきちんと定義されている場合です。

まだ仕様が無いなら

このスキルは仕様か明確な要件があることを前提にしています。何を作るかがまだ決まっていないなら、先に同じ公開元の spec-driven-development で仕様書を書くのが順番です。そちらの本文は、計画と作業の分解の手順はこのスキルが正だ、と書いています。

文脈を持たない実装者に渡す詳しい計画なら

ここで作る作業は、受け入れの条件と触りそうなファイルまでの粒度です。実装者が自分で決められないファイルの経路や型や試験まで書き込んだ計画が要るなら、writing-plans のほうが細かく書かせます。書いた計画を順に実行していく段は executing-plans が扱っています。

長い作業の進み具合を書き続けたいなら

このスキルは計画を作るところまでで、進み具合の記録や会話が圧縮されたあとの取り戻し方は扱いません。それが目的なら、計画と進捗をファイルに書き続けさせる planning-with-files が合います。

SKILL.md には、外部への通信やシェルの実行の記述はありません。ファイルは書きます。計画書の tasks/plan.md と、作業の一覧（既定で tasks/todo.md）で、tasks/ が無ければ作ります。

外部のトラッカーを使う場合も同じで、新しい計画の場所を空けるために、ほかの計画の開いている項目をまとめて閉じたり消したりするな、と書かれています。

作業の一覧の置き場所は 1 か所で決まる

既定は tasks/todo.md のチェックリストで、同じリポジトリの /build などの後工程がこの置き場所を前提にしている、と書かれています。プロジェクトの CLAUDE.md や AGENTS.md、または利用者がトラッカーを指定していれば、作業ごとに 1 件の項目を起こし、依存はトラッカーのつなぎ方（bd dep add や「blocked by」など）で表します。

そのときは tasks/plan.md に、どこで作業を管理しているかを書き、作業の一覧の節は項目の ID やリンクの並びにします。tasks/todo.md とトラッカーの両方に作業を散らすことは、危険の兆しに入っています。

作業 1 件で触るファイルはおよそ 5 つまで

確かめの一覧に、どの作業も約 5 ファイルを超えない、という項目があります。大きさの表では L が 5〜8 ファイルなので、L の作業は分けてから実装に入る、ということになります。

完了の定義はフォルダの外にある

末尾は、作業ごとの受け入れの条件の上に、プロジェクト全体の「完了の定義」がある、として ../../references/definition-of-done.md を案内しています。これはリポジトリの直下にあり、スキルのフォルダには SKILL.md しかありません（同梱 0 件、2026-10-23 時点）。

最後に人が計画を承認する

確かめの一覧の最後は「人が計画を見直して承認した」です。計画を作らせたら、そのまま実装に入らせず、一度目を通す流れを前提にしてください。

ライセンス

リポジトリのライセンスは MIT です。

小さな変更でも計画を作らせる必要がありますか

本文は、範囲が明らかな 1 ファイルの変更は対象外としています。一方で、よくある言い訳の表では「作業は明らかだ」にも、書き出せ、隠れた依存や忘れた端の場合が表に出る、と返しています。迷う大きさなら、作業の一覧だけでも書かせる価値がある、という立場です。

spec-driven-development とはどう違いますか

spec-driven-development は仕様・計画・作業の分解・実装の 4 段を回すスキルで、そのうち計画と分解の詳しい手順をこのスキルに任せています。仕様書がすでにあるなら、このスキルから始めて構いません。

Claude Code の `/plan` とは何が違いますか

公開元は、Claude Code のプラグインとして入れたときの命令 /plan を用意していて、中身はこのスキルを呼び、仕様を読んで読むだけの状態で計画し、tasks/plan.md と tasks/todo.md に保存する指示です（2026-10-23 確認）。npx skills add でこのスキルだけを入れた場合、命令は付かず、スキルが単体で動きます。

対応しているエージェントはどれですか

公開元の README が、Claude Code（推奨と明記）と Codex のそれぞれに入れ方を案内しています（2026-10-23 確認）。README はほかに Cursor・Gemini CLI・GitHub Copilot などへの入れ方も載せていますが、当サイトが表示しているのは Claude Code と Codex の 2 つです。