Claude CodeやCodexに「HTMLで出して」と頼むと、それなりのページは返ってきます。ただ、ワイヤーフレームを頼んだのに完成品みたいなカードが並んだり、図を頼んだのに文章の隣に小さなSVGが添えられるだけだったり、という取りこぼしも起きます。plannotator/effective-html は、その「どの粒度で出すか」をスキル側に持たせて分業させるスキル集です。2026年8月25日時点でGitHubスター2,062、ライセンスはMIT、収録スキルは6本です。

公式READMEが掲げるデモ。html-diagram が出した単一HTMLのアーキテクチャ図で、上部のピル（Everything / Create / Live edit / Agent edit / Public read / Login / HTML render）を押すと関係ない要素が沈み、該当経路だけが赤い破線で浮かび上がる。出典: plannotator/effective-html README（30.5秒・音声なし）

Claude Code本体の設定やHooks・CLAUDE.mdまで含めた全体像は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてあります。本稿はその拡張エコシステム側、「HTMLを成果物として出させる」部分だけを深掘りします。

30秒でわかる effective-html
・Claude Code / Codex / Cursor 等に入れるHTML成果物スキル6本（MIT・★2,062・最終更新 2026-08-03）。ワイヤーフレーム／モックアップ／動くプロトタイプ／計画書／図を、ビルド不要の単一HTMLで出させる
・名前を呼ばずに起動するのは6本中2本だけ。同梱の agents/openai.yaml を全数確認した結果、html と design-artifact のみ allow_implicit_invocation: true
・ワイヤーフレームはわざと未完成のまま出す。グレースケール固定・装飾禁止で、構造の違う2〜3方向を1ファイルに詰めて比較させる
・常時ロードされるのはdescription 6本ぶんの2,449バイトのみ。全部展開しても46,457バイトで、19.0倍の段階開示になっている
・design-artifact はAnthropic公式スキルの移植ではない。上流とされた web-artifacts-builder（3,087バイト）と特徴的フレーズ10個で逐語一致0件

effective-htmlとは｜Claude Code・Codexに入るHTMLスキル集6本の正体

このスキル集が解こうとしているのは、「エージェントにHTMLを書かせること」そのものではありません。エージェントは頼めばHTMLを書きます。問題はどの完成度で止めるかで、そこが毎回ブレることです。構造を議論したいのに配色まで決まったページが来ると、レビューの論点が「この青でいいのか」にすり替わります。逆に、動作を確かめたいのに静止画のようなモックアップが来ると、押せないボタンの前で会話が止まります。

effective-html はこのブレを、スキルの分割そのもので抑えにいきます。6本それぞれが「どのレビュー質問を持ち主とするか」を宣言していて、html がその振り分け役を担います。

スキル 持ち主となるレビュー質問 SKILL.md サイズ
html どれに振るべきか。該当が無い場合のレポート・解説・LP・ツール 6,548 B
design-artifact 配色・書体・構図・テーマをどう決めるか（見た目の方向づけ） 10,948 B
html-wireframe 画面に何を載せ、どういう順で並べ、どう遷移させるか 4,859 B
html-prototype 実際に触ったとき、入力・状態変化・失敗復帰はどう振る舞うか 6,055 B
html-plan 元資料の約束事を保ったまま、順序・担当・依存をどう見せるか 2,456 B
html-diagram 関係・順序・トポロジ・状態のどれを、どの記法で描くか 2,709 B

読者の関心に引きつけて言い換えると、こうなります。

①結局なにができるのか。 ビルド手順もCDNも要らない.htmlファイルを1枚出させられます。ブラウザで開けばそのまま動き、Slackに投げてもGitHubに置いても再現します。

②なにを解決するのか。 「粒度がブレる問題」です。ワイヤーフレームを頼めば意図的に粗い成果物が返り、プロトタイプを頼めば読み込み中・エラー・成功・無効化まで含んだ動く画面が返ります。

③なにを代替できるのか。 初期段階の Figma / パワポ / 手書きの構造検討と、README に貼るためだけに描いていた図です。逆に、本番のデザインシステム構築やコンポーネント実装は代替しません。SKILL.md 自身が「独立HTMLファイルが成果物でない通常のアプリ実装には使うな」と書いています。

補助線として、そもそも「なぜMarkdownでなくHTMLなのか」という議論は Claude CodeはなぜMarkdownでなくHTMLを出力すべきか｜情報密度と共有性の優位を9ユースケースで解説 で扱っています。effective-html の README はまさにその記事の元になった Thariq Shihipar 氏のエッセイを着想元として明記しており、本稿はその発想を実際のスキルとして固めたらどうなったか、という続きにあたります。

なお README は導入について慎重な書き方をしています。「このリポジトリはインストールしなくても使える。まず参照資料として、二次的にインストール可能なスキル集として扱ってほしい」。スキル集としては珍しい立場表明で、実際 SKILL.md はどれも人間が読める散文で書かれており、コピーして自前のCLAUDE.mdに溶かす使い方も成り立ちます。

6スキルのルーティング設計｜名前を呼ばずに起動するのは2本だけ

分業させると必ず出てくるのが「結局どれが動くのか」という問題です。effective-html はここを二段構えにしています。

flowchart TD U["ユーザーの依頼"] --> R{"html スキル
唯一のルーター"} subgraph S["成果物を作る5つの経路（いずれも単一HTML・ビルド不要）"] W["html-wireframe
低忠実度・2〜3方向"] P["html-prototype
モックアップ / プロトタイプ"] L["html-plan
元の約束事を保持"] D["html-diagram
記法から選ぶ"] H["html のまま
レポート・解説・LP・ツール"] end R -->|"構造・導線が未確定"| W R -->|"見た目 or 挙動を検証"| P R -->|"計画・ロードマップ"| L R -->|"関係・順序・状態"| D R -->|"該当なし"| H DA["design-artifact
配色・書体・構図
置き換えず合成する"] -.->|"見た目の方向が未確定なら"| S

点線が示すとおり、design-artifact は置き換えではなく合成です。html の SKILL.md は「creative direction を供給するのであって、忠実度・構造・挙動を持つ専門スキルを置き換えるものではない」と明示しています。そして各専門スキルの側も「design-artifact を読んでよいが、この低忠実度契約のほうが優先される」と書いており、方向づけがレビュー用途を侵食しないようになっています。

ここで実務上いちばん効いてくるのが、どのスキルが「名前を呼ばれなくても」動くかです。スキルはリポジトリに置いた瞬間から description が常時読まれるため、意図しない発火はコンテキストと成果物の両方を汚します。この点は Claude Skills の基本設計そのものなので、仕組みから確認したい場合は Claude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説 を先に読むと早いです。

effective-html は各スキルに agents/openai.yaml を同梱しており、そこに機械可読のポリシーが書かれています。実際にインストールして全6本を確認しました。

effective-html の6スキルの allow_implicit_invocation 実測。html と design-artifact のみ true
インストールした .agents/skills/<name>/agents/openai.yaml の policy.allow_implicit_invocation を全6本で確認した結果

html が true なのはルーターなので設計どおりです。注目すべきは design-artifact で、こちらも true でした。他の4本は description に「Do not activate independently from a general request（一般的な依頼から独立して発火するな）」という一文を持っていますが、design-artifact にはその一文がありません。description は「Use when creating or restyling any visual HTML deliverable（あらゆる視覚的HTML成果物を作る・作り直すとき）」と広く取っており、実質的に2本目の暗黙起動スキルとして機能します。

導入時に効く判断材料。エージェントに勝手に見た目を決めてほしくない運用（自社デザインシステムがある、あるいは既存HTMLを触られたくない）なら、--skill で design-artifact を外して入れるのが確実です。npx skills add plannotator/effective-html --skill html-wireframe のように個別指定ができます。

この「起動の止め方」は、リポジトリの歴史のなかで一度作り替えられています。

・2026-06-09（初版）——html-diagram と html-plan の frontmatter に disable-model-invocation: true を追加。Claude Code が解釈する機械可読のキーで、暗黙起動を止めていた
・2026-07-30（PR #9）——html-wireframe と html-prototype を追加した同じPRで、この disable-model-invocation キーを削除。代わりに description の散文（「Do not activate independently」）へ置き換えた
・現在——6本すべての frontmatter は name と description の2キーのみ。機械可読のポリシーは Codex 側の agents/openai.yaml にだけ残っている

つまり Codex では設定ファイルが起動を止めますが、Claude Code 側で暗黙起動を止めているのは description に書かれた一文だけです。モデルがその一文をどう読むかに委ねられている、という理解で運用するのが安全です。

もう一点、リポジトリ内の記述と現物にズレがあります。公式サンプルに同梱された検証記録 validation.md は「全5スキルがプラットフォームのバリデータを通過」「暗黙起動を許すのは html のみ」と書いていますが、この記録の日付は2026年7月29日・最終更新は7月30日で、design-artifact が追加されたのは8月2日です。実際に npx skills add ... --list を叩くと Found 6 skills と返ります。検証記録のほうが1本ぶん古い、というだけの話ですが、READMEの表と検証記録で本数が食い違って見えるので、現物を数えるのが確実です。

effective-htmlのインストールと使い方｜npx skills・Claude Code・Codexの3経路

導入経路は3つ用意されています。どれもリポジトリのREADMEに記載された公式手順です。

汎用のインストーラを使う場合（Claude Code / Cursor / Cline など横断）:

# 6本まとめて
npx skills add plannotator/effective-html

# 中身を見てから選ぶ
npx skills add plannotator/effective-html --list
npx skills add plannotator/effective-html --skill html-wireframe

Claude Code のプラグインとして入れる場合:

/plugin marketplace add plannotator/effective-html
/plugin install plannotator-effective-html@effective-html

Codex のプラグインとして入れる場合:

codex plugin marketplace add plannotator/effective-html
codex plugin add plannotator-effective-html@effective-html

実際に空のディレクトリで npx skills add plannotator/effective-html を実行し、何がどこに置かれるかを確認しました。結果は次のとおりです。

・Found 6 skills と表示され、6本すべてが導入対象になる
・実体は ./.agents/skills/<スキル名>/ に配置される。インストーラは「universal: Cursor, Amp, Antigravity, Antigravity CLI, Cline +12 more」と表示し、17種のエージェント共通の場所として扱う
・Claude Code 向けには ./.claude/skills/<スキル名> から ../../.agents/skills/<スキル名> へのシンボリックリンクが張られる（実体の二重化はしない）
・置かれたのは18ファイル・合計49,744バイト。内訳は SKILL.md 6本、Codex用 agents/openai.yaml 6本、html 配下の references/ 5本、skills-lock.json 1本
・skills-lock.json にはスキルごとに source / skillPath / computedHash（SHA-256）が記録される。更新の検知やレビューに使える
・完了時に「Review skills before use; they run with full agent permissions.（使う前にレビューを。スキルはエージェントの全権限で動く）」と警告が出る

最後の警告は形式的な文言ですが、実態としても妥当です。SKILL.md はエージェントへの指示文そのものなので、入れる前に6本ぶん、合計30,884バイトの散文に目を通しておく価値はあります。散文として読める分量なので、通読は現実的です。

html-wireframeの使い方｜ワイヤーフレームを「未完成のまま」出す設計

html-wireframe は、このスキル集のなかでもっとも「AIっぽい出力」に逆らっています。SKILL.md の要求は明快で、完成品に見えてはいけない。

・抑えたグレースケール、システムフォント、素の枠線、単純なブロックのみ
・ブランドカラー・グラデーション・影・イラスト・装飾画像・作り込んだコンポーネントは禁止
・角丸と余白は控えめに。階層を判断できる程度の秩序は要るが、ブランドレビューを誘発するほど磨いてはいけない
・画像やリッチメディアは、構造判断に影響しない限りラベル付きのプレースホルダで表す
・ただし「低忠実度は匿名のボックスやダミーテキストを使う口実ではない」。文言が配置に影響するなら実際のラベルを使う

そして構造が未確定なら、意味のある違いを持つ2〜3方向を作れと指示します。色を変えただけ、カードを並べ替えただけは別方向として認めない、とまで書いてあります。変えるべきは、ナビゲーションのモデル、グルーピングと順序、主要アクションの位置、情報密度、俯瞰型かステップ型か、デスクトップからモバイルへの折り返し方です。

公式サンプル（リリース可否を判断する画面）で、それが実際にどう出るかを見られます。

html-wireframe が1つのHTMLに出した3方向のワイヤーフレーム比較
公式サンプル examples/release-readiness/wireframe.html（30,040バイト・1ファイル）に入っている3方向。画面下部のセレクタで切り替える。出典: plannotator/effective-html examples

3つは同じ内容・同じタスクを保ったまま、構造だけが違います。「Decision first」は判定と次アクションを常時見せ、根拠は1スクロール先に置く。「Evidence ledger」は根拠を表に落として比較と監査可能性を優先する。「Guided gate」は左に6ステップの縦ナビを置き、1件ずつ確認させる。どれが正しいかは、そのプロダクトが誰の何を守りたいかで変わります。ワイヤーフレームの役目は、その議論を色の話に逃がさないことです。

日本語で「ワイヤーフレーム 作り方」を調べると Figma やデザインツールの操作手順が並びますが、このスキルが答えているのは別の問いです。ツールの操作ではなく「構造の選択肢を並べて捨てる」工程を、エージェントに肩代わりさせるという発想で、成果物はレビュー用の使い捨てHTMLです。きれいな画面が欲しい場合は次の html-prototype に進みます。

3方向は1つのHTMLに入っていて、キーボード操作できるセレクタで切り替えます。ファイルが増えないので、Slackに1枚投げれば議論が始められます。

html-prototypeで検証できること｜公式サンプルの状態遷移を読む

html-prototype は2つのモードを持ちます。モックアップは視覚的な階層・レイアウト・タイポグラフィ・配色が論点のときに使う、ほぼ静的で磨かれた成果物。プロトタイプはナビゲーション・入力・状態変化・フィードバック・復帰・遷移が論点のときに使う、動く成果物です。SKILL.md は「html-mockup という別スキルを作るな。モックアップはこのスキル内の忠実度モードだ」と釘を刺しています。

html-prototype が生成したリリース可否判断のプロトタイプ画面
公式サンプル examples/release-readiness/prototype.html（52,809バイト・1ファイル）。スクリーンショットは4項目すべて通過した ready 状態。出典: plannotator/effective-html examples

このスキルの実力が読み取れるのは、同梱の states.md です。プロトタイプが「押せるボタンが並んだ画像」で終わらないために、どの状態まで面倒を見るかが表になっています。

状態 引き金 見えること 取れるアクション
Blocked iOSスモークテストが失敗 失敗した検査とリリース判定が、なぜ止まっているかを示す 再実行を記録する
Saving 再実行を送信 フォームとトリガーが無効化され、進行がアナウンスされる 待つ
Save error 疑似エビデンスサービスが更新を拒否 入力値を保ったまま失敗理由を説明し、再試行を提示 再試行 / キャンセル
Ready 4項目すべて通過 サマリが「4 of 4」に変わり、リリース操作が有効化 本番リリースを要求
Release requested 有効化されたリリース操作を選択 実システムが引き取る境界を説明する 説明を閉じる
Empty notes レビュアーがノートを全消去 ノート欄が「まだ何も無い」ことを説明する ノートを追加

最後から2番目の「Release requested」が、このスキルの設計思想をよく表しています。押せるが、実際にはデプロイしない。代わりに「ここから先は本物のシステムが引き取る」という境界を明示する。SKILL.md も「死んだボタンは消せ。実システムに属するアクションなら、完了したふりをせず境界を説明しろ」と書いています。

自己完結性についても実測しました。公式サンプル2ファイルを解析した結果は次のとおりです。

・外部ホストへの src / href 参照: 0件（プロトタイプ・ワイヤーフレームとも）
・<script src> 0件、<link rel="stylesheet"> 0件、@import 0件、<img> 0件
・fetch() / XMLHttpRequest / WebSocket / sendBeacon: 0件
・インライン <style> 1ブロック、インライン <script> 1ブロック
・@font-face は0件。書体は Georgia・Arial・ui-monospace などOS常駐のスタックのみで指定されている

最後の点は、design-artifact が「Google Fonts等のCDNからWebフォントをリンクするな。使うなら @font-face のデータURIで埋め込め」と指示していることと符合します。公式サンプルはデータURI埋め込みすら使わず、OSにある書体だけで「2つ以上の役割を持つ書体」の要求を満たしていました。結果として、ネットワークを一切踏まないファイルになっています。ダイアログは <dialog> 要素で実装され、showModal() と .close() を使っているため、role="dialog" を手書きしなくてもフォーカス閉じ込めと Escape がブラウザ側で担保されます。SKILL.md の「適切なセマンティクスを持つならネイティブ要素を使え」がそのまま出ている箇所です。

design-artifactの出自と「AIっぽい見た目」回避リスト｜公式スキルとの実測比較

6本のうち最大の SKILL.md（10,948バイト・本体の34%）を持つのが design-artifact です。役割は「何を作るか」ではなく「どう感じさせるか」——視覚的なレジスタ、配色、書体、構図、テーマ、装飾の量を決めます。冒頭は「幅の広さで評判の、ブティック型エージェンシーのクリエイティブディレクターの視点を取れ。すべての仕事に固有のビジュアルアイデンティティを与えよ」という指示から始まります。

このスキルが具体的に何を禁じているかを見ると、性格がわかります。「今のAI出力が繰り返し着ている衣装」として9項目が列挙されています。

・暖色のクリーム（#F4F1EA）にセリフ体のディスプレイとテラコッタのアクセント
・ほぼ黒の地に、アシッドグリーンかバーミリオンを1発だけ差す
・細い罫線の新聞風レイアウトに、詰まったカラム
・白地に浮かぶ紫→青のグラデーションのヒーロー
・無難さで選ばれた Inter または Space Grotesk
・セクションの目印を絵文字に肩代わりさせる
・全部中央揃え
・rounded-lg をあらゆる場所に撒く
・アクセントバーやレールを着けた角丸カード

「AI slop を拒む」という発想自体は他のスキルにもあります。同系統の考え方を持つ Hallmark デザインスキル解説｜AI slopを拒みClaude Code・Cursorで使う と比べると、Hallmark が特定の美意識を提示するのに対し、design-artifact は「使い回せる見た目を押し付けないこと」自体を目標に据えている点が違います。SKILL.md の冒頭にも「一貫した見た目ではなく、一貫した配慮が基準だ。過去の実行から house palette や type stack を再生産するな」とあります。

出自については、リポジトリの記述が短期間で二転三転しています。実測して整理すると次のようになります。

design-artifact と Anthropic 公式 web-artifacts-builder の実測比較
両者の SKILL.md を取得して比較した結果。バイト数はUTF-8実測

・2026-08-03（コミット 1913a32a）——ドキュメントに「Anthropic公式の web-artifacts-builder から派生した」と追記され、リンクも張られた
・2026-08-03（同日・コミット 89ed09a6）——「Claude Code に内蔵されたアーティファクト設計ガイダンスに着想を得た。Anthropic はその内部ガイダンスを単体スキルとして公開していないので、リンクできる上流の SKILL.md は存在しない」へ書き換え。web-artifacts-builder への言及とリンクは削除された
・現行版——該当ページから Anthropic への言及自体が無くなっている

ここは読み違えやすいので補足します。訂正後の「リンクできる上流の SKILL.md は存在しない」が指しているのは、Claude Code に内蔵されている（＝単体スキルとして公開されていない）ガイダンスのほうです。訂正前に挙げられていた web-artifacts-builder のことではありません。つまりこの書き換えは、誤りの訂正というより着想元の申告そのものを差し替えたもの、と読むのが正確です。

念のため、訂正前の主張がリンクしていたファイルの現存だけは確認しました。anthropics/skills の skills/web-artifacts-builder/SKILL.md は現在も HTTP 200 で取得できます。ただし中身は React 18 + TypeScript + Vite + Parcel + Tailwind CSS + shadcn/ui を使う claude.ai アーティファクトのビルド手順が主体で、3,087バイト。デザインに関する記述は「AI slop を避けるため、過度な中央揃え・紫のグラデーション・一律の角丸・Interフォントを避けよ」という1文だけです。

design-artifact（10,948バイト）と特徴的なフレーズ10個（”creative director at a boutique agency”、”telltale AI aesthetic”、”Copy is a material”、”tabular-nums”、”text-wrap: balance” など）を照合すると、逐語一致は0件でした。重なるのは禁止項目のうち4つ（中央揃え・紫グラデーション・一律の角丸・Inter）という発想レベルだけで、design-artifact 側は残る5項目と、配色・書体・余白・テーマ・カスケード・コピーライティングの作法を独自に足しています。

結論として、design-artifact は Anthropic 公式スキルの移植でも派生でもなく、Plannotator が書き下ろした別物と理解するのが実態に合います。ライセンスもMITでPlannotator管理です。

入れる前に知っておくこと。design-artifact の SKILL.md は末尾で「成果物の完成後、公開ページとして共有するかユーザーに尋ねろ」と指示し、同意が得られた場合に限り tot CLI（npm install -g @plannotator/tot／npm実在・MIT・v0.1.2）で公開してURLを返せ、と書いています。同意なしの公開・インストールは禁止する文言も併記されていますが、エージェントが自社の未公開UIについて「共有しますか？」と聞いてくる可能性は把握しておく方がよいでしょう。同様に README は同じ組織の backnotprop/plannotator（★7,988・Apache-2.0）と plannotator/tot（★60・MIT）へのバナーを掲げています。

導入前チェックと類似スキル集との違い｜コンテキスト消費量の実測

スキル集を評価するとき、機能一覧の次に効いてくるのが「常時どれだけコンテキストを食うか」です。SKILL.md はトリガーされたときに本文が読まれますが、description は常に読まれます。全6本を実測しました。

effective-html のコンテキスト消費量実測。常時2,449バイト、全展開で46,457バイト
SKILL.md の frontmatter を分離し、description と本体をUTF-8バイト数で分けて計測した結果

常時ロードされるのは description 6本ぶんの2,449バイトだけです。起動して初めて SKILL.md 本体（6本合計30,884バイト）が読まれ、さらに html スキルが必要と判断したときに references/ 配下の5本（合計13,124バイト）が追加で読まれます。全部展開すると46,457バイトで、常時ロード分の19.0倍。段階開示が実際に効いている構造です。

1本あたりで見ると、description に対する本体の倍率は html-plan の6.3倍から design-artifact の31.4倍まで開きがあります。design-artifact は337バイトの description で10,567バイトの本体を引き当てる設計で、暗黙起動が true であることと合わせると、意図せず発火したときのコンテキスト影響がもっとも大きい1本ということになります。

同系統のスキル集と比べると、位置づけがはっきりします。

  effective-html designer-skills Hallmark Archify
主眼 HTML成果物の粒度の分業 デザイン知識の網羅 AI slopを拒む美意識 技術図の生成
収録数 6本 237スキル 1スキル 1スキル
成果物 単一HTML（ワイヤー/試作/計画/図） 各スキル依存 HTML/UI 自己完結HTMLの技術図
暗黙起動 6本中2本のみ true（実測） — — —
ライセンス MIT — — —

数の多さで勝負していないのが effective-html の特徴です。6本しかない代わりに、それぞれが「どのレビュー質問を持つか」まで宣言し、html がその振り分けを担う。スキル集というより小さなワークフローの束と捉えたほうが実態に近いでしょう。

最後に、導入前に確認しておきたい点をまとめます。

・入れるスキルを選べる——--skill <name> で個別導入できる。見た目を勝手に決められたくないなら design-artifact を外す
・暗黙起動の止め方が処理系で違う——Codex は agents/openai.yaml の設定で止まるが、Claude Code 側は description の一文に依存する（disable-model-invocation キーは2026-07-30に削除済み）
・同梱の検証記録は1本ぶん古い——validation.md の「5スキル」は design-artifact 追加前の記録。現物は6本
・最終更新は2026-08-03——スキル本体は約3週間動いていない。README・サイト側の更新は継続している
・成果物はレビュー用の使い捨て——本番のコンポーネント実装は範囲外だと SKILL.md 自身が明示している
・インストール不要でも成立する——READMEの立場どおり、6本のSKILL.mdを読んで自分のCLAUDE.mdに要点を書き写す使い方も現実的（合計30,884バイトの散文）

最初の1本を試すなら。npx skills add plannotator/effective-html --skill html-wireframe だけを入れて、手元の企画に対して「この画面のワイヤーフレームを3方向で」と頼むのが、費用対効果がいちばん高い入り口です。出てきたグレースケールのHTMLをそのままレビューに回して、議論が「配色」ではなく「構造」から始まったかどうかを見れば、このスキル集が自分のチームに効くかを1回で判断できます。

参照ソース