インストール
pnpx skills add antfu/skills --skill='*'誰向けか
日常の中心が Vite または Nuxt で、汎用フロントエンド雛形ではなく、Anthony Fu の好み、経験、ツール用法の説明をコーディング Agent に先に読ませたいときに、このキュレーション一式を使う。Agent Skills 形式に従い、出典も範囲も異なるスキルをまとめ、Vite/Nuxt の一箇所集合を目指す。作者はこれを概念実証と書く：元文書からスキルを生成して同期し、実地の効果は自分でも十分試していない。フィードバック歓迎。出力を提案として扱い、プロジェクトの現状と照合する人に向く。他のフレームワークをまだ使っている人、またはスキルがすでに安定して受け入れ済みであることを求める人は、先に制限を読む。ページは具体的なスキル名を出さず、クライアントも指名しない。名簿や独占対応を自分で足さないこと。
3 分で最初の試行を終える
公式のこのプロジェクト内インストールだけを使い、全スキルを入れる：
pnpx skills add antfu/skills --skill='*'
コマンド内の引用符とアスタリスクはページどおりでなければならない。npx や、出ていないインストーラに変えない。同じページには -g 付きのグローバルインストールもある。それはより多くのプロジェクトに効く。最初の試行の既定経路ではない。
入れ終わったら、既存の Vite または Nuxt リポジトリを開く。最初は読み取り専用の照合だけ。いまの設定に関する質問、たとえば既存 Vite 設定が何をしているかの説明に、集合のどの種類のツール用法文書を使う予定か Agent に言わせる。先に復唱させる：これは概念実証、作者は十分に実測していない、いまは説明だけしてファイルは変えない。確認してからファイル読みを許す。成功の合図は、回答がリポジトリ内の実設定と合い、ページに無いスキル短縮名を作っていないこと。
Agent が設定変更やプラグイン追加を始めたら止める。フィードバックと貢献は公式が歓迎するが、先にリポジトリを変えなければならない意味ではない。
利用事例
事例一：Vite/Nuxt プロジェクトで作者の好みに沿ってツール用法を聞く。全スキルを入れたあと、いまのリポジトリについてビルド、開発サーバー、Nuxt の約束事を聞き、先にスキル内の用法説明を引用させ、それから自分のファイルと照合する。漠然としたフレームワーク助言を減らす向き。説明にスキルディレクトリは無いので、スキル名を先に埋めない。ファイルに合わない助言は捨てる。
事例二：グローバルインストールのあと別プロジェクトで確認する。公式の二番目のコマンドは同じインストールに -g を足したもの。複数の Vite/Nuxt リポジトリで同じ好み一式を読みたい人向け。グローバル書き込みの前に、他プロジェクトへ影響することを受け入れるか確認する。別リポジトリで同じ読み取り専用の説明をし、一式がまだ読み込まれているか見る。-g を未記載のディレクトリに向けない。アンインストール手順も作らない。
利用上の境界
既定のインストールは pnpx skills add antfu/skills --skill='*'。-g はグローバル変種であり、最初のコマンドの一部ではない。これは概念実証で、作者は振る舞いを十分試していない。スキルは元文書から生成して同期する。効果は手元の照合が基準。集合は Vite/Nuxt 向けで、出典と範囲が混ざる。あらゆるフロントエンド積み重ねの公式規範だと思わず、作者のホームページから追加のインストール入口も推測しない。ページはクライアント名簿、秘密情報、スキル短縮名を出していない。書いていないパスやマーケットコマンドは足さない。リポジトリページ：
https://github.com/antfu/skills