はじめに
万能なビジュアルボタンは存在しない
ClaudeにHTMLページの作成を依頼するとき、品質は「もっときれいに」という一言ではなく、呼び出されるスキルで決まる。ClaudeKitはビジュアル化を一つの万能コマンドにまとめていない。それぞれ特定の役割を持つ小さなスキルに分割されている。最もよくある混同は、すべてを同じグループとして扱うことだ。その結果、アーキテクチャドキュメントがランディングページのように見えたり、プロダクトUIが社内ドキュメントのようになったりする。
今回の内容では、思考オーケストレーションとインターフェース実行という二つの軸を中心にポジショニングマップを使い、実際の問題に適用する：プランファイル全体をビジュアル化するケースだ。パート03では、経費承認アプリのサンプルプランが実際に動作する。スクリーンショットはそのまま証拠として保持され、プロンプトはコピー&ペーストして再利用できる。
例を正しく読むための注記：ClaudeKitでは、preview・frontend-design・stitch・tech-graph・show-offはすべて自然言語で呼び出すスキル（prompt-driven）であり、手動で入力するフラグ付きのCLIコマンドではない。
記事でフラグに言及する場合、それはスキルが内部で自動実行するスクリプトのフラグであり、スラッシュコマンドと一緒に入力するパラメーターではない。例外はpreviewの--explain・--diagram・--slides・--htmlなどの生成フラグで、これらはこのスキルの呼び出し構文の一部だ。
もう一点、第 02 部で詳しく扱う：安定版 engineer@v2.20.0 から --html は preview 専用ではなくなり、/ck:brainstorm と /ck:plan の両方が受け付ける。
01
ポジショニングマップ：/ck:preview vs /ck:frontend-design
この二つのスキルは混同されやすい。どちらも美しいHTMLを出力でき、タイポグラフィや色にこだわり、テンプレート回避のルールを持つ。違いはアウトプットの契約にある：previewはチームが理解・照合・意思決定するためのドキュメントを作成し、frontend-designはユーザーがプロダクトのように操作できるUIを作成する。
/ck:preview：ビジュアルオーケストレーション
ファイル・ディレクトリをプレビューする必要があるとき、または/ck:planや/ck:debugの直後に説明ドキュメントを作成するときに使う。topic・gitコンテキスト・explanation・slides・diagram・dashboard reviewの中継地点となる。
/ck:frontend-design：インターフェース実行
エンドユーザー向けの完成したUIを作成することが目標のときに使う。デザインソースがあるとき（スクリーンショット・サンプルフローの動画・詳細な説明）に最も効果を発揮する。
/ck:preview --html --explain "ブログの i18n パイプライン：HTML ソースから JSON を経て 4 つの locale ルートへ"
/ck:preview --html --slides "Astro + Turborepo モノレポのアーキテクチャ"
/ck:preview --diff HEAD~3previewのスタイル哲学は一貫性だ。事前に定義されたプリセットリストからスタイルを選択し、生成のたびにローテーションすることでフォントとパレットの繰り返しを避ける。スクロール可能なHTMLページには6つのプリセットがある：Blueprint・Editorial・Paper-Ink・Terminal Mono・Swiss Clean・Warm Signal。スライドデッキには別の4つのプリセットがある：Midnight Editorial・Warm Signal・Terminal Mono・Swiss Clean。固定ルールとして：生成するすべてのHTMLページには<body>の最初の子要素としてlight/darkテーマトグルが必要だ。トグルがなければ未完成とみなされる。
/ck:frontend-design このスクリーンショットの UI を HTML/Tailwind で再現 [+ 画像添付]
/ck:frontend-design 注文管理ダッシュボード、高密度のデータ行。DESIGN_VARIANCE=4, VISUAL_DENSITY=8frontend-designのスタイル哲学は逆方向を向く：差別化だ。デフォルトはDESIGN_VARIANCE=8で、二つのデザインが同じにならないことを目標とする。プロンプトで直接宣言する三つのDesign Dialsで制御できる。
| Dial | デフォルト | 低 | 高 |
|---|---|---|---|
DESIGN_VARIANCE |
8 | 対称、センタリング | 非対称、masonry、意図的な余白 |
MOTION_INTENSITY |
6 | hover/activeのみ | スクロール時に表示されるエフェクト、springアニメーション |
VISUAL_DENSITY |
4 | 広いWhitespace、クリーン | 小さいPadding、monoスペース数値、コックピット風 |
クイックルーティング表
| Input | 呼び出し | 理由 |
|---|---|---|
| チームに説明が必要なtopic | preview --html --explain "<topic>" |
アウトプットはMermaid付きの閲覧用ドキュメント |
| プレゼンが必要なtopic | preview --html --slides "<topic>" |
viewport-fitのスライドエンジン |
| git range / PR | preview --diff <ref> |
ダッシュボードレビュー、実際のgitデータを読む |
| コードと照合が必要なプラン | preview --plan-review <plan> |
プランと実際のコードベースを比較 |
| UIのスクリーンショット/動画 | frontend-design + 添付 |
レプリケートのワークフロー |
| UIの説明 + Design Dials | frontend-design |
プロダクションUIの構築 |
この二つのスキルは相互排他ではない。同じ開発サイクルの異なる段階に位置する：previewは思考部分を検証する（プランがコードベースと一致しているか、フローが明確か、diffのblast radiusはどの程度か）。frontend-designはプロダクトのaesthetic部分を構築・検証する。
02
サテライトスキル体系
パート01の二つの主軸は単独で存在しない。その周りには三つの能力グループに分けられた補助スキル群がある。このグループを把握することで、正しいスキルをより精度高く呼び出せるようになり、何かが動かないときのデバッグも容易になる。
/ck:ui-ux-pro-maxはレイアウト・タイポグラフィ・スペーシング・パレット・UXガイドラインを定義する。これはfrontend-designの必須の基盤だ。
/ck:tech-graphはpublish-grade品質のSVG/PNGを出力し、/ck:mermaidjs-v11はmarkdown図のsyntaxを正確に保つ。
/ck:markdown-novel-viewerは閲覧体験を担い、/ck:show-offはbrief・content・HTML・スクリーンショット・ショーケースをまとめてパッケージングする。
/ck:brainstorm と /ck:plan が --html を受け付けるようになり、markdown ファイルだけでなくブラウザで直接開ける HTML ページも出力する。
グループ1：デザインインテリジェンス
/ck:ui-ux-pro-maxはdesign intelligence engineだ。frontend-designの必須の基盤であり、すべてのワークフローがまずこれを起動する。preview --slidesにも推奨される。内部では大規模CSVに対するBM25検索エンジンが動いており、多数のスタイル・数百のカラーパレット・フォントペアリング・プロダクトタイプ・UXガイドライン・チャートタイプが含まれる。コード生成前に、レイアウト・タイポグラフィ・スペーシングなどのデザイントークン体系を定義する。
覚えておくべき優先ルール：ui-ux-pro-maxの推奨がanti-slopルールと衝突する場合（InterフォントやパープルパレットのサジェストなどM）、ユーザーが明示的に要求しない限りanti-slopルールが勝つ。
グループ2：アーキテクチャ図化
/ck:tech-graphはpublish品質のdiagramを出力するために使う。このスキルは記事・スライド・引き渡しドキュメントに挿入できる鮮明なSVGとPNGを生成する。8つのスタイルをサポートする：Flat Icon・Dark Terminal・Blueprint・Notion Clean・Glassmorphism・Claude Official・OpenAI Official・Dark Luxury。呼び出し方はシステムと希望スタイルを自然言語で説明するだけだ。スキルは内部でgenerate-diagram.shスクリプトを自動実行してSVGを検証しPNGをエクスポートする。
/ck:mermaidjs-v11はテキスト形式の図のsyntax validatorだ。社内markdownに直接埋め込むflowchart・sequence・state diagramを素早く構築するのに適しており、Mermaid v11の正確なsyntaxを保証する。previewはMermaidを生成するたびにこのスキルを呼び出す。純粋なreferenceスキルなので、単独で使用することもできる。
三つのdiagramスキルの境界はかなり明確だ：diagramが別の場所へ持ち出す独立した画像ファイルならtech-graphを使う；diagramがmarkdownに埋め込まれるならmermaidjs-v11を使う；diagramがHTML説明ページの内部に存在するならpreview --diagramを使う。
グループ3：プレゼンテーションと体験
/ck:markdown-novel-viewerはpreview view modeの背後にあるサーバーだ。markdownを専用の閲覧ページにレンダリングする：セリフ体、温かみのある背景、制限された横幅で、長文ドキュメントに適している。見落とされやすいポイントは、Mermaidをページ内でレンダリングできることだ。flowchart・sequence・gantt・mindmapも含み、theme-aware且つfull-width切り替えが可能だ。
/ck:show-offはbriefからsocial assetまでのend-to-endパイプラインだ。よく誤解されるポイント：show-offはリポジトリ内の既存アセットを自動スキャンしてギャラリーにまとめるわけではない。self-containedなミッションを実行する：research/fact-check、バイリンガルcontent執筆、frontend-designを起動してHTMLを構築、Puppeteerで複数の比率のスクリーンショットを撮影、そしてショーケースを出力する。frontend-designはその中の一ステップに過ぎない。
グループ 4：Brainstorm と plan を HTML 出力
最近まで --html はほぼ preview 専用だった。安定版 engineer@v2.20.0（ClaudeKit CLI 4.5.0 に同梱）から、brainstorm（アイデアや選択肢を検討する skill）と plan（実装計画を立てる skill）も同じフラグを受け付ける。この 2 つは以前は markdown テキストを返すだけだったが、今ではブラウザでそのまま読んで共有できる HTML ページも出力できる。
/ck:brainstorm --html はまず markdown を書き、その後に雑誌風の HTML ページを加える。決定と根拠は同じだが、最も重要なトレードオフ・前提・最終的な推奨をより分かりやすく示す。HTML ファイルはそのまま開ける独立したページで、議論に参加しなかった人に送るのに便利だ。
/ck:plan --html はさらに一歩進む。主な成果物は plan.html。各 phase をクリックして開け、各ステップの詳細をポップアップで見られる対話的な plan ページで、オプションで技術イラストも付く。本記事にとって注目すべき点：HTML を作る前に /ck:frontend-design を呼び出すため、ui-ux-pro-max の design intelligence プロセスも通る。HTML ページは plan が red-team レビューと validation チェックを通過した後にのみ生成されるので、最終的な plan を反映する。
/ck:brainstorm --html "ブログの i18n 同期方式を選ぶ：build-time inject
vs runtime fetch vs content collection"
/ck:plan --html "ブログ全体に 5 つ目の locale（ko）を追加、i18n JSON から既存の 4 ルートまで"実務上のポイント：brainstorm と plan は preview と競合しない。preview は topic や git context から説明用ドキュメントを素早く作る手段のままだ。一方、brainstorm と plan の --html は、そのセッションが生み出した brainstorm そのもの、または plan そのものに HTML ページを付けるのであって、別個の説明資料ではない。
03
ケーススタディ：プランファイル全体をビジュアル化する
課題：プランファイルがある。目標はすべてをビジュアル化すること：システムアーキテクチャ・イラストUIインターフェース・運用フロー。単一のスキルでは完全に対応できない。なぜなら課題が説明・図化と実際のUIモックアップという二つの異なる能力グループにまたがるからだ。
ケーススタディで使用するプランは社内経費承認アプリだ：6エンティティ（Employee・ExpenseClaim・LineItem・Approval・Payment・AuditLog）、5状態のstate machine、5つのUI surface。エンティティとアクションが十分に明確で、スキルがworkflow・アーキテクチャ・UIを推論できる。
正しく使うために一点訂正：preview --explainとpreview --diagramはtopic文字列を受け取るのであって、プランファイルを自動パースするわけではない。正しい構文はフラグをtopicの前に置くことだ：/ck:preview --diagram "<説明>"であり、/ck:preview <path> --diagramではない。
方案1：Fast-track（2コマンド）
アイデアの迅速な検証が必要なとき、ドラフト版を許容する場合向け。
/ck:preview --html --explain "経費承認アプリ：SPA から PostgreSQL まで 5 層、
ステートマシン draft→submitted→under_review→approved→paid、5 つの画面"
/ck:stitch "plan 内の workflow から経費承認アプリの UI 画面を推論し、
生成する前に確認用の画面リストを提示して"- コマンド1はself-containedなHTMLファイルを生成する：overview・ASCIIクイックビュー・Mermaidアーキテクチャフロー・キーコンセプト。すべて1ページに収まり、テーマトグル付き。
- コマンド2は
stitchがプランの機能ロジックから画面構造を自動推論する。「genの前に画面リストを列挙する」というフレーズが最も重要なチェックポイントだ。
方案2：Comprehensive flow（4ステップ）
顧客向けデザインドキュメントまたはプロジェクトドキュメントのセットを作成するための完全なプロセス。以下は各ステップの実際の実行結果だ。
architecture
approval queue
state machine
showcase
ステップ1：tech-graphでアーキテクチャ図を作成
/ck:tech-graph 経費承認アプリのアーキテクチャ図：5 層 Frontend（5 画面）→
API（ロールベース）→ Service（ClaimService が state machine・Approval・Payment・Audit を保持）
→ Data（PostgreSQL）+ Storage（receipts）。Blueprint スタイル。スキルはBlueprintプリセットに従ってSVGを描く：dot-gridの背景、mono、cyan accent。その後、検証してpublish-grade品質のPNGをエクスポートする。結果は5つの明確なレイヤー、ボックスをまたがないarrow routing、下部にstate machineのcallout、state machineを保持するClaimServiceが緑でハイライト、AuditServiceはオレンジ色になっている。
ステップ2：frontend-designで詳細なインターフェースを作成
/ck:frontend-design 経費承認アプリの Approval Queue 画面（デスクトップ、dev-tool スタイル）。
サイドバーナビ + マスタ詳細：左に承認待ち claim リスト、右に line item 詳細 + approve/reject
ボタン。ステータスで色分けしたバッジ。DESIGN_VARIANCE=4, VISUAL_DENSITY=8結果は重要なanti-slopルールを守っている：Inter/Robotoを避け、純粋な黒の代わりにoff-black tintedを使用し、accent goldは一色のみ、三列均等カードの代わりにmaster-detailレイアウト、$1,247.30のような自然な端数と多様な名前でよりリアルに見えるcopyを使用。under_review/submittedバッジはstate machineに従って色分けされている。
ステップ3：preview --html --slidesでワークフローウォークスルーを作成
/ck:preview --html --slides "expense claim のライフサイクル：employee が作成・提出 → manager が
承認 → accountant が支払い、state machine と 3 つの guardrail 付き"viewport-fitデッキはMidnight Editorialプリセットを使用：セリフ体、gold accent、dark navy。このスタイルはステップ1のBlueprintとまったく異なり、アウトプット間でaestheticを変えるルールを正しく守っている。デッキにはプログレスバー・ページ番号・テーマトグルがある。以下はdarkテーマのtitleスライドとlightテーマのstate machineスライドで、トグルが機能していることがわかる。
ステップ4：show-offで統合とプレゼンテーションを作成
/ck:show-off ショーケースページ "Expense Approval — ビジュアル資料一式"。アーキテクチャ図
（ステップ 1）、Approval Queue 画面（ステップ 2）、workflow スライド（ステップ 3）を
ナビアンカー付きの section にまとめ、サーバー不要でブラウザから直接開く。show-offは最終的な統合ステップだ。diagramとUI画面をself-containedなHTMLページにまとめる。このケーススタディでは、ファイルを一つ開くだけで動作するよう画像がbase64で埋め込まれている。ページにはナビゲーションアンカー・使用したスキルをリストアップするfooter・テーマトグルがある。ブラウザで直接開け、サーバー不要だ。
トークンコスト。4ステップのシーケンスはかなりのトークンを消費する。なぜなら各tech-graph/frontend-design/preview/show-offがそれぞれ別のアウトプット生成パスだからだ。方向性のレビューに十分なバージョンだけが必要な場合は、方案1に戻ることを検討しよう。
04
技術的な区別：/ck:frontend-design vs /ck:stitch
UI構築のステップ（ステップ2または上記のコマンド2）での決定ポイントは、デザインソースがすでにあるか、それともClaudeに自己推論させる必要があるかだ。
/ck:frontend-designは再現
デザインソースアセットがすでにある場合に使う：Figmaのデザイン・サンプルUIのスクリーンショット・特定のインタラクションフロー。スキルはソースを真実として忠実に従い、HTML/Tailwindで再現する。
/ck:stitchは推論
デザインサンプルがない場合に使う。スキルはワークフローの名詞と動詞に基づいて機能ロジックからレイアウトを推論し、UIのギャップを自動的に埋める。
| 状況 | スキル | 性質 |
|---|---|---|
| スクリーンショット/Figma/モックアップを参考にできる | frontend-design |
精確な再現 |
| ワークフローの説明のみ、UIは自己推論 | stitch |
推論と組み立て |
AIにインターフェースを自己推論させる際の重要な注意点3つ
- 生成前に画面リストを確定する。これを省略すると、AIがスコープ外の補助画面を自己生成しやすく、トークンを無駄にしてメインフローが希薄になる。
- Design Dialsを最初から宣言する。最初の呼び出しで
DESIGN_VARIANCE・VISUAL_DENSITY・MOTION_INTENSITYを明示的に設定し、画面間でaestheticがずれないようにする。 - anti-slop guardを維持する。デフォルトのRoboto/Interフォント・典型的な紫-青グラデーション・均等な三列カード・neon glow・「John Doe」・Latinプレースホルダーをブロックする。
両方に共通の注意事項：「John Doe」・丸い数字・クリシェなどの偽コピーはブロックできるが、実際のcopyは人間が書くか確認する必要がある。スキルはドメインコンテンツを自動的に作り上げることはできない。
05
準備とpitfalls
スキルを一連のチェーンに連結する前に、dependencyを事前に確認することを推奨する。スキルはすべてClaudeKit内にあるが、実行環境にはそれぞれ独自の部分がある：tech-graphはSVG/PNGエクスポートのバイナリ（rsvg-convert）が必要で、stitchは対応サービスのAPIキー/クォータが必要で、show-offはスクリーンショット撮影のためのPuppeteer実行環境が必要だ。一つの部品が欠けると予測困難なエラーが発生しやすい：画像がエクスポートされない、ジョブが途中で止まる、またはログが非常に一般的なエラーのみを示す。事前確認で後の時間を節約できる。
show-off/tech-graph/stitchにCLIコマンドのようにフラグを入力する。これらはprompt-drivenであり、フラグは内部スクリプトのものだ。show-offが既存アセットを自動スキャンすると思い込む。ミッションにアセットを提供する必要があり、スキルが自動的に見つけることはない。preview --diagram <path-to-plan>を呼び出す。topic文字列を受け取るのであってファイルを読むわけではない。フラグはtopicの前に置く。- 画面リストを確定せずに
stitchに自動生成させる。結果として余分な画面が生成されやすくトークンを消費する。 - スライドプリセット（4つ）とHTMLページプリセット（6つ）が異なることを忘れる。Blueprint/Paper-InkはスライドにはないD。
frontend-designを使って説明ドキュメントを作成する。アウトプットは通常、閲覧目的にはaestheticが重すぎる。
まとめ
アウトプットの目的で選ぶ
思考 → preview。
プロダクト → frontend-design。
独立ファイル → tech-graph。
markdown埋め込み → mermaidjs-v11。
HTMLページ内 → preview --diagram。
ある → frontend-design。
ない → stitch。
show-offはself-containedなパイプラインだ。
順番に組み合わせる：tech-graph + frontend-design/stitch + preview --slides + show-off。
内部説明 → preview/preview --slides。
UIレビュー → frontend-design/stitch。
他の人に渡す → show-off。
brainstorm → brainstorm --html。
plan → plan --html。
ClaudeKitのビジュアル化領域に万能ボタンはないが、役割の観点から見れば複雑でもない。オーケストレーションと実行という二つの軸を中心に展開する。まず、アウトプットの用途を決める。内部説明なのか、UIレビューなのか、他の人に渡すためのパッケージなのか。次に、必要なアウトプット形式に応じたサテライトスキルを選ぶ。課題が複数の能力グループにまたがる場合は、一つのスキルに他のスキルの仕事をさせようとするのではなく、パート03のケーススタディで実際に実行されたように正しい順序でスキルを組み合わせる。