writing-plans (obra/superpowers)
コードに触れる前に、仕様や要件を段階的な実装計画に落とし込みます。
writing-plans：短い機能仕様をステップバイステップの TDD プランに変換します（対照群 1.6、スキルあり 4.4、一文プロンプト 4.2）。トークンは 1.35 倍です。同じ形式の一文プロンプトはほぼ同等のスコアを獲得します。
Codex CLI · gpt-6-astra
25.3 / 30
スキルなしに対するリフト：+2.87 · 推奨 · 18 実行
推奨：合計 25.3/30 が 22 以上、出力品質 4.4 が 3.5 以上、リフト +2.87 が +1.0 以上。
SOTA
合格Codex でテスト済み。
カバー対象 Codex, Claude Code
Codex CLI 0.166（SOTA ティア）：採点対象 18 実行。当ティアのルールでは、ここでの合格は Claude Code もカバーします。第2ティアについては何も述べません。
スコア
各ディメンションは 0〜5 点で、6 つの合計が 30 点満点の合計スコアになります。すべてのディメンションで 5 が最良です。コスト 5 は低コストで高速、インストール 5 は簡単であることを意味します。
- トリガーの信頼性
- 5.0
- スキルなしに対するリフト
- 4.9
- 出力品質
- 4.4
- トークンと時間のコスト
- 3.0
- インストールと移植性
- 4.0
- 安全性
- 4.0
セキュリティレビュー
安全静的スキャン：CRITICAL 0 / HIGH 0 / MEDIUM 0。手動レビュー：ネットワーク無効のサンドボックスで実行しても安全（指摘なし）。クリーンなスキャン結果はスキルの安全性を証明しません。
インストール
npx skills@latest add obra/superpowers --skill writing-plans
固定コミット: 2ce8aa15d05bd57213e6f746f953aafb7ded7a8b
テスト済み: 2026-11-02
テスト内容
- CLI の期限機能をプラン — spec.md には、この小規模な todo CLI の機能が説明されています。その実装プランをこのフォルダの plan.md に書いてください。プロジェクトにはコードを一切書かないでください。プランのみです。
- CSV エクスポートをプラン — spec.md には、このレポートモジュールの機能が説明されています。その実装プランをこのフォルダの plan.md に書いてください。プロジェクトにはコードを一切書かないでください。プランのみです。
- API レート制限をプラン — spec.md には、このメモ API の機能が説明されています。その実装プランをこのフォルダの plan.md に書いてください。プロジェクトにはコードを一切書かないでください。プランのみです。
長所
- スキルなしと比べ平均スコアを 1.56 から 4.43 に引き上げ（+2.87）。
- スキルは名前を出さずとも採用されました：スキルあり群 6/6 実行でスキルファイルが読み込まれました。
短所
- テスト上の注意：最初のスコアを見た後、3 つのチェックを変更し、新しいルールで全 18 実行を再採点しました。プレースホルダーチェックは単語 TODO（あるタスクでは製品名）に一致しなくなりました。failing-test-first と expected-output のパターンは「Expect failure」という表現を受け入れます。コミットとチェックボックスのしきい値は引き下げられました。変更前はスキルが 2.98、一文プロンプトが 4.04。変更後は 4.43 と 4.21 です。対照群はいずれの場合も 1.5 前後でした。
- タスク・群ごとに n=2。1 ポイント未満の差はノイズです。
レビュー
専用の Windows テスト PC 上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。3 つの小規模な Python プロジェクト（todo CLI、レポートモジュール、メモ API）。それぞれ spec.md があります。プロンプトは plan.md への実装プランのみを求め、コードの記述を禁じます。プランの形式は説明しません。一文プロンプトは形式全体を説明します：2〜5 分で済む小さなステップ、正確なパス、完全なコード付きで先に失敗するテスト、期待される出力付きの正確なコマンド、最小限の実装、git commit、プレースホルダーなし。
3群の比較
| 群 | 平均スコア（0〜5） | 1実行あたりのトークン |
|---|---|---|
| スキルなし | 1.56 | 88k |
| 一文プロンプト | 4.21 | 127k |
| スキルあり | 4.43 | 119k |
Codex CLI で 18 実行を計測し、LLM 判定なしのルールベースのチェックで採点。合計 25.3 / 30、判定は 推奨。
開示事項 初回のスコアを見て3つのチェックを変更し、全 18 実行を新しいルールで再採点しました：プレースホルダーチェックは、あるタスクで製品名である TODO という語に一致しないようにしました。failing-test-first と expected-output のパターンは「Expect failure」という表現を受け入れるようにしました。コミットとチェックボックスの閾値は引き下げました。変更前はスキルが 2.98、一文プロンプトが 4.04 でしたが、変更後は 4.43 と 4.21 になりました。対照群はいずれも 1.5 前後のままでした。
判定：推奨（25.3 / 30）。 出典：obra/superpowers、skills/writing-plans、コミット 2ce8aa1 時点。インストール：npx skills@latest add obra/superpowers --skill writing-plans。ライセンス： MIT（リポジトリの LICENSE）。
概要
writing-plans スキル（obra/superpowers）。仕様を、一口サイズの実装計画に変換します。正確なファイルパス、最初に失敗するテスト、期待される結果付きの正確な実行コマンド、最小限の実装、タスクごとのコミット手順、チェックボックス付き手順、TBD プレースホルダーなし、という内容です。
テスト方法
専用の Windows テスト PC 上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。
小さな Python プロジェクト 3 つ（todo CLI、レポートモジュール、notes API）。それぞれに spec.md があります。プロンプトは plan.md への実装計画の作成だけを求め、コードを書くことを禁じます。計画の形式は説明しません。一文プロンプト群には形式全体を説明します。2〜5 分の一口サイズの手順、正確なパス、完全なコード付きの最初に失敗するテスト、期待される出力付きの正確なコマンド、最小限の実装、git commit、プレースホルダーなし。
- CLI の期限機能の計画 — spec.md は、この小さな todo CLI の機能を説明しています。その実装計画を、このフォルダの plan.md に書いてください。プロジェクトにはコードを一切書かず、計画のみにしてください。
- CSV エクスポートの計画 — spec.md は、このレポートモジュールの機能を説明しています。その実装計画を、このフォルダの plan.md に書いてください。プロジェクトにはコードを一切書かず、計画のみにしてください。
- API レート制限の計画 — spec.md は、この notes API の機能を説明しています。その実装計画を、このフォルダの plan.md に書いてください。プロジェクトにはコードを一切書かず、計画のみにしてください。
採点はプログラム的（隠しテスト／仕込み問題の検出／制約チェック／該当する場合はレンダリング+OCR）で、実行ごとに 0〜5 点。スコアはどの LLM 判定者も決めていません。
結果
第3群に与えた一文プロンプト："計画を一口サイズのタスクとして書く（各手順 2〜5 分）：正確なファイルパス、完全なコード付きの最初に失敗するテスト、期待される出力付きの正確なコマンド、完全なコード付きの最小限の実装、そして git commit の手順。TBD や 'add validation' のようなプレースホルダーはなし。"
| タスク | 対照群スコア | 一文プロンプト | スキルあり | 対照群トークン | 一文プロンプトトークン | スキルありトークン | スキル読込 |
|---|---|---|---|---|---|---|---|
| t1-todo-due | 1.51 | 4.21 | 4.28 | 94k | 132k | 111k | 2/2 |
| t2-csv-export | 1.71 | 4.47 | 4.8 | 84k | 129k | 122k | 2/2 |
| t3-rate-limit | 1.45 | 3.95 | 4.21 | 85k | 120k | 122k | 2/2 |
平均スコア：スキルなし 1.56 対 スキルあり 4.43（差分 +2.87）。1 実行あたりのトークン：88k 対 119k（1.34 倍）、時間 66 秒 対 102 秒。一文プロンプト群：4.21（一文プロンプトに対するスキルの上乗せ：+0.22、スキルなしに対する一文プロンプト自身の上乗せ：+2.65）。一文プロンプトのトークンは 1 実行あたり 127k で、スキルのコストは一文プロンプトの 0.93 倍です。
何が起きたか
- 対照群 1.56、スキルあり 4.43、一文プロンプト 4.21（各 n=6）。対照群の計画は短い散文のアウトライン（46〜71 行）です。6 実行すべてで、最初に失敗するテストの手順も、期待される出力も、コミット手順もなく、実行コマンドは各 1 つだけでした。
- スキルの計画は 110〜142 行のチェックボックス形式で、失敗するテストの手順、「Expect failure」または「Expect all tests to pass」と記された実行手順、CSV タスクでのタスクレベルのコミットがあります。それでも欠けはあります。6 実行中 4 実行に git commit の手順がなく、コードブロックは全手順ではなく 2〜3 手順にしか現れません。
- 一文プロンプトの計画は約 350 行で、各手順に完全なコードがあり、必要なコミットとコマンドがすべて揃っています。ただし 6/6 実行でチェックボックスがなく（スキル固有の形式）、6 実行中 3 実行では実行コマンドが 4 個未満でした。PowerShell の表現を使ったためです。
- トークン：1 実行あたりスキルあり 119k、一文プロンプト 127k、対照群 88k（対照群の 1.35 倍）。スキルはスキルあり群 6/6 実行で読み込まれました。
次元別スコア
| 次元 | スコア | 理由 |
|---|---|---|
| 1_output_quality | 4.43 | スキルありの平均スコア 4.43/5（プログラム的チェック。タスク別の 表を参照）。 |
| 2_lift_vs_no_skill | 4.87 | スキルなしの 1.56 に対して +2.87 ポイント（タスクごとに n=2。約 1 ポイント未満はノイズ）。 |
| 3_trigger | 5.0 | スキルあり群 6/6 実行でスキルファイルが読み込まれました。 |
| 4_instructions_portability | 4 | superpowers 形式の SKILL.md。実行は他の superpowers スキルを 参照します。 |
| 5_efficiency | 3 | トークン 1.34 倍（1 実行あたり 119k 対 88k）、時間 1.54 倍（102 秒 対 66 秒）。 |
| 6_safety_hygiene | 4 | 散文のみ。security.md を参照。 |
このテストの限界
- plan.md のテキストへのルールベースのチェック。パス、コマンド、コミット、チェックボックス、コードブロックの数を数えます。計画の質や、計画が実際に機能するかは判定していません。
- 最初の採点を見た後でチェックを変更し、同じ新しいルールで全実行を再採点しました。(1)「プレースホルダーなし」チェックは TODO という語に一致しましたが、これは todo-CLI タスクの製品名です（パターンから TODO を削除）。(2)「最初に失敗するテスト」と「期待される出力」のパターンを広げて、「Expect failure」と「Expect all tests to pass」も受け入れるようにしました。(3) コミットのしきい値を 3 から 2 に（スキルの計画はタスク 2 つのため）、チェックボックスのしきい値を 12 から 8 に下げました。この変更前はスキル 2.98、一文プロンプト 4.04。変更後は 4.43 と 4.21。対照群はどちらでも 1.4〜1.6 のままでした。
- チェックボックスのチェックは、スキルが使い、一文プロンプトが決して求めなかった形式を数えるため、スキルに有利です。
- セルごとに n=2。小さなフィクスチャ。
- タスク・群ごとに n=2。1 ポイント未満の差はノイズです。
- ルールベースの採点はチェックで見えるものだけを測ります。センスや、その結果が可能な限り最良かどうかは判定できません。
セキュリティ
security.md を参照。スキャン：0 CRITICAL / 0 HIGH / 0 MEDIUM。判定：実行しても安全（ネットワーク無効のサンドボックス）。クリーンなスキャン結果はスキルの安全性を証明しません。
まとめ
助けなしでは Codex は緩いアウトラインを書きます。スキルがあれば本物の TDD 手順を書きます。同じ形式を名指しした段落もほぼ同等で、手順ごとにより充実したコードを生むため、スキルは主にその段落を便利にまとめたものです。
トランスクリプト
実行ログ：writing-plans (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.) 列：タスク、群-回、スコア（0-5）、トークン、秒、合格したチェック、エージェントが開いたスキルファイル。 t1-todo-due control-1: スコア 1.38, トークン 102848, 秒 60.8, チェック 3/10, 開いたファイルなし t1-todo-due control-2: スコア 1.64, トークン 86724, 秒 67.6, チェック 3/10, 開いたファイルなし t1-todo-due oneliner-1: スコア 4.47, トークン 133771, 秒 130.1, チェック 9/10, 開いたファイルなし t1-todo-due oneliner-2: スコア 3.95, トークン 131546, 秒 112.8, チェック 8/10, 開いたファイルなし t1-todo-due treatment-1: スコア 4.34, トークン 123893, 秒 104.1, チェック 8/10, 開いたファイル writing-plans t1-todo-due treatment-2: スコア 4.21, トークン 99712, 秒 99.6, チェック 8/10, 開いたファイル writing-plans t2-csv-export control-1: スコア 1.71, トークン 85021, 秒 70.6, チェック 4/10, 開いたファイルなし t2-csv-export control-2: スコア 1.71, トークン 84700, 秒 64.8, チェック 4/10, 開いたファイルなし t2-csv-export oneliner-1: スコア 4.47, トークン 129967, 秒 119.6, チェック 9/10, 開いたファイルなし
18 実行、3 成果物
サンプル出力
SOTA · With the skill: plan.md (t1-todo-due, run 1, Codex)
# Todo Due Dates Implementation Plan > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking. **Goal:** Add optional due dates, chronological listing, and an overdue-only CI check without migrating existing data. **Architecture:** Keep the existing JSON dictionary storage and implement date validation, ordering, and rendering in `todo/cli.py`. Capture the local date once per list invocation and pass it to a pure overdue predicate. Preserve the existing `main(argv=None)` entry point and argparse error handling. **Tech Stack:** Python standard library: argparse, datetime, json, unittest, unittest.mock, tempfile; no new dependencies. **Spec:** `spec.md` (read alongside this plan). ## Global Constraints - `todo add "title" --due 2026-03-01` stores an optional ISO due date with the item. - `todo list` prints overdue items first (marked `!`), then by due date, then undated items. - `todo list --overdue` prints only overdue items; exit code 1 if there are any (so CI can use it). - Invalid dates are rejected with a clear message and exit code 2. - Items already stored without a due date must keep working (no migration step for the user). ## Decisions for details not specified - Accept exactly `YYYY-MM-DD` with a real Gregorian calendar date; reject whitespace, compact dates, timestamps, and unpadded components. - An item is overdue only when unfinished and its due date is strictly before the current local date. Due today is not overdue. - Sort overdue items by ascending due date, then remaining dated items by ascending due date, then undated items. Preserve insertion order within equal keys. Completed items remain visible in ordinary listings but are never overdue. - Preserve `[ ] title` and `[x] title` for undated items. Append ` (due YYYY-MM-DD)` for dated items and prefix overdue lines with `! `, e.g. `! [ ] rent (due 2026-03-01)`. - Ordinary listing returns 0, even with overdue items. Overdue-only listing returns 0 with no output when none qualify. Listing never rewrites storage. - Store dates as strings under `due`; omit the key when not supplied. Treat an absent key or `null` as undated. Arbitrary corrupt JSON or malformed dates manually inserted into storage are outside this feature. ## Review Focus 1. Calendar boundaries: leap day is accepted only in leap years; impossible dates fail before storage changes (Task 1). 2. ISO-looking variants: compact dates, timestamps, whitespace, and unpadded dates are rejected (Task 1). 3. Midnight/today boundary: due today is not overdue; use one captured local date per listing (Task 2). 4. Completed items with past dates: remain visible without `!` and are excluded from overdue filtering (Tasks 2–3). 5. Legacy and tied items: missing/null dates work, ties retain insertion order, and listing leaves the JSON file untouched (Tasks 2–3). ## File Map - Modify `todo/cli.py`: add argument validation, optional date persistence, overdue predicate, sorting, rendering, and filter exit status. - Create `tests/test_cli.py`: isolated CLI tests u [... excerpt: first 3200 of 11517 characters]