Claude Codeで実装計画を作る writing-plansスキル

使うとこうなる

仕様を渡すと、コードに手を付ける前に計画書が1本できあがります。タスクごとの変更ファイルとテスト手順まで書かれたものです。たとえば次のように頼みます。

添付の仕様から実装計画を作ってください。まだコードは書かないでください。

エージェントはまずwriting-plansを使うと宣言し、計画をdocs/superpowers/plans/YYYY-MM-DD-<feature-name>.mdに保存します。冒頭に並ぶのは、目的、構成の方針、使う技術、元になった仕様の場所です。

その下には、仕様全体にかかわる制約と「Review Focus」の欄が続きます。Review Focusに挙がるのは、どのタスクのテストも押さえていない入力や失敗条件です。

各タスクは次の3つの要素で書かれます。

要素	書かれる内容
Files	作成・変更・テストするファイルのパス。変更するファイルは行番号まで
Interfaces	前のタスクから受け取るものと、後のタスクに渡す関数名・引数・戻り値の型
手順	チェックボックス付きの手順。失敗するテストを書く、失敗を確認する、最小限の実装をする、成功を確認する、コミットする

計画を書き終えると、エージェントは計画を読むよう求め、実装の進め方を尋ねて止まります。確認しないまま実装が始まることはありません。

writing-plansでできること

writing-plansは、仕様を「実装者が自分では決められないこと」の一覧に変えるスキルです。次の4つの働きで、手戻りの元になる曖昧さを実装前に減らします。

仕様を決定事項にまとめる

計画の読み手として想定するのは、このコードベースも仕様も見ていない実装者です。そのため計画には、触るファイル、関数の名前と型、仕様にある具体的な値、各タスクを裏付けるテストを書き出します。

関数の中身は書きません。ただし、型とテストだけでは決まらないアルゴリズムは例外です。

テストできる単位にタスクを分ける

1つのタスクは、それ自体のテストサイクルを持ち、レビューで単独に差し戻せる最小の単位です。設定や下準備、ドキュメントの作業は、それを必要とするタスクに含めるのが決まりです。

仕様が独立した複数のサブシステムにまたがる場合、エージェントはサブシステムごとに計画を分けるよう提案します。

書き終えた計画を自己点検する

計画を書き終えると、エージェントは仕様と見比べて次の5項目を確かめます。

1. 仕様の各要件に対応するタスクがあるか
2. 「TBD」「エッジケースを処理」のように何も決めていない行や、書きすぎた関数本体がないか
3. 前のタスクで定義した型や関数名を、後のタスクでも同じ名前で使っているか
4. 仕様から想定される入力や失敗条件を、どこかのタスクのテストが押さえているか
5. 計画が仕様に比べて長くなりすぎていないか

見つけた問題はその場で直し、対応するタスクがない要件にはタスクを足します。Task 3でclearLayers()、Task 7でclearFullLayers()と書いたような名前の揺れを拾うのも、この段階です。

別の担当者やエージェントに渡せる形にする

各タスクのInterfaces欄に書かれるのは、受け取るものと渡すものの正確な型です。実装者は自分のタスクだけを読んでも、隣のタスクと名前や型をそろえられます。

計画の冒頭には、元の仕様の場所も書かれています。受け取った側は、計画と仕様を並べて読めるわけです。

インストール方法

writing-plansはobra/superpowersに含まれるスキルの1つで、付属ファイルはSKILL.mdだけです。コマンドで入れるなら次を実行してください。入れる先のエージェントは、Claude CodeやCodexなどから選べます。

npx skills add https://github.com/obra/superpowers --skill writing-plans

エージェントに入れてもらう場合は、次の文面をそのまま送ってください。中身を確かめてから配置するよう頼む内容です。

次の Agent Skill をインストールしてください。
https://github.com/obra/superpowers/tree/main/skills/writing-plans

まず SKILL.md と付属ファイルの中身を確認し、不審な処理（外部への送信、認証情報の読み取りなど）がないことを確かめてから、Claude Code なら ~/.claude/skills/writing-plans/、Codex なら ~/.agents/skills/writing-plans/ に配置してください。

置き場所は、すべてのプロジェクトで使うか、特定のプロジェクトだけで使うかで選びます。

エージェント	すべてのプロジェクトで使う	特定のプロジェクトだけで使う
Claude Code	~/.claude/skills/	プロジェクトの.claude/skills/
Codex	~/.agents/skills/	プロジェクトの.agents/skills/

使い方の例

依頼文には、仕様の場所と、計画の保存先や実行方法の希望を添えると話が早く進みます。代表的な頼み方は次の3つです。

この機能追加の要件から、変更するファイルとテスト手順を含む実装計画を作って。保存先はdocs/plans/にして。

計画は指定したdocs/plans/に保存されます。保存先の希望が、既定の場所より優先されるためです。各タスクには、ファイルの一覧と、テストから書き始めるチェックボックス付きの手順が付きます。

計画のTask 2で、どのテストをどのコマンドで実行して、何が出れば成功か教えて。

計画の確認手順には、実行コマンドと成功を示す出力が書かれています。そのため返ってくるのは、失敗を確かめる段階と成功を確かめる段階それぞれについて、計画に書かれたままのコマンドと期待結果です。

計画ができたら、タスクごとに別のエージェントに実装させたい。

実行方法を先に伝えておけば、エージェントは方法を聞き直さず、計画の確認だけを求めます。伝えていない場合は次の2つから選ぶよう尋ね、どちらを勧めるかを理由とともに添えます。

方法	進め方	特徴
Subagent-driven	タスクごとに新しいサブエージェントが実装し、新しいレビュアーが確認してから次へ進む。最後にブランチ全体をレビュー	最も丁寧。タスクとレビューのたびに新しいコンテキストを使う
Native	同じセッションで全タスクを実装し、最後に最も能力の高いモデルのレビュアーがブランチ全体を確認	最も安く速い。途中に独立したレビューはない

注意点

writing-plansは、仕様か要件が手元にある状態で使うスキルです。前提になる仕様は人が用意し、内容を確かめておきましょう。仕様が曖昧なまま渡すと、計画もその曖昧さを引き継ぎます。

実装の段階では、別のスキルを呼び出す作りになっています。Subagent-drivenならsubagent-driven-development、Nativeならexecuting-plansが必要です。どちらもobra/superpowersに含まれるので、あわせて入れておいてください。

計画はそのまま受け入れず、自分で読んで判断してください。特にReview Focusの欄には、テストで押さえきれていない入力や失敗条件が並びます。実際の利用者に影響しそうな順に目を通すのがよいでしょう。

ライセンスはMITです。入れる前にSKILL.mdの中身を読み、指示の内容を確かめてください。

関連スキル

同じobra/superpowersのスキルから、計画の前後をつなぐものを3つ紹介します。

brainstormingは、計画の前段階で目的や制約を対話で整理し、作業の規模に合った設計をまとめます。仕様がまだ固まっていないときは、こちらが出発点です。

subagent-driven-developmentは、計画をタスクごとに別のエージェントへ任せ、仕様への適合とコード品質を確かめながら進めます。executing-plansは、同じセッションでタスクを順に実行し、最後にブランチ全体をレビューします。

まとめ

writing-plansは、AIエージェントにいきなりコードを書かせて手戻りが多い人に向いたスキルです。仕様から、変更ファイル・関数の型・テスト・確認コマンドを書いた計画を先に作ります。そのうえで、名前の揺れや仕様漏れを自己点検します。

できた計画は、タスク単位で別のエージェントや担当者に渡せます。まずは小さな機能追加の仕様で試してみてください。cccskillsのページ