# AIで見栄えのいいSaaS画面を作る デザインスキルを工程ごとに使い分ける

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-08-24
- カテゴリー: エージェント・ソフトウェア
- タグ: SaaS、ダッシュボード、Claude Code、Codex
- 想定読了時間: 約19分
- 調査基準日: 2026年8月24日
- 出典: 16件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/saas-dashboard-design-skills
- このMarkdown: https://www.chinouken.com/articles/saas-dashboard-design-skills.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

SaaSのダッシュボードをAIコーディングエージェントで作るなら、一つの「最強スキル」を探すより、方向づけ、情報設計、実装、動きの仕上げ、実画面の検証を工程として分ける方が安定します。同じ顧客データと同じ依頼文へ、frontend-design、emil-design-eng、Impeccable、interface-design、ui-ux-pro-maxを差し替えて七通りに生成して比較し、有力スキルの中身と導入の順序を整理します。

![スキルが決める視覚の方向 署名要素 動きの規則と 工程が決める判断の一文 情報設計 実画面の検証を左右で対比した概念図](https://www.chinouken.com/images/articles/saas-dashboard-design-skills/hero.png)

*デザインスキルは見た目の方向を確実に変えます。リスクの定義や次の操作は、判断の一文から検証までの工程が決めます。*

## きれいな画面より判断できる画面

SaaSのダッシュボードは、利用者が状態を把握し、異常を見つけ、次の操作を決めるための確認画面です。売上、利用状況、未処理件数をカードへ並べるだけでは、数字を見た後に何をすべきかが分かりません。誰が、どの頻度で、どの判断をするのかを決めてから、比較期間、更新時刻、責任者、絞り込み、詳細への導線を置く必要があります。

144件のダッシュボードを調べた研究でも、画面には分析型、物語型、埋め込み型などの型があり、画面面積、操作、表示情報の両立を目的に応じて設計する必要があると整理されています。[9] 一方でAIエージェント向けのデザインスキルの多くが主目的にするのは、平均的な見た目からの脱出です。Anthropicの`frontend-design`とImpeccableは、用途、利用者、トーン、制約、記憶に残る差を実装前に定めさせます。[2][3] 見た目の方向づけと、確認画面としての正しさは別の工程です。この二つがどう分かれるかを、まず実際の生成結果で確かめます。

## 同じ顧客データで七通りに作った結果

結論を先に見せます。上の画像は、五段階の工程で作った「朝の確認画面」です。カスタマーサクセス管理SaaSを題材に、顧客10社分の固定データを用意し、健康度50未満の4社を対応キューとして上へ、残り6社を表へ置きました。各行の帯は現在の健康度と8週間の推移を一体化した表示で、担当者のいない顧客には割り当て操作、全顧客に「対応を記録」ボタンがあります。

実験の条件をそろえるため、次を固定しました。データは51文字の長い社名、担当者未割り当て2社、45日間未ログイン、30日以内の契約更新2社を含む10社分のJSONです。依頼文は「モダンなSaaSダッシュボードを作ってください。データはdata.jsonの顧客データを使ってください」の一文で、単一の自己完結HTML、外部ライブラリ禁止、日本語UIだけを制約にしました。比較するスキルは、導入数や星数で名前の挙がる公開スキルのうち、2026年8月24日にGitHubで実在と原文を確認できたものから選びました。星8万件超のTasteは、原文の冒頭が「ダッシュボード、データテーブル、複雑な製品UIは対象外」と宣言しているため、対象外宣言そのものを結果として記録し、生成には使っていません。

| 作り方 | 所要時間 | HTML行数 | 画面の要点 |
| --- | ---: | ---: | --- |
| スキルなし | 2分17秒 | 655行 | 濃紺サイドバーとKPI横並びの既定の管理画面 |
| `frontend-design` | 3分43秒 | 561行 | 散布図「更新ランウェイ」を主役にした独自構図 |
| `emil-design-eng` | 2分2秒 | 611行 | 静かなグレー基調。動きは初回表示だけに限定し、絞り込みは即時反映 |
| Impeccable | 8分15秒 | 597行 | KPIタイル格子を内蔵規則で拒否。推奨アクション付きキューとMRR健康構成 |
| `interface-design` | 3分27秒 | 771行 | 「夜の港と灯台」の世界観で作ったダークUI。危険MRRセルだけ琥珀の署名要素 |
| `ui-ux-pro-max` | 3分6秒 | 844行 | 青系の標準的な管理画面。44pxの操作領域やaria属性を優先 |
| 五段階の工程(筆者) | 約45分 | 384行 | 判断の一文から設計。対応キューと割り当て・記録の操作だけを残す |

スキルを使う6本は、Claude Code(Fable 5)のサブエージェントへ毎回まっさらな状態で同じ依頼を渡し、読ませるSKILL.mdだけを差し替えました。Impeccableは本体の指示どおり参照ファイル3枚を追加で読み、生成中に自前の画面検査まで実施したため所要時間が最長です。`interface-design`と`ui-ux-pro-max`はGitHubのSKILL.md本文だけを渡したため、`ui-ux-pro-max`は同梱の検索データベースなしのフォールバック動作になっています。筆者のCは「判断の一文を決める、視覚方向を決める、情報設計を決める、実装する、実画面を検証する」の順で作りました。Cの機能は七つの中で最も少なく、行数も最少です。判断の一文を「責任者が毎朝10分で、リスクの高い順に確認し、担当のいない顧客へ担当を割り当て、対応を記録する」と先に決めたため、検索、並べ替え、ナビゲーションを全部落とし、割り当てと記録の操作だけを残せました。

七通りに共通する結果が一つあります。データに「リスク顧客」の定義を入れなかったところ、AIが作った6本すべてが健康度50未満を危険の閾値として自分で決め、スキルを読ませた4本は50未満・50〜69・70以上の同じ三段階を画面の脚注へ明記していました。各エージェントは完了報告でも「閾値はデータに定義がないため自分で決めた」と申告しています。どのスキルを使っても、業務の定義を渡さなければAIが同じ既定値で埋めるという点は、この後の議論の前提になります。

![五段階の工程で作った朝の確認画面 危険域4社の対応キューと担当割り当て操作 残り顧客の表を持つカスタマーサクセス管理のダッシュボード](https://www.chinouken.com/images/articles/saas-dashboard-design-skills/figure-variant-c.png)

*五段階の工程で作った変種Cです。危険域の顧客を理由と次の操作つきで上へ置き、サマリーは判断へ直結する3枚だけにしました。*

## スキルごとに変わったことと変わらなかったこと

今のモデルのAIらしさは、紫のグラデーションや崩れたレイアウトには現れません。スキルなしの画面は、濃紺のサイドバーに角丸の「CS」ロゴ、白いカード、青のアクセント、KPIカードの横並び、健康度バーとスパークライン付きの顧客テーブル、右側の要対応アラートという、破綻のない、そして誰がどのSaaSを頼んでも返ってくる構図でした。「平均ヘルススコア59」のように見ても次の行動が決まらない指標も入っています。この既定の構図からの距離が、上の比較画像で分かるスキルの効き目です。

スキルはそれぞれ別の方向へ画面を動かしました。`frontend-design`は契約更新までの残り日数を軸に取る散布図「更新ランウェイ」を主役にした独自構図です。`emil-design-eng`は装飾を抑えた明るいグレー基調で、入場の動きを初回表示の一度だけに限定し、毎朝何度も押す絞り込みは動き無しの即時反映にするという、頻度で動きを決める規則が画面へそのまま出ました。Impeccableは「大きな数字と小さなラベルを並べるKPIタイル格子」を同梱の品質規則が禁じているため、要約をやめて「今日の対応」キューへ推奨アクションの文章を添え、総MRRを危険・注意・良好の帯で分解した「63.5%が危険域」という一文を主役にしています。`interface-design`は「夜の港と灯台」という世界観を先に決め、色トークンへ港や灯火の名を付けたダークUIで、画面で唯一の面的アクセントを危険MRRのセルへ置きました。`ui-ux-pro-max`は6枚のKPIと優先対応リストを持つ青系の標準的な管理画面で、44pxの操作領域、コントラスト比、読み上げ属性といったアクセシビリティ既定を最も丁寧に実装しています。

変わった点はもう一つあります。4本とも並べ替えと絞り込みが実際に動き、押しても何も起きない飾りのボタンをほぼ置きませんでした。`frontend-design`単独の生成では「押しても動かないボタン」の自己申告があったので、操作の実装度はスキルの規則で引き上げられています。一方で変わらなかった点が本題です。リスクの閾値は4本とも同じ50を自分で決め、担当者のいない顧客へ担当を割り当てる操作は、七つのうち工程で作ったCにしかありません。ダークUIや散布図には軸や配色の読み方という学習コストも残ります。見た目の方向づけを作るスキルは、業務の判断と操作の完了条件までは面倒を見ません。ここが方向づけと情報設計を別工程に分ける理由です。

![スキルなし frontend-design emil-design-eng Impeccable interface-design ui-ux-pro-maxで同じ顧客データから生成した6画面の比較グリッド](https://www.chinouken.com/images/articles/saas-dashboard-design-skills/figure-skill-grid.png)

*同じ依頼文とデータへ、読ませるスキルだけを差し替えて各1回生成した6画面です。構図も配色も毎回別方向へ変わる一方、リスクの閾値はどの画面も同じ50を自分で決めていました。*

## 有力スキルの役割

公開されているデザインスキルは、得意な工程が異なります。導入数やGitHubの星だけで順位を付けると、最初の画面を作るスキルと、完成後の不具合を探すスキルを同じ物差しで比べることになります。

| 候補 | 主な役割 | ダッシュボードで効く点 | 注意点 |
| --- | --- | --- | --- |
| Anthropic `frontend-design` | 新規画面の美術方向と実装 | 無難な見た目から離れ、題材固有の署名要素を作る | 独自性は情報の重複や学習コストと衝突し得る |
| Impeccable | 製品文脈、設計、批評、磨き込み、堅牢化 | `PRODUCT.md`と`DESIGN.md`を残し、画面をOperateモードとして扱える | 多機能なので、対象とコマンドを絞らないと作業が広がる |
| `interface-design` | 製品画面の階層、トークン、状態、細部 | 焦点を一つに絞る構図、四段階の文字階層、状態の網羅を要求する | マーケティングページには向かない |
| `ui-ux-pro-max` | 検索可能なデザイン知識データベース | 119件のUX指針や25種の図表型を検索し、密度設定をダッシュボード向けへ変えられる | 検索結果は推奨であり、業務の判断定義は含まれない |
| Taste | ランディングページ等の反スロップ生成 | ダッシュボードには効かない。原文が「ダッシュボード、データテーブル、複雑な製品UIは対象外」と冒頭で宣言 | 星数最上位級でも守備範囲外。人気順の導入が失敗する実例 |
| Emil Kowalski Skills | 動き、部品、細部の設計判断 | 頻度から「動かさない」を選び、曲線、時間、押下感まで指定する | 全画面の情報設計を単独で担うものではない |
| `frontend-visual-qa` | 実装後の視覚検査 | 端末幅、はみ出し、折返し、状態遷移を実ブラウザーで確認する | 表示が正しくても、意味が伝わるかは別の検査が必要 |

### Anthropic frontend-design

Anthropicの`frontend-design`は、短い`SKILL.md`で強い方向を与える入口です。用途、トーン、技術制約、差別化をコードより前に決め、AI生成に頻出する既定の見た目を名指しで避けさせ、大胆さは署名要素の一点に集中させます。[2] 実験で確認したとおり、既定の管理画面の構図から離れる効果は確実に現れます。日常的に使う製品画面では、この大胆さが情報密度や毎朝の操作と衝突しないかを、次の情報設計の工程で確かめる必要があります。

### Impeccable

Impeccableは、単発の生成指示を、製品文脈が残る設計運用へ広げたスキルです。`PRODUCT.md`へ利用者、目的、製品の約束を置き、`DESIGN.md`へ色、文字、部品、視覚規則を残したうえで、新規制作、批評、監査、磨き込み、情報の削減、堅牢化、端末対応を別のコマンドとして扱います。[3][4] SaaSで効くのは、画面をOperate、つまり利用者が仕事を完了する面として扱う判断です。既存製品で色や部品が定まっている場合は、先に現在の設計を文書化してから修正することで、ページごとに別の雰囲気になる問題を抑えます。

### interface-designとui-ux-pro-max

`interface-design`は、ダッシュボード、管理画面、設定、データ画面へ範囲を限定した設計技能です。読んでみると規則はかなり具体的で、一画面に焦点を一つだけ置く、文字サイズではなく太さと不透明度で階層を作る、表示待ち、空、エラーを含む状態を省かない、動きは変形と不透明度だけに限る、といった判断を、実装時の確認手順として要求します。[5] 生成の独自性より、細部が同時に正しいことを競争力と定義している点で、`frontend-design`と補完関係にあります。

`ui-ux-pro-max`は、79種の様式、119件のUX指針、25種の図表型などを収めた検索可能なデータベースをスキルとして配る構成です。付属の検索スクリプトへ製品種別を渡すと配色、書体、避けるべき型を返し、余白の密度をダッシュボード向けの詰まった設定へ切り替える指定もあります。[6] 日本語圏でも`frontend-design`との併用例が公開されています。[15] 知識の検索は速い一方、返ってくるのは一般的な推奨であり、どの指標で何を判断するかは依頼側が決める必要があります。

### Emil Kowalskiのデザイン技能

Emil Kowalskiの公開リポジトリは、VercelとLinearでの経験をもとに、動きと細部の判断を複数のスキルへ分けています。中心の`emil-design-eng`に加え、既存アニメーションの批評、改善候補の探索、動かすべき場所の発見などがあります。2026年8月24日の確認時点で、GitHubでは3万件を超える星を集めていました。[7]

実務で価値があるのは、何でも動かす指示ではありません。毎日100回以上使う操作は動かさず、たまに開くモーダルや通知だけ標準的に動かすという頻度からの判断と、入る要素は速く反応してゆっくり止まる曲線、押下は軽い縮小で応えるという具体値です。[7] 実験のCでもこの基準を使い、入場アニメーションを全て外して、ホバー、押下、状態変化だけへ動きを絞りました。

### 実ブラウザーで見る視覚QA

`frontend-visual-qa`は、完成した画面を実ブラウザーで開き、構成、文字、余白、折返し、切れ、端末幅、状態遷移を調べる検査用スキルです。ビルドの成功、DOM上の存在、撮っただけで見ていない画面画像を、視覚的な証拠とは扱いません。[8] 後述する実行記録のとおり、今回の実験でもこの工程だけが4件の実不具合を見つけました。表示の検査が合格しても、指標名が伝わるか、次の操作が分かるかという意味の検査は別に残ります。

## ローカルで中身を調べた結果

知能圏の作業環境には、Impeccable、`emil-design-eng`、動きの実装用`animate`、アニメーション批評用`review-animations`が導入済みでした。2026年8月24日に各`SKILL.md`と同梱ファイルを読み、役割と規則の粒度を確認しました。`interface-design`と`ui-ux-pro-max`、そして星数で最上位級のTaste(`taste-skill`)はGitHub上の原文を読んでいます。[16] Tasteは本体だけで1206行ありますが、冒頭でランディングページ、ポートフォリオ、再設計に範囲を絞り、ダッシュボードを名指しで対象外にしていました。

| 確認対象 | `SKILL.md`の行数 | 同梱ファイル数 | 実査で分かったこと |
| --- | ---: | ---: | --- |
| Impeccable 4.0.4 | 79行 | 152 | 本体は振り分け役で、各作業の詳しい規則、スクリプト、参照資料を必要時だけ読む |
| `emil-design-eng` | 674行 | 1 | 動き、部品、細部の判断を一つの長い指示へ集約している |
| `animate` | 199行 | 2 | 動かす目的、道具、属性、曲線、時間、割込み、終了を順番に決める |
| `review-animations` | 112行 | 1 | 既存の動きへ厳しい合否判定を行い、問題を表で返す |

Impeccableは巨大な文章を毎回読み込むのではなく、入口で作業を振り分けて必要な参照だけを開く構造でした。OpenAIの公式文書でも、スキルは`SKILL.md`に名前、発動条件、手順を置き、必要に応じて参照、スクリプト、ひな型、素材を同梱できると説明されています。[1] Anthropicも長い参照資料は必要時だけ読み、`SKILL.md`本体を短く保つよう案内しています。[11]

出典の実在確認も実査の一部です。この記事の初稿では、判断中心の設計規則を含むとされる`ui-ux-design`という公開スキルを候補に挙げていましたが、公開前の照合でGitHubのリポジトリごと404になっており、実在を確認できませんでした。該当の記述を落とし、実在を確認して原文を読んだ`ui-ux-pro-max`へ差し替えています。スキル名だけが紹介記事から紹介記事へ伝言される状況では、原文へ戻る確認を省けません。

ここからは筆者の見立てです。デザインスキルの質は、規則の多さだけでなく、いつ何を読むか、実画面をどう確かめるか、失敗をどの成果物へ戻すかで決まります。長い美学の文章だけを追加しても、利用者の仕事、実データ、端末幅、状態、検証手順がなければ再現性は上がりません。

## 五段階の実行記録

筆者の版Cは五つの工程を順番に通しました。各工程の成果物と所要時間、見つかった問題をそのまま残します。

1. 判断の一文を決めます。「カスタマーサクセス責任者が毎朝10分で、解約リスクの高い顧客から順に確認し、担当者のいない顧客へ担当を割り当て、対応を記録する。デスクトップ中心、スマートフォンでは確認だけできればよい」としました。ここで完了条件に「割り当て」と「記録」の操作が入ったことが、画面から検索やナビゲーションを削る根拠になりました。
2. `frontend-design`の手順で視覚方向を決めます。世界観は毎朝の当直、色は地と面の明るいグレーに墨色の文字、危険、注意、良好、操作の4色だけを意味へ割り当て、署名要素は健康度の現在値と8週間の推移を段階色で一体化した帯としました。避ける既定値も先に書き出しました。
3. 情報設計を決めます。`interface-design`の焦点を一つに絞る規則とダッシュボード設計研究の型を参照し、危険域4社を対応キューとして上へ、残り6社を表へ、サマリーは「危険域の顧客数と対象収益」「担当者がいない顧客」「30日以内の契約更新」の3枚だけにしました。各行には理由と次の操作を並置し、危険域ゼロの空状態、長い社名の折返し、担当未割り当ての強調を先に決めました。
4. 実装します。動きは`emil-design-eng`の頻度基準で、入場アニメーションなし、ホバー120ミリ秒、押下は3%の縮小、状態変化150ミリ秒だけにし、視差や演出は入れませんでした。設計メモと実装で約20分です。
5. ヘッドレスChromeで1480px、800px、390pxの画面画像を撮り、目視で検査します。往復3回で4件の不具合を見つけ、すべて修正しました。

見つかった4件は、8週間差分の「-8 / 8週」が途中で折り返す、備考と自動生成の理由文が「未解決の問い合わせ7件」を二重に表示する、幅800pxでデスクトップ用の格子がはみ出して操作ボタンが画面外へ消える、幅390pxで2列の格子が最小幅を超える、というものです。上の画像は3件目の修正前後です。設計と実装をどれだけ丁寧に進めても、この種の問題はレンダリング後にしか現れませんでした。

検査の道具にも落とし穴がありました。ヘッドレスChromeはウィンドウの最小幅が500pxのため、390pxを指定した最初の撮影は「500pxで組んだ画面を390px幅に切り抜いた」偽の画像になっており、存在しないはみ出しを疑って時間を使いました。500pxの窓の中へ390px幅のiframeを置く撮影用HTMLを作って解決しています。撮っただけの画像を証拠と扱わないという`frontend-visual-qa`の注意は、撮影方法自体にも当てはまります。QAと修正、撮影環境の調査を合わせて約25分でした。

![幅800pxで操作ボタンが画面外へ切れた修正前と 操作列を下段へ移した修正後の画面比較](https://www.chinouken.com/images/articles/saas-dashboard-design-skills/figure-qa-before-after.png)

*視覚QAが見つけた3件目の不具合です。幅800pxでデスクトップ用の格子がはみ出し、操作ボタンが画面外へ消えていました。*

## Xで見えた期待と警戒

X上では、スキルを専門知識の再利用単位として評価する投稿と、増えすぎたスキルの重複や陳腐化を警戒する投稿が並んでいます。Kaxil Naikは、制作、レビュー、ブラウザーでの一連の操作、画面画像や録画までを技能と道具の組み合わせにし、決定的な出力にはスクリプトとフックを使う運用を紹介しました。[12] デザイン分野でも、指示文だけでなく、画面を開いて確認し、失敗を規則へ戻す流れが重要だと読めます。

Simon Smithは、Skills.shに8万5千件を超えるスキルがある状況で、組織内の重複、整理、更新が新しい負債になると指摘しています。[13] 数字は投稿者による当時の観測ですが、同種の`frontend-design`を何本も入れ、どれが発動したか分からない状態への警告として妥当です。実在しないスキル名が紹介記事を巡回する今回の経験も、この規模の副作用と読めます。Aaron Levieも、AIによって専門性が不要になるのではなく、専門家がエージェントを正しく方向づける力の倍率が上がると述べています。[14]

研究からも、スキルを入れれば自動的に成績が上がるとは限りません。SWE-Skills-Benchは49件の公開ソフトウェア技能を実際のリポジトリ課題へ適用し、39件で合格率の改善がなく、平均改善も1.2ポイントだったと報告しました。[10] 対象はデザイン専用評価ではありませんが、人気、長さ、名前だけで採用せず、自分の画面と完了条件で比較する必要を示します。今回の実験でも、スキルなしの生成は十分に整った画面を出しており、スキルの価値は壊れた出力を直すことにはありません。既定の構図から画面を引き離し、動きや品質の下限のような決めていなかった規則を先に与えるところに現れました。そして星数最上位級のTasteがダッシュボードを対象外と宣言しているように、人気順とその画面への適合は別の話です。

## 最初に導入する組み合わせ

新規のSaaSダッシュボードなら、`interface-design`を主担当にし、Anthropicの`frontend-design`を視覚方向の補助へ置く構成が小さく始められます。既存製品を継続して改善するなら、Impeccableで`PRODUCT.md`と`DESIGN.md`を作り、批評、磨き込み、堅牢化を同じ文脈で回す方が向いています。Emil Kowalskiの技能は動きと細部、視覚QAは実装後の検査に限定すると責任が重なりません。`ui-ux-pro-max`は迷ったときの検索辞書として補助に置けます。

ただし今回の実測では、スキルより先に効いた要素が二つあります。一つは判断の一文で、これがないとリスクの閾値も優先順位もAIが埋めます。実際、スキルを読ませた4本はすべて同じ閾値50を自分で決めていました。もう一つは実画面の検証で、五段階のうち不具合を実際に見つけたのはこの工程だけでした。スキルを増やす前に、一つのダッシュボードで「判断の一文、方向づけ、情報設計、実装、検証」を一度通し、どの工程の品質が上がったかを記録するところから始めるのが安全です。比べるときは、同じ画面、同じデータ、同じ成功条件で一つの構成だけを変え、最重要の異常を見つけるまでの時間、次の操作の発見、横はみ出しや未定義状態の件数で判断すると、採用理由を説明できます。

## 参照リンク

1. [OpenAI: Skills – Plugins](https://developers.openai.com/plugins/concepts/skills)
2. [Anthropic: frontend-design](https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md)
3. [Impeccable: Impeccable](https://impeccable.style/docs/impeccable/)
4. [Impeccable: Design Context](https://impeccable.style/docs/context/)
5. [Dammyjay93: Interface Design](https://github.com/Dammyjay93/interface-design/blob/main/.claude/skills/interface-design/SKILL.md)
6. [nextlevelbuilder: UI/UX Pro Max](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill/blob/main/.claude/skills/ui-ux-pro-max/SKILL.md)
7. [Emil Kowalski: Skills for Design Engineers](https://github.com/emilkowalski/skills)
8. [daymade: Frontend Visual QA](https://github.com/daymade/claude-code-skills/blob/main/frontend-visual-qa/SKILL.md)
9. [arXiv: Dashboard Design Patterns](https://arxiv.org/abs/2205.00757)
10. [arXiv: SWE-Skills-Bench](https://arxiv.org/abs/2603.15401)
11. [Anthropic: Extend Claude with skills](https://code.claude.com/docs/en/skills)
12. [Kaxil Naik on X: I Haven’t Written a Line of Code in 4 Months](https://x.com/kaxil/status/2037503513350005134)
13. [Simon Smith on X: I like Agent Skills as a primitive](https://x.com/_simonsmith/status/2029713209179988445)
14. [Aaron Levie on X: Most people have the wrong default assumption](https://x.com/levie/status/2006521312693637597)
15. [SonicGarden: 画面デザインをClaude Codeと壁打ちして実装まで持っていく話](https://zenn.dev/sonicgarden/articles/fc9fe68b3611f7)
16. [Leonxlnx: Taste Skill](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md)

2026年8月24日時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/saas-dashboard-design-skills