writing-plans
仕様から、文脈を持たない実装者に渡せる計画を書かせる。書くのは「実装者が自分では決められないこと」だけ。ファイル・名前と型・仕様の値・試験。本体のコードは原則として書かせない
npx skills add obra/superpowers/writing-plans入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 290,184
- 実用度
- 86
- GitHub star
- 313,505
- 最終更新
- 2026/11/4
頼み方の例
そのままコピーして使えますwriting-plansを使って、この仕様から実装計画を作ってください。各タスクに使う名前と型、試験の名前と確かめる値を入れ、仕様が触れていないが壊れやすい入力を「見直しの焦点」に挙げてください。計画を書いたら自己点検の 5 項目もやってください。実装はまだ始めないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: markdown
いつ使うか
仕様は決まったが、まだコードに触っていないときです。
読み手は文脈を持たない実装者
読み手は「このコードベースも仕様も見ていない実装者」です。2026 年 9 月の改訂で、その実装者の置き方が変わりました。
| 以前 | いま | |
|---|---|---|
| 実装者の想定 | 文脈を持たず、趣味も怪しい | 正確な名前と試験が分かれば、慣用的なコードを書ける |
| 計画に書くもの | 各段に実際のコードを全部 | 実装者が自分では決められないことだけ |
| 本体のコード | 必須 | 署名と試験で決まらない処理のときだけ |
本文の言い方では、実装者に分からないのは「あなたが何を決めたか」です。どのファイルか、どの名前と型か、仕様のどの値か、どの試験が各タスクを証明するか。それを書け、としています。
1 つの段に書くもの
段（ステップ）の条件は 1 つで、「実装者がそこから書けるものが 1 つに決まる」ことです。完全である必要はありません。
- 試験の段試験の名前と確かめる内容（コードで、仕様の正確な値を入れる）
- 実装の段正確な署名（名前・引数・戻り値の型）、置くファイル、仕様が決めている値
- 確かめの段実行するコマンドと、通ったとみなす出力
- 他のタスクへの参照そのタスクの「インターフェース」の欄を見よ、と書く
書きすぎも、決めなさすぎも失敗
「計画が、それが表すコードより長いなら、計画ではなくコードを書いている」と書かれています。
逆に「TBD」「適切な検証を追加」「上記の試験を書く」のように何も決めていない行も失敗です。
見直しの焦点
計画の冒頭の決まった欄に、「見直しの焦点」が加わりました。仕様が示しているのに、どのタスクの試験も確かめていない入力や失敗の形のうち、使う人を最も困らせそうな 5 つを 1 行ずつ書きます。
仕様が触れていない入力で壊れてよいわけではない、という考えです。書いた 5 つには、それを受け持つタスクに試験を足します。
同じ冒頭には「全体の制約」の欄もあります。版の下限・依存の制限・命名の規則など、仕様の全体にかかる要件を、正確な値のまま 1 行ずつ写します。各タスクの要件には、この欄が暗に含まれます。
書いたあとの自己点検（5 項目）
- 仕様の網羅各項目に対応するタスクを指せるか
- 段の点検何も決めていない行と、書きすぎた本体の両方を直す
- 型の一貫性前のタスクと後のタスクで名前が変わっていないか
- 見直しの焦点試験の無い入力を 5 つ選び、試験を足したか
- 釣り合い計画が仕様の何倍も長く、コードが大半なら、署名と試験に置き換える
最後に計画を読ませ、実行の仕方を選ばせる
保存したら、利用者に計画を読んでもらい、実行の仕方を選ばせます。
サブエージェント方式
タスクごとに新しい実装役と見直し役。最も丁寧だが高くつく
渡す先: subagent-driven-development
このセッションで実行
自分で全タスクを実装し、最後に最も能力の高いモデルが全体を見直す。安く速い
渡す先: executing-plans
以前のように「サブエージェント方式を推奨」と決め打ちせず、計画の中身から 1 つを理由つきで勧める形になりました。前者は subagent-driven-development、後者は executing-plans に渡されます。
利用者が実行の仕方を先に指定しているときは、選ばせずに計画の確認だけを求めます。確認を待ってから、指定された方式で実装に入ります。
使わないほうがいいとき
仕様が無いとき
仕様が無いなら順序が逆です。本文にも、複数の独立した部分にまたがる仕様は構想の段階で分けておくべきだったと書かれています。そちらは brainstorming の担当です。
小さな変更
小さな変更には重すぎます。1 ファイルの修正に、ファイル構成の設計とタスクの分割と自己点検を通す意味は薄いです。
試験が書けない対象
試験が書けない対象には合いません。段の骨格が「落ちる試験 → 実装 → 通す」なので、見た目の良し悪しのような対象は型に乗りません。
注意点
実際には計画のファイルを書く
SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは無く、SKILL.md 1 枚で完結しています。
ただし実際には計画のファイルを書きます。保存先は docs/superpowers/plans/YYYY-MM-DD-<名前>.md が既定で、利用者の指定があればそちらが優先されます（スキルを入れる前に確認すること）。
以前の版と、計画の書き方が逆向き
以前の版と、計画の書き方が逆向きです。以前は「各段に実際のコードを入れよ」「Task N と同様、と書くな（コードを繰り返せ）」でした。いまは本体のコードを原則として書かず、他のタスクのコードも繰り返しません。
古い版で書かれた計画と見比べると、短くなって見えるのは意図どおりです。
計画の質は仕様の質を超えない
ライセンス
ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
planning-and-task-breakdown
仕様や明確な要件を、1 回の集中で実装して確かめられる小さな作業に割らせる。依存の図を描き、層ごとではなく機能の縦の切れ目で分け、作業ごとに受け入れの条件と確かめ方を付けて計画書と作業の一覧に書かせる。未完了の計画は上書きさせない
brainstorming
作る前に、本当に欲しいものとその理由を聞き出させる。作り方の案を選ばせ、設計書が承認されるまで何も作らせない
executing-plans
書かれた計画を、同じセッションで自分で実装させる。タスクごとに試験を落としてから通し、判断は「裁定」として台帳に残して止まらず進む。最後に全体を 1 回だけ別の目で見直す
subagent-driven-development
計画をタスクごとに別のエージェントへ投げて、毎回レビューを通させる。途中で人に相談させない
test-driven-development
テストが落ちるのを見るまで実装させない。先に書いたコードは消させる
よくある質問
実装のコードを書かないと、実装者が迷いませんか
本文の前提は、名前と型と試験が正確なら、実装者は慣用的なコードを書け、計画が決めていない所では妥当な選択をする、というものです。署名と試験だけでは決まらない処理（どのライブラリを使うか、どのデータ構造か）は、1 行で方針を書きます。それでも決まらない手順のときだけ、コードを書きます。
タスクはどれくらいの大きさにしますか
自分の試験の周回を持ち、見直し役の関門に値する最小の単位です。準備や設定や文書は、それを必要とする成果物のタスクに畳み込み、分けるのは見直し役が片方だけを却下できるときだけです。
計画はどこに保存されますか
既定は docs/superpowers/plans/YYYY-MM-DD-<機能名>.md です。利用者の設定があればそちらが優先されます。
対応しているエージェントはどれですか
Claude Code と Codex です。公開元は群の入口（using-superpowers）に実行環境ごとの補足ファイルを置いています。当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。