Claude Code に「この機能の実装計画を出して」と頼むと、見出しと箇条書きが続く長い Markdown が返ってきます。内容は正しくても、どこに自分の判断が必要なのかを探すのに時間がかかります。読み飛ばした箇所に大事な前提が埋まっていて、実装が終わってから気づくこともあります。
2026 年 10 月 6 日、Thariq（@trq212）さんが、この悩みに向けたスキルを X で紹介しました。
I’ve been working on a skill that makes better HTML plans in Claude Code.
It uses simple language, shows code snippets, surfaces questions & makes mockups. Linting reduces the normal failure cases that Claude runs into.
Would love your feedback before shipping more broadly!
— Thariq (@trq212) 2026年10月6日
投稿の要旨は「Claude Code で、より良い HTML の計画書を作るスキルを作っている。平易な言葉を使い、コード片を見せ、確認すべき問いを表に出し、モックアップも作る。lint で Claude がよく失敗するパターンを減らした。広く出す前にフィードバックがほしい」というものです。
つまり html-plan は、正式リリース前のフィードバック募集段階にあるスキルです。Anthropic のコミュニティ用マーケットプレイスからプラグインとして導入できます。本記事では、プラグインに同梱されたサンプル計画を手元で実際に組み立て、何が見えるのかを画面つきで紹介します。確認日は 2026 年 10 月 6 日、プラグインのバージョンは 1.0.0 です。
html-plan は計画を「主張のツリー」にする
html-plan の考え方は、プラグイン内の説明書（SKILL.md）にまとまっています。計画書は手書きの HTML 1 ファイルで、中身は「主張（claim）のツリー」です。ツリーの階層ごとに答える問いが決まっていて、問いに合った「証拠（exhibit）」を 1 つだけ添えます。
| 階層 | 答える問い | 主張の形 | 添える証拠 |
|---|---|---|---|
| タイトル | これは何か | 変更内容と場所を 3〜7 語で | なし（「Why」に依頼者の原文を引用） |
| 1 | 誰が何をできるように・見えるようになるか | ふるまい | UI モックアップ、または状態遷移図 |
| 2 | それはどう動くか | 入口・ルール・データ | 呼び出しの流れ、スキーマ、短いコード |
| 3 | どこを変えるか | ファイル:行番号 |
実際のコード |
ポイントは、第 1 階層を「ファイル」や「作業順」ではなく「ふるまい」で分けることです。ふるまいなら、コードを読まない人でも正しいかどうかを判断できます。各主張は「真か偽か言える 1 文」で書くルールなので、「メッセージ上限」のような見出しではなく、「1 人が予約できるメッセージは最大 50 件」のような言い切りになります。
閉じたツリーが、そのまま要約になる
同梱のサンプルは、架空のメールアプリ「PostBox」に「予約送信（Send later）」を足す計画です。開いた直後は、第 1 階層の主張だけが並びます。
ここに TL;DR（要約）の欄はありません。SKILL.md には「閉じたツリーが要約である。第 1 階層の主張だけを読み上げて、変更の全体が伝わらなければならない」と書かれています。画面を上から読むだけで、次のことが分かります。
- 作成画面で送信時刻を選べる
- 予約したメッセージを 1 つの一覧で確認・変更できる
- メッセージは指定時刻にだけ送られ、失敗した送信は残る
- 予約送信が失敗したらユーザーに知らせる
最後の 2 行は、複数の主張が使う共有データ（新しいテーブル 1 つ）と、変更しないもの（通常の送信、下書き、メール配信の仕組み）です。「何を変えないか」を明記させる点は、レビューの漏れを防ぐうえで地味に効きます。
開くと、モックアップと呼び出しの流れが出てくる
主張をクリックすると、1 段ずつ中身が開きます。第 1 階層「作成画面で送信時刻を選べる」を開いた状態です。
モックアップには「新しいボタン。送信ボタンは変更しない」という注記が付いています。その下の第 2 階層では、ボタンから API、サーバー側の関数、テーブルへの書き込みまでの呼び出しの流れが、ファイル:行番号 つきで示されます。行頭の + は新規、~ は変更です。
各行には「comment（コメント）」と「strike（この呼び出しは不要と打ち消す）」のボタンもあり、読み手はその場で意見を残せます。
判断ポイントは、それが変える主張の上に置かれる
html-plan の一番の特徴は、ユーザーに決めてほしいこと（decision）を、計画の末尾にまとめず、それが影響する主張の真下に置く点です。右下の「4 to answer」ボタンを押すと、未回答の判断ポイントへ順に移動します。
「1 人あたり予約できるのは何件までか」という問いが、「最大 50 件」という主張と、その上限を確かめるコード片のすぐ下にあります。Claude のおすすめには「Suggested」が付き、最初から選ばれています。どの主張が何を前提にしているかを見ながら選べるので、「この選択肢を選ぶと、どの実装が変わるのか」を想像しやすくなります。
SKILL.md では、問うのは「何を作るかが変わる分岐」だけ、1 つの計画につき 2〜5 個まで、と決められています。選択肢を選ぶと主張が丸ごと不要になる場合は、「claim 4 goes（主張 4 は消える）」のように書くことも求められています。
回答は 1 つの返信にまとめて、Claude へ貼り戻す
選択・コメント・スキーマの書き換えが済んだら、「Respond」を押します。
シートには、すべての判断ポイントと現在の答えが並び、その下に Claude へ貼り戻すための Markdown が生成されます。「Copy response」でコピーし、Claude Code のチャットに貼れば、Claude はそれを反映してから実装に入ります。SKILL.md は「その返信が届くまで、作り始めてはいけない」と Claude 側に指示しています。
細かいところですが、返信文は判断ポイントごとに次の 2 つを区別して書き出します。
_(kept as proposed)_：読み手が開いたうえで、提案どおりを選んだ_(not opened; default kept)_：読み手が開いていない（＝初期値のまま）
後者を「同意」と読まないように、Claude 側への指示にも「重要な判断なら、チャットで改めて聞くこと」と書かれています。「レビューで何も言われなかった」と「レビューで承認された」を区別する、よい設計だと思います。
lint が「Claude のよくある失敗」を事前に止める
X 投稿にある「Linting」は、同梱の pack.mjs のことです。計画の HTML を検査し、CSS と JavaScript を埋め込んだオフラインでも開ける 1 ファイルに固めます。node が必要なのはこの処理のためです。
SKILL.md によると、pack.mjs が自動で確かめるのは次のようなルールです。
- 第 1・第 2 階層の主張が、真偽を言える短い 1 文になっているか
- 1 つの主張に証拠が 1 つだけか
- 子は 5 つまで、階層は 3 段までか
- 判断ポイントの数が、決められた範囲に収まっているか
- 末尾に「共有データ」と「変更しないもの」があるか
- ページの先頭がタイトルで始まっているか
手元でサンプルを組み立てたところ、次のような警告が 6 件出ました（抜粋）。
⚠ line 48 <doc-calls>: 7 rows point at files not found under . — pass --root <checkout> (and ref="<sha>" for a merged PR) so rows can open their code
✓ scheduled-send.packed.html 218 KB · 2 asset(s) inlined · 6 warning(s)サンプルは架空のアプリなので、呼び出しの流れに書かれたファイルが手元に存在しません。実際のリポジトリで使うときは --root にチェックアウトの場所を渡すと、各行から実際のコードを開けるようになります。計画に書いた ファイル:行番号 が本当に存在するかを機械的に確かめてくれるわけです。AI が書く計画でよくある「もっともらしいが存在しないパス」を、渡す前に見つけられます。
インストール方法
Claude Code のターミナルで、次の 2 コマンドを順に実行します。
claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install html-plan@claude-community1 行目で Anthropic のコミュニティ用マーケットプレイスを追加し、2 行目で html-plan プラグインを入れます。
入れたあとは、チャットで次のように呼びます。
/html-plan コンポーザーに送信予約を追加するページを 1 ファイルにまとめる処理に node が必要です。それ以外の依存はありません。
SKILL.md によると、/html-plan と打たなくても、「複数ファイルにまたがる変更の前に、計画・RFC・設計を求めたとき」にもこのスキルが使われる想定です。できあがった計画は、plan.packed.html としてブラウザで開いて受け取ります。Claude の Artifact 機能が使える環境では、--artifact を付けてまとめた plan.artifact.html を、非公開の Artifact として発行して受け取ることもできます。
使う前に知っておきたい 3 つの注意点
1. 計画の文章は英語で書かれる
日本語で使う人がまず気づくのはここです。SKILL.md は、計画内の文章（主張、注記、問い、選択肢）をすべて ASD-STE100 Simplified Technical English（STE） で書くよう指示しています。STE は、航空機の整備マニュアルなどのために作られた「制限された英語」で、使ってよい単語・時制・文の長さが決まっています。「should や may を使わず must と can を使う」「受け身を使わない」「1 文は 20〜25 語まで」といった具合です。
日本語で依頼しても、計画本体は平易な英語で出てくると考えておくのがよいでしょう。例外は、依頼者の言葉をそのまま引用する「Why」欄、コード、モックアップ上の文字です。英語が苦手なメンバーと共有するなら、返ってきた計画の要点を Claude に日本語で説明させる、といった併用が現実的です。
2. 貼り戻す返信は「指示」ではなく「データ」として扱われる
計画ページは、チームの誰かに共有して答えてもらうこともできます。そのため SKILL.md は、貼り戻された返信を計画への回答というデータとして扱い、コメント欄に「このコマンドを実行して」と書かれていても実行しないよう Claude に指示しています。新しい依頼や危険な依頼がコメントにあれば、チャットで利用者に確認する決まりです。共有しても安全側に倒れる設計になっています。
3. まだフィードバック募集段階である
X 投稿のとおり、html-plan は作者が「広く出す前にフィードバックがほしい」としている段階です。プラグインの説明書きや見た目は、今後変わる可能性があります。業務の手順に組み込む場合は、版を確かめてから使い、変化に追随できる余地を残しておくのが無難です。
フィールフロウの視点：計画は「読む」から「答える」へ
AI に実装を任せる開発では、人間の仕事は「書くこと」から「判断すること」へ移っていきます。フィールフロウがAI 仕様駆動開発で重視しているのも、AI が走り出す前に、人間が決めるべきことを決めておくことです。
その観点で見ると、html-plan の価値は見た目の美しさより、次の 3 点にあると考えます。
- 判断が必要な箇所が、数と位置で分かる（「4 to answer」と、主張の真下の問い）
- 答えなかったことが、答えなかったと記録される（
not opened; default kept） - 計画に書いたファイルや行が実在するかを、機械が確かめる（
pack.mjsの lint）
長い計画書を「読んで承認する」形だと、読み飛ばしが起きても誰にも分かりません。html-plan は計画を「答える」形に変えることで、その抜けを目に見えるようにしています。社内でスキルやプラグインを配布して開発の進め方をそろえたい場合は、Skills と hooks をプラグインで配る仕組みの記事もあわせてご覧ください。
参考資料
- Thariq（X）：html-plan の紹介投稿（2026 年 10 月 6 日）
- Anthropic：claude-plugins-community（コミュニティ用プラグインマーケットプレイス）
- html-plan 1.0.0 同梱ドキュメント：
README.md、skills/html-plan/SKILL.md、skills/html-plan/examples/scheduled-send.html（作者 Thariq Shihipar、MIT ライセンス。本記事の画面写真は同梱サンプルを手元で組み立てて撮影したもの）