
元記事: Claude Codeで実装計画を作る writing-plansスキル(cccskills)
スキルのページ: writing-plans
この記事の結論
writing-plansを入れると、仕様や要件を渡すだけで実装計画を作れます。
変更するファイル、関数の型、テスト、確認コマンドまで書かれた計画が、コードより先にできあがる仕組みです。
この記事では、計画書の中身と自己点検の内容、Claude CodeやCodexへの入れ方を説明します。
後半では、計画を別のエージェントに渡して実装させる方法も扱います。
仕様を渡すと、コードに手を付ける前に計画書が1本できあがります。
タスクごとの変更ファイルとテスト手順まで書かれたものです。
たとえば次のように頼みます。
添付の仕様から実装計画を作ってください。
まだコードは書かないでください。
エージェントはまずwriting-plansを使うと宣言し、計画をdocs/superpowers/plans/YYYY-MM-DD-<feature-name>.mdに保存します。
冒頭に並ぶのは、目的、構成の方針、使う技術、元になった仕様の場所です。
その下には、仕様全体にかかわる制約と「Review Focus」の欄が続きます。
Review Focusに挙がるのは、どのタスクのテストも押さえていない入力や失敗条件です。
各タスクは次の3つの要素で書かれます。
| 要素 | 書かれる内容 |
|---|---|
| Files | 作成・変更・テストするファイルのパス。変更するファイルは行番号まで |
| Interfaces | 前のタスクから受け取るものと、後のタスクに渡す関数名・引数・戻り値の型 |
| 手順 | チェックボックス付きの手順。失敗するテストを書く、失敗を確認する、最小限の実装をする、成功を確認する、コミットする |
計画を書き終えると、エージェントは計画を読むよう求め、実装の進め方を尋ねて止まります。
**確認しないまま実装が始まることはありません。
**
writing-plansは、仕様を「実装者が自分では決められないこと」の一覧に変えるスキルです。
次の4つの働きで、手戻りの元になる曖昧さを実装前に減らします。
計画の読み手として想定するのは、このコードベースも仕様も見ていない実装者です。
そのため計画には、触るファイル、関数の名前と型、仕様にある具体的な値、各タスクを裏付けるテストを書き出します。
関数の中身は書きません。
ただし、型とテストだけでは決まらないアルゴリズムは例外です。
1つのタスクは、それ自体のテストサイクルを持ち、レビューで単独に差し戻せる最小の単位です。
設定や下準備、ドキュメントの作業は、それを必要とするタスクに含めるのが決まりです。
仕様が独立した複数のサブシステムにまたがる場合、エージェントはサブシステムごとに計画を分けるよう提案します。
計画を書き終えると、エージェントは仕様と見比べて次の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は、同じセッションでタスクを順に実行し、最後にブランチ全体をレビューします。
仕様か要件があることが前提です。
まだ固まっていない場合は、先にbrainstormingで目的や制約を整理し、そこから計画を作る流れになります。
既定の保存先はdocs/superpowers/plans/の下です。
日付と機能名を付けたMarkdownファイルとして保存されます。
依頼のときに保存先を指定すれば、そちらが優先されます。
進みません。
計画を保存して自己点検したあと、利用者のレビューを待って止まります。
実装を担うのはsubagent-driven-developmentかexecuting-plansです。
計画の書式の例はPythonとpytestですが、実装者がプロジェクトの言語で書くことを前提にしています。
計画に書くのはファイル、型、テスト、確認コマンドなので、言語に合わせた内容になります。
writing-plansは、AIエージェントにいきなりコードを書かせて手戻りが多い人に向いたスキルです。
仕様から、変更ファイル・関数の型・テスト・確認コマンドを書いた計画を先に作ります。
そのうえで、名前の揺れや仕様漏れを自己点検します。
できた計画は、タスク単位で別のエージェントや担当者に渡せます。
まずは小さな機能追加の仕様で試してみてください。
cccskillsのページ
この記事は cccskills の読みもの「Claude Codeで実装計画を作る writing-plansスキル」の転載です。
スキルの詳細とインストール方法は cccskills の writing-plans のページ にあります。