BuilderIO/skills は、Builder.io が公開しているAIコーディングエージェント向けの Agent Skill 集だ。READMEの1行目は「Small, composable skills for your favorite agent.（お気に入りのエージェントのための、小さく組み合わせられるスキル）」。⭐4,479・MIT。この「小さく」がどこまで本当なのかを、24本を1本ずつ測り、/visual-edit を実際に手元へ入れて確かめた。
- ・`skills/` 配下に **SKILL.md 24本・合計205,584バイト**（ほかに `.agents/` に1本）
- ・**上位3本はすべてvisual系**（visual-recap / visual-plan / visual-edit）で、**全体の47.4%**を占める
- ・常駐するfrontmatterは24本合計 **7,076バイト＝約1,769トークン**。本文まで読むと約51,396トークン
- ・**`disable-model-invocation` を持つ本は0本**。24本すべてが自動起動の候補になる
- ・`/visual-edit` を実際に導入：**1分21秒**、書かれたのは **`~/.claude/` 配下だけ**でプロジェクトは無変更
- ・**公開リポジトリのSKILL.mdと配布版は完全一致ではない**（3ハンク・21行の差）
エージェント側の全体像やフレームワークの選び方はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめてある。本記事はその枝として、「スキル集を1つ入れる」という行為の中身を測る。
BuilderIO/skillsとは：24本の内訳を数える
リポジトリは 2026-06-10 作成、最終コミットは 2026-09-30 の eb07be6。コミットメッセージが chore: update Agent Native exported skills で、この時点で「ここは手で書く場所ではなく、別のどこかから書き出されている」と分かる。ライセンスは MIT、.claude-plugin/plugin.json の名前は builder-skills で、mcpServers として ./.mcp.json を指している。
24本の内訳はこうなっている。
| 系統 | 本数 | 中身 |
|---|---|---|
| visual系 | 3 | visual-recap（差分を対話的な振り返りに）・visual-plan（文字の計画を図に）・visual-edit（動いているアプリをキャンバスで編集） |
/factory 系（実験扱い） |
9 | 設定の factory と、collect / babysit-pr / review-prs / ship / lookback / human-digest / watchdog / recover |
| アプリ連携 | 3 | an（Agent-Nativeアプリを会話の横で操作）・webmcp（ページのMCPツールを先に使う）・turn-into-app（スレッドやスキルを動くアプリに） |
| 作業の作法 | 9 | agent-watchdog・plan-arbiter・plow-ahead・efficient-fable・efficient-frontier・stay-within-limits・quick-recap・read-the-damn-docs・rewind |
バイト数で見ると、重心がはっきりする。
上位3本がすべて visual系で、合計97,379バイト。24本の総計205,584バイトの 47.4% を1／8の本数が占めている。残り19本を合わせても70,783バイトで、visual系3本のほうが大きい。「小さく組み合わせられるスキル」という説明は、作法系の小さいスキル群には当てはまるが、看板商品には当てはまらない。
小さい側を見ると、確かに小さい。最小の quick-recap は1,420バイトで、中身は「作業が終わる応答は必ず 🟢 🟡 🔴 のいずれかで始まる100字未満のステータス行で終える」という規約ひとつだけ。efficient-frontier（3,422バイト）は、高価なモデルには設計・優先順位付け・曖昧さの解消・最終レビューだけを残し、調査・リポジトリの棚卸し・ログの圧縮・テスト失敗のクラスタリングといった作業を安いサブエージェントに投げる、という分担の手順書だ。判断と実行を分けるという考え方自体は、pstackの検証スキルとは｜エージェントに自分の作業を証明させる2本をソースで読むで見たものと同じ系統にある。
24本すべてが自動起動する、という設計判断
読んでいて一番目を引いたのは、サイズでも本数でもなかった。disable-model-invocation: true を持つSKILL.mdが1本も無いことだ。
比較のために、当サイトが同じ方法で測った他の2つを並べた。emilkowalski/skills は13本中3本（review-animations・prototype・pick-ui-library）、pstack（cursor/plugins）は 47本中46本が自動起動を切っている。BuilderIO/skills は逆側の端にいる。
これは優劣の話ではなく、設計思想の違いだ。pstack のスキルは「証明しろ」「原則に従え」といった重い作法なので、呼ばれたときだけ効けばいい。同じく作法を注入するSuperpowers完全ガイド：AIエージェントに“プロの開発作法”を注入する最強OSSも、呼び出し側が意図して使う設計だった。対して BuilderIO/skills の read-the-damn-docs（外部APIを触る前に公式ドキュメントを読ませる）や stay-within-limits（長時間作業の前に利用上限を確認させる）は、エージェントが自分で気づいて発火しないと意味がない種類のものだ。
ただしコストは意識しておく必要がある。24本のfrontmatterを合計すると 7,076バイト＝約1,769トークン（当サイトの tools/token_audit.py が使う heuristic 近似・CJK 1字=1 / ASCII 4字=1。tiktoken の cl100k_base はBPE辞書の取得がこの環境の外向き通信で遮断され使えなかった）。この1,769トークンは常駐するだけでなく、毎ターン「いま発火すべきか」の判定対象になる。本文まで読み込んだ場合の合計は約51,396トークンで、visual系3本だけで約24,345トークンを占める。
ベンダーが自社のハーネスをスキル群として配る形はMantisとは｜Googleの脆弱性探索19スキルを入れて動かす境界まで実測したでも見たが、あちらが19本すべてを1つの目的（脆弱性探索）に向けていたのに対し、こちらは目的がばらけている。なお /factory 系9本は README で明示的に experimental（実験扱い） とされている。フィードバック・テレメトリ・エラーを集めて、ポリシーで縛った上で修正・レビュー・マージ・デプロイまで自動で回すという構想で、PRの見張りや停滞タスクの検知まで含む。24本のうち3分の1以上が実験的なワークフローだという前提は、入れる前に知っておいたほうがいい。
/visual-edit を実際に入れてみる
ここからは手を動かす。ユーザーから指定された skills/visual-edit/README.md に書かれたコマンドを、そのまま空のリポジトリで実行した。
mkdir an-test && cd an-test && git init -q
npx @agent-native/core@latest skills add visual-edit
1分21秒（real 1m20.812s）で完了した。表示された要約はこうだ。
• Registered "agent-native-design" for claude-code, cursor, opencode, github-copilot
at https://design.agent-native.com/mcp
• Skipped URL-only hosted MCP config for codex, cowork; run agent-native connect ...
• Authentication skipped (non-interactive). To finish auth, run:
npx @agent-native/core@latest connect https://design.agent-native.com --client ... --scope user
— ✅ All set! Start using /visual-edit in your agent client.
そして実行したディレクトリには、1バイトも書かれていなかった。
書かれた先は2箇所だ。
・~/.claude/skills/visual-edit/SKILL.md（30,990バイト）と agent-native-skill.json（423バイト）
・~/.claude.json の mcpServers に agent-native-design → https://design.agent-native.com/mcp
--help を見ると --scope <user|project> の既定が user で、-g がそのエイリアスになっている。「このリポジトリで試す」つもりで叩くと、全プロジェクトに効く場所へ入る。プロジェクトに閉じたいなら --project を明示する必要がある。あわせて --no-mcp（スキルのファイルだけ入れてMCP登録を飛ばす）、--dry-run（書き込まずに予定を表示）、--json も用意されていたので、まず --dry-run --json で確かめてから入れるのが素直だ。実際に --dry-run を通すと、内部で組み立てられるコマンドがそのまま出てくる。
# 何が起きるかだけを見る（書き込みなし・当記事で実行）
npx @agent-native/skills@latest add --dry-run --json -y
# => "commands": ["npx @agent-native/core@latest skills add assets --client claude-code,codex,cowork,cursor,opencode,github-copilot --scope user --yes"]
置かれた agent-native-skill.json には contentHash・installedAt・installCommand・updateCommand が入っていて、更新も npx @agent-native/core@latest skills update visual-edit で行う形になっていた。スキルが「ファイルを置いて終わり」ではなく、配信元と紐づいた管理対象として扱われている。
なお認証は非対話実行のためスキップされ、connect を別途実行するよう促された。認証していないので open-visual-edit などのMCPツールは一度も呼べておらず、キャンバス上の編集とソースへの書き戻しは未検証だ。この検証環境からは dispatch.agent-native.com も design.agent-native.com も外向き通信が許可されておらず、そもそも到達できない。
検証後、当記事では ~/.claude/skills/visual-edit/ と ~/.claude.json のMCP登録を削除して元の状態に戻した。ユーザースコープに入る道具を試すときは、戻し方まで含めて手順にしておきたい。
実行して分かった経路を図にすると、こうなる。
展開30MB・3,976ファイル"] B --> C{"--scope の既定"} C -->|"user（既定）"| D["~/.claude/skills/visual-edit/
SKILL.md 30,990B ＋ メタ 423B"] C -->|"--project を明示"| E["プロジェクト配下に配置"] D --> F["~/.claude.json に MCP を登録
agent-native-design"] F --> G{"認証"} G -->|"対話あり"| H["connect でブラウザ認証
open-visual-edit が使える"] G -->|"非対話（当記事）"| I["スキップ。ツールは呼べない＝未検証"]
「小さいスキル」の裏にある30MB
もう1つ測っておきたかったのが、npm側の実体だ。READMEが勧める一括導入は npx @agent-native/skills@latest add、visual-edit の README が指すのは npx @agent-native/core@latest skills add visual-edit。別のパッケージが2つある。
| パッケージ | 最新 | 公開日 | 展開サイズ | ファイル数 | 公開バージョン数 |
|---|---|---|---|---|---|
@agent-native/skills |
0.3.18 | 2026-09-30 | 400,439バイト | 30 | 1,390 |
@agent-native/core |
0.198.6 | 2026-09-30 | 30,008,779バイト | 3,976 | 1,733 |
@agent-native/skills の説明は「Install BuilderIO skills for coding agents.」で、依存はわずか2つ。ただしその片方が @agent-native/core 0.198.6 で、こちらは自称「エージェント型アプリケーションのフレームワーク」、展開して 30MB・3,976ファイルだ。依存には nitro・h3・yjs・postgres・better-auth・esbuild・ink・i18next などが並ぶ。Markdownを1枚置くために、Webフレームワーク一式が npx のキャッシュに落ちてくる。
半年で1,733バージョンという公開ペースも目を引く（2026-03-12 作成なので、単純平均で1日あたり8回以上）。@latest を毎回叩く運用だと、同じコマンドが日によって違うものを入れる可能性は高い。
npx @agent-native/skills@latest list を叩くと、CLIが配れるスキルの一覧が出る。ここでリポジトリの24本とは粒度が違うことに気づいた。visual-plan・visual-recap・visualize-repo は visual-plans という1つの導入単位にまとめられており、逆に assets のようにリポジトリに無いものが出てくる。/visual-edit に至っては、この list には現れない（@agent-native/core 側から入れる）。GitHubで見える構成と、CLIが実際に配る構成は同じではない。
公開リポジトリのSKILL.mdは、配られる版と少し違う
最後に、いちばん気になっていたことを確かめた。GitHubに置かれている skills/visual-edit/SKILL.md と、いま手元に入った SKILL.md は同じものか。
答えは「ほぼ同じだが、一致はしない」。30,992バイト対30,990バイト、差分は3ハンク・21行。言及されるMCPツール名（open-visual-edit・get-visual-edit-pending・get-visual-edit-prompt・apply-visual-edit・acknowledge-visual-edit-pending）は両方とも同じ5つで、機能の骨格は変わらない。違うのは操作の説明だ。
・公開リポジトリ版：「キャンバスに別の Apply ボタンは無い」「Copy prompt で視覚編集をコーディングエージェントに渡す」
・配布版：「Apply design updates をホストの MCP Apps ブリッジ経由で通す」「キャンバスが Apply design updates（ローカル）または Apply edits を出すまで保留される」
つまり配布版のほうが新しい操作系を説明している。最終コミットが chore: update Agent Native exported skills である以上これは想定内の挙動で、リポジトリは配布物の書き出し（export）であって正典ではない。GitHubのSKILL.mdを読んで挙動を判断すると、わずかにずれるということは覚えておきたい。
/visual-edit の README 自体も、機能の説明としてはよくできている。ローカルで動かしているアプリの実ルートを iframe の画面としてキャンバスに並べ、paths で複数ページ、routes で多段フロー、viewports でレスポンシブ幅を指定する。注意書きも率直で、「Design はそれらの変更を自動でコードに書き込まない」「公開・読み取り専用のデザインはサインイン無しで見られるが、作成・保存・共有にはアカウントが要る」と明記されている。動かせていない以上これらは未検証だが、アカウント必須のホスト型サービスに依存するスキルだという前提は、READMEの時点で隠されていない。
最後に、当記事で確かめた範囲を整理しておく。
| 項目 | 確認方法 | 状態 |
|---|---|---|
| SKILL.md 24本・205,584バイト | clone して1本ずつ計測 | 実測 |
| visual系3本が47.4% | 同上 | 実測 |
disable-model-invocation が0本 |
24本のfrontmatterを走査 | 実測 |
| 常駐1,769トークン／本文51,396トークン | frontmatterと本文を分けて計測 | 実測 |
| インストール1分21秒と書き込み先 | 空リポジトリで実行し、書かれたファイルを列挙 | 実測 |
--dry-run --json の出力 |
実行 | 実測 |
| npmパッケージのサイズとバージョン数 | registry.npmjs.org のメタデータ | 実測 |
| 公開版と配布版の差分（3ハンク・21行） | diff | 実測 |
| キャンバスでの編集とソース書き戻し | 認証未実施・ドメインに到達不可 | 未検証 |
/factory 系9本の実動作 |
実行していない | 未検証 |
| 他クライアント（Cursor・Codex等）での挙動 | Claude Code 向けの書き込みのみ確認 | 未検証 |
「スキルを1本入れる」と言うとMarkdownを1枚置くだけに聞こえるが、実際にはどのスコープに、どのサーバとの接続ごと書き込まれるかが付いてくる。--dry-run が用意されているのは良い設計なので、まずそれを通してから決めたい。
参照ソース
・BuilderIO/skills — GitHubリポジトリ（main・最終コミット eb07be6・2026-09-30 を clone して計測）: https://github.com/BuilderIO/skills
・skills/visual-edit/README.md — 導入コマンドと使い方: https://github.com/BuilderIO/skills/blob/main/skills/visual-edit/README.md
・@agent-native/core — npm レジストリのメタデータ（0.198.6・展開30,008,779バイト）: https://registry.npmjs.org/@agent-native/core
・@agent-native/skills — npm レジストリのメタデータ（0.3.18）: https://registry.npmjs.org/@agent-native/skills
