AIFCC
記事一覧へ
claude-setupclaude-workflowharness-design

Claude Code「ベスプラ」スキルを12分で自作した話

734
「スキルってどう言う構造で書くのがいいんだっけ」 Claude Codeでスキルを作ろうとするたびにこれが起きる。 descriptionの推奨文字数は?modelフィールドの選択肢は? user-invocableとdisable-model-invocationの違いは?てかそもそも今作ってるスキルって構造大丈夫?な? 毎回GitHubを開いて調べてました。笑 ある日Claude Codeに「ベスプラのコマンドある?解説記事作りたい」って振ったら、「ないです」って言われた。 「え、じゃあそもそも作って、それ記事にしよう」って話になって、有名な「shanraisshan/claude-code-best-practice」の内容を全部読ませて、「/ベスプラ」ってタイプするだけで引けるスキルにした。 作業時間は約12分。もうGitHubを開く必要がない、、! きっかけ — 「記事にしよう」が「先に作ろう」に変わった瞬間 本当は、すでにある誰かのツールの解説記事を書くつもりだった。 で、Claude Codeに「ベスプラのコマンドある?」と聞いたら、ローカルに無いと。そこから流れが変わった。 「なら作るか」って思った時点で、これが意外と使える話になった。「記事のネタを探してたら、記事のネタを自分で作ってた」みたいな、、 Claude Codeにshanraisshanのリポを読み込ませて、スキル構造を設計させて、6つのカテゴリにrefファイルを分けて、/ベスプラ skills で呼び出せるようにした。 そして今、その作ったスキル自体が、次にスキルを作る時の参照になってる、、、! 困る → 調べる → また困る のループ スキルを作るたびに同じことを調べてた。 「descriptionは何語以内?」→ 100語。毎ターンロードされるから。 「SKILL.mdは何行まで?」→ 500行。それ以上はrefファイルに分離。 「Agentのfrontmatterって何フィールドある?」→ 16個。でも実際使うのは5個。 「settings.jsonの優先順位は?」→ 5段階。Managed > CLI args > local > shared > user。 全部知ってるはずなのに、毎回忘れる。GitHubのリポを開いて、ディレクトリを辿って、該当ファイルを見つけて、読んで、「あ、そうだった」ってなる。 この「忘れる → 調べる → 思い出す → また忘れる」のループが嫌すぎた。 /ベスプラ の中身 — コマンド1つで全部引ける 引数に応じて呼び出せる。6カテゴリに分けた。 `/ベスプラ skills` スキル設計のベストプラクティスが出る。frontmatterの13フィールド、2つのスキルパターン(DirectとAgent Skill)、サイズの鉄則(500行以下、description 100語以下)。全部。 `/ベスプラ subagents` エージェント設計。16フィールド、公式Agent 5つ、使うべき場面と使うべきでない場面の判断基準。 `/ベスプラ memory` CLAUDE.mdの書き方。Ancestor Loading(上方向・即時)とDescendant Loading(下方向・遅延)の違い。削除テスト(「この行を消したらClaudeがミスする?」→ Noなら削除)。 `/ベスプラ settings` 60以上の設定、5段階の優先順位。 `/ベスプラ mcp` 推奨MCPは4-5個で十分。「15個入れたけど結局4つしか使ってない」(Reddit 682 upvotes)。 `/ベスプラ commands` スラッシュコマンドの設計パターン。引数処理、自動起動、チーム共有。 引数なしで「/ベスプラ」だけ打てば全体概要。 活用事例1: 新しいスキル作る時 「AI動画生成スキル作ろう」って思った時。まず /ベスプラ skills で設計ルール全部引く。 frontmatterは何書く? → nameとdescriptionは必須、あとはuser-invocableとargument-hint descriptionの文字数は? → 100語以内 SKILL.md本体は? → 500行以内、それ超えたらrefファイルに分離 ファイル構造は? → SKILL.md + assets/ + scripts/ + references/ で、Claudeが「この構造で作ります」って提案してくれる。自分が手動でルール確認する時間がゼロになる。 5-10個スキル作ってる人なら、これだけで累計数時間の節約になってるはず。 活用事例2: CLAUDE.md の肥大化を止める時 半年くらい放置してたらCLAUDE.mdが800行超えた。 /ベスプラ memory で呼び出すと、削除テストのロジックが出る。 「この行を消したらClaudeがミスする? → Noなら削除」 これをClaudeに並列で全行判定させる。~/開発/xxx/CLAUDE.md の全行をレビューして、削除候補と残す理由を分類してもらう。 結果、800行 → 540行まで削れた。ターンごとに260行分のトークンを節約できる計算。 活用事例3: サブエージェント設計を考える時 「このタスク、サブエージェントに投げた方がいいのか、メインコンテキストで続けた方がいいのか」 /ベスプラ subagents で判断基準が出る: ✅ 中間出力が多くて結論だけ欲しい → サブエージェント ✅ 別コードベースを読み込む必要がある → サブエージェント ❌ ユーザーと対話しながら進める → メインコンテキスト ❌ 進捗をリアルタイムで見たい → メインコンテキスト 公式Agent 5つの使い分けと、自作Agentのfrontmatter 16フィールドの意味も出る。 自分はこれ見てから「サブエージェントを投げすぎてた」問題に気づいた。中間出力が少ないタスクはメインで続けた方がトークン効率いい。 活用事例4: 新しいClaude Codeバージョンの新機能追い Claude Codeは頻繁にアップデートされる。毎回リリースノートを追うのは無理。 /ベスプラ commands を引くと、存在する公式コマンド69個が全部出る。自分がバージョンアップで気づかずに使えるようになってた機能がボロボロ見つかる。 /effort — エフォートレベル変更(low/medium/high/max) /rewind — 会話を巻き戻し /btw — メインタスク中に割り込み質問 /passes — マルチパスレビュー /think、/thinkdeep、/thinkultra — 思考量コントロール 69個中、実用してるのは10個程度。残りの59個も「いつか使うかも」でストックしておける。 中身はめちゃくちゃシンプル ~/.claude/skills/cc-best-practice/ の中にSKILL.mdと参照ファイル6個、これだけ。 SKILL.mdは「目次」。引数を見て、どのrefファイルをReadするかだけ。 ref-skills.md、ref-subagents.md、ref-commands.md、ref-memory.md、ref-mcp.md、ref-settings.md が「本文」。 Claudeは引数を見て、必要なファイルだけ読みに行く。全部の情報を常にロードしてない。コンテキストの無駄遣いゼロ。 この「SKILL.md = 軽い目次、refファイル = 重い本文」というパターン、実はベスプラ自体が推奨してるスキル設計そのもの。自分のコマンドが、自分が参照するベスプラのルールに従ってる。メタ、、 元ネタのリポから一番刺さった内容3つ shanraisshanのリポ、副題が「from vibe coding to agentic engineering — practice makes claude perfect」。Boris Cherny(Claude Code開発責任者)含めAnthropic中の人たちや、コミュニティの一次情報がまとまってる。 82個のTipsから、特に「あ、これ知らなかった」と思ったもの。 Command → Agent → Skill の3層構造 解決優先度は Skill → Agent → Command。「まずSkillでできないか考えろ」。 自分は最初Commandばかり作ってたけど、途中から大量にSkillに移行した。Commandはユーザーが明示的に呼ばないと動かない。Skillならdescriptionにトリガーワードを書いておけばClaudeが勝手に使ってくれる。 CLAUDE.mdの削除テスト 「この行を消したらClaudeがミスする? → Noなら削除」。CLAUDE.mdは全ターンで読まれる。行数 × ターン数 = 総コスト。無駄な行を削るだけでコンテキストが空く。自分のCLAUDE.md、これやったら3割くらい減りました。 公式コマンドが69個ある /compact、/clear、/model、/cost しか使ってなかった。/effort(エフォートレベル変更)、/rewind(会話を巻き戻し)、/btw(メインタスク中に割り込み)、/passes(マルチパスレビュー)。存在すら知らなかった。 ローカル方式 vs GitHub毎回fetch方式 「これってGitHubから毎回最新取ってくるの?ローカル?」って聞かれた。 ローカルコピー方式にしました。理由は速度。GitHubに毎回fetchしに行くと数秒かかるけど、ローカルファイルなら即時。オフラインでも動く。 ただし最新性はトレードオフ。GitHubで更新があっても、ローカルは古いまま。解決策は update.sh を書いた。 bash ~/.claude/skills/cc-best-practice/update.sh これ叩くと6ファイル全部をGitHubから取得し直して、差分があったやつだけ上書き。先頭に Source URL と Last sync タイムスタンプが自動で入る。 週1で自動実行したい人はcronで十分: 0 9 * * 1 bash ~/.claude/skills/cc-best-practice/update.sh 自分で「/○○」コマンドを作る方法 /ベスプラを作った手順、そのまま書きます。 1. 元ネタを見つける(GitHubリポ、社内ドキュメント、なんでもいい) 2. ~/.claude/skills/[名前]/ ディレクトリを作る 3. SKILL.md を書く(frontmatter + ルーティング + refファイルへの導線) 4. 参照ファイルを配置(ref-*.md) 5. user-invocable: true にする(/メニューに出す) 6. description にトリガーワードを入れる(自動起動用) 特別なコードは要らない。SKILL.mdとrefファイルだけ。 自分はこの方法で88個のコマンドを作ってます。/ohayo(朝のブリーフィング)、/ベスプラ、/article(記事生成)、/invoice(請求書作成)。繰り返し参照する情報は全部コマンドにしちゃえばいい。 今回のワークフロー、他のGitHubリポでも再現できる。 1. バズってるGitHubリポを見つける(Star 1万以上、参照価値が高い) 2. Claude Codeに「このリポを全部読んでスキルにまとめて」 3. カテゴリ分けは Claude に任せる(大体いい感じにしてくれる) 4. user-invocableで /リポ名 に割り当てる 「/○○」って打つだけで必要な情報が出てくる環境、一度作ると戻れないです... 元ネタ: https://github.com/shanraisshan/claude-code-best-practice
原文を表示 / Show original
「スキルってどう言う構造で書くのがいいんだっけ」 Claude Codeでスキルを作ろうとするたびにこれが起きる。 descriptionの推奨文字数は?modelフィールドの選択肢は? user-invocableとdisable-model-invocationの違いは?てかそもそも今作ってるスキルって構造大丈夫?な? 毎回GitHubを開いて調べてました。笑 ある日Claude Codeに「ベスプラのコマンドある?解説記事作りたい」って振ったら、「ないです」って言われた。 「え、じゃあそもそも作って、それ記事にしよう」って話になって、有名な「shanraisshan/claude-code-best-practice」の内容を全部読ませて、「/ベスプラ」ってタイプするだけで引けるスキルにした。 作業時間は約12分。もうGitHubを開く必要がない、、! きっかけ — 「記事にしよう」が「先に作ろう」に変わった瞬間 本当は、すでにある誰かのツールの解説記事を書くつもりだった。 で、Claude Codeに「ベスプラのコマンドある?」と聞いたら、ローカルに無いと。そこから流れが変わった。 「なら作るか」って思った時点で、これが意外と使える話になった。「記事のネタを探してたら、記事のネタを自分で作ってた」みたいな、、 Claude Codeにshanraisshanのリポを読み込ませて、スキル構造を設計させて、6つのカテゴリにrefファイルを分けて、/ベスプラ skills で呼び出せるようにした。 そして今、その作ったスキル自体が、次にスキルを作る時の参照になってる、、、! 困る → 調べる → また困る のループ 図: 「忘れる → 調べる → また忘れる」の無限ループ スキルを作るたびに同じことを調べてた。 「descriptionは何語以内?」→ 100語。毎ターンロードされるから。 「SKILL.mdは何行まで?」→ 500行。それ以上はrefファイルに分離。 「Agentのfrontmatterって何フィールドある?」→ 16個。でも実際使うのは5個。 「settings.jsonの優先順位は?」→ 5段階。Managed > CLI args > local > shared > user。 全部知ってるはずなのに、毎回忘れる。GitHubのリポを開いて、ディレクトリを辿って、該当ファイルを見つけて、読んで、「あ、そうだった」ってなる。 この「忘れる → 調べる → 思い出す → また忘れる」のループが嫌すぎた。 /ベスプラ の中身 — コマンド1つで全部引ける 図: /ベスプラ 動作フロー 引数に応じて呼び出せる。6カテゴリに分けた。 `/ベスプラ skills` スキル設計のベストプラクティスが出る。frontmatterの13フィールド、2つのスキルパターン(DirectとAgent Skill)、サイズの鉄則(500行以下、description 100語以下)。全部。 `/ベスプラ subagents` エージェント設計。16フィールド、公式Agent 5つ、使うべき場面と使うべきでない場面の判断基準。 `/ベスプラ memory` CLAUDE.mdの書き方。Ancestor Loading(上方向・即時)とDescendant Loading(下方向・遅延)の違い。削除テスト(「この行を消したらClaudeがミスする?」→ Noなら削除)。 `/ベスプラ settings` 60以上の設定、5段階の優先順位。 `/ベスプラ mcp` 推奨MCPは4-5個で十分。「15個入れたけど結局4つしか使ってない」(Reddit 682 upvotes)。 `/ベスプラ commands` スラッシュコマンドの設計パターン。引数処理、自動起動、チーム共有。 引数なしで「/ベスプラ」だけ打てば全体概要。 活用事例1: 新しいスキル作る時 具体的に自分がどう使ってるか書 「AI動画生成スキル作ろう」って思った時。まず /ベスプラ skills で設計ルール全部引く。 frontmatterは何書く? → nameとdescriptionは必須、あとはuser-invocableとargument-hint descriptionの文字数は? → 100語以内 SKILL.md本体は? → 500行以内、それ超えたらrefファイルに分離 ファイル構造は? → SKILL.md + assets/ + scripts/ + references/ で、Claudeが「この構造で作ります」って提案してくれる。自分が手動でルール確認する時間がゼロになる。 5-10個スキル作ってる人なら、これだけで累計数時間の節約になってるはず。 活用事例2: CLAUDE.md の肥大化を止める時 半年くらい放置してたらCLAUDE.mdが800行超えた。 /ベスプラ memory で呼び出すと、削除テストのロジックが出る。 「この行を消したらClaudeがミスする? → Noなら削除」 これをClaudeに並列で全行判定させる。~/開発/xxx/CLAUDE.md の全行をレビューして、削除候補と残す理由を分類してもらう。 結果、800行 → 540行まで削れた。ターンごとに260行分のトークンを節約できる計算。 このプロンプトを組むときも、/ベスプラ memory で「Ancestor Loading」「Descendant Loading」の挙動を確認しながらやる。 活用事例3: サブエージェント設計を考える時 「このタスク、サブエージェントに投げた方がいいのか、メインコンテキストで続けた方がいいのか」 /ベスプラ subagents で判断基準が出る: ✅ 中間出力が多くて結論だけ欲しい → サブエージェント ✅ 別コードベースを読み込む必要がある → サブエージェント ❌ ユーザーと対話しながら進める → メインコンテキスト ❌ 進捗をリアルタイムで見たい → メインコンテキスト 公式Agent 5つ(general-purpose、statusline-setup、output-style-setup等)の使い分けと、自作Agentのfrontmatter 16フィールドの意味も出る。 自分はこれ見てから「サブエージェントを投げすぎてた」問題に気づいた。中間出力が少ないタスクはメインで続けた方がトークン効率いい。 活用事例4: 新しいClaude Codeバージョンの新機能追い Claude Codeは頻繁にアップデートされる。毎回リリースノートを追うのは無理。 /ベスプラ commands を引くと、存在する公式コマンド69個が全部出る。自分がバージョンアップで気づかずに使えるようになってた機能がボロボロ見つかる。 /effort — エフォートレベル変更(low/medium/high/max) /rewind — 会話を巻き戻し /btw — メインタスク中に割り込み質問 /passes — マルチパスレビュー /think、/thinkdeep、/thinkultra — 思考量コントロール 69個中、実用してるのは10個程度。残りの59個も「いつか使うかも」でストックしておける。 中身はめちゃくちゃシンプル 図: SKILL.md + 6つのrefファイル構成 ~/.claude/skills/cc-best-practice/ の中にSKILL.mdと参照ファイル6個、これだけ。 SKILL.mdは「目次」。引数を見て、どのrefファイルをReadするかだけ。 ref-skills.md、ref-subagents.md、ref-commands.md、ref-memory.md、ref-mcp.md、ref-settings.md が「本文」。 Claudeは引数を見て、必要なファイルだけ読みに行く。全部の情報を常にロードしてない。コンテキストの無駄遣いゼロ。 この「SKILL.md = 軽い目次、refファイル = 重い本文」というパターン、実はベスプラ自体が推奨してるスキル設計そのもの。自分のコマンドが、自分が参照するベスプラのルールに従ってる。メタ、、 元ネタのリポから一番刺さった内容3つ shanraisshanのリポ、副題が「from vibe coding to agentic engineering — practice makes claude perfect」。Boris Cherny(Claude Code開発責任者)含めAnthropic中の人たちや、コミュニティの一次情報がまとまってる。 82個のTipsから、特に「あ、これ知らなかった」と思ったもの。 Command → Agent → Skill の3層構造 図: Claude Code 3層構造 解決優先度は Skill → Agent → Command。「まずSkillでできないか考えろ」。 層起動コンテキスト再利用性Command明示呼び出し(`/xxx`)現在のコンテキストに挿入低Agent明示呼び出し or 自動委譲独立したコンテキスト中Skill自動(descriptionで判定)現在のコンテキストに挿入高 自分は最初Commandばかり作ってたけど、途中から大量にSkillに移行した。Commandはユーザーが明示的に呼ばないと動かない。Skillならdescriptionにトリガーワードを書いておけばClaudeが勝手に使ってくれる。 CLAUDE.mdの削除テスト 図: 削除テストのロジック 「この行を消したらClaudeがミスする? → Noなら削除」。CLAUDE.mdは全ターンで読まれる。行数 × ターン数 = 総コスト。無駄な行を削るだけでコンテキストが空く。自分のCLAUDE.md、これやったら3割くらい減りました。 公式コマンドが69個ある /compact、/clear、/model、/cost しか使ってなかった。/effort(エフォートレベル変更)、/rewind(会話を巻き戻し)、/btw(メインタスク中に割り込み)、/passes(マルチパスレビュー)。存在すら知らなかった。 ローカル方式 vs GitHub毎回fetch方式 図: ローカル vs fetch 方式比較 図: update.sh 動作フロー 「これってGitHubから毎回最新取ってくるの?ローカル?」って聞かれた。 ローカルコピー方式にしました。理由は速度。GitHubに毎回fetchしに行くと数秒かかるけど、ローカルファイルなら即時。オフラインでも動く。 ただし最新性はトレードオフ。GitHubで更新があっても、ローカルは古いまま。解決策は update.sh を書いた。 bash ~/.claude/skills/cc-best-practice/update.sh これ叩くと6ファイル全部をGitHubから取得し直して、差分があったやつだけ上書き。先頭に Source URL と Last sync: 2026-04-17 18:53 みたいなタイムスタンプが自動で入る。 週1で自動実行したい人はcronで十分: 0 9 * * 1 bash ~/.claude/skills/cc-best-practice/update.sh 自分で「/○○」コマンドを作る方法 図: 自作88コマンドの内訳 /ベスプラを作った手順、そのまま書きます。 元ネタを見つける(GitHubリポ、社内ドキュメント、なんでもいい) ~/.claude/skills/[名前]/ ディレクトリを作る SKILL.md を書く(frontmatter + ルーティング + refファイルへの導線) 参照ファイルを配置(ref-*.md) user-invocable: true にする(/メニューに出す) description にトリガーワードを入れる(自動起動用) 特別なコードは要らない。SKILL.mdとrefファイルだけ。 自分はこの方法で88個のコマンドを作ってます。/ohayo(朝のブリーフィング)、/ベスプラ、/article(記事生成)、/invoice(請求書作成)。繰り返し参照する情報は全部コマンドにしちゃえばいい。 フレームワークとしてのヒント 図: 他のGitHubリポをスキル化する再現パターン 今回のワークフロー、他のGitHubリポでも再現できる。 バズってるGitHubリポを見つける(Star 1万以上、参照価値が高い) Claude Codeに「このリポを全部読んでスキルにまとめて」 カテゴリ分けは Claude に任せる(大体いい感じにしてくれる) user-invocableで /リポ名 に割り当てる 「忘れる → 調べる」のループ解消 例えば awesome-chatgpt-prompts、system-design-primer、30-seconds-of-code とか。自分もそういうスキル型のナレッジベース、今後増やしていきたい。 「/○○」って打つだけで必要な情報が出てくる環境、一度作ると戻れないです... 🔗元ネタ: https://github.com/shanraisshan/claude-code-best-practice 今週末!!Claude Codeを6時間、徹底解説するウェビナーを開催します!! 見てるだけでまだしっかり触れてない人はこちらからぜひ。 4000円で特典もたくさんついてくるので、業界内でもかなりコスパ良く購入することが可能です! アーカイブやエージェントスキル配布などもあるのでぜひClaude Codeを導入するきっかけになれば嬉しいです! すぐる | ChatGPTガチ勢 𝕏 @SuguruKun_ai · Mar 27 待望の「Claude Code講座」開催します!! ㅤ 申し込み: https:// luma.com/calendar/cal-f a2Z7teed3RVQOS … ㅤ ここ半年、自分の業務ほぼ全部これで回してて コンサルもリサーチも執筆もSNSも請求書も、少数で何十社も捌けてるのは 正直Claude Code様のおかげです ㅤ で、「どうやってるの?」って聞かれすぎるので Show more 23 94 818 346K 【役員・DX担当者向け】Claude Codeを「自分で使える」ようになるマンツーマン指導塾も 経営者・リーダー層向けに、Claude Codeのマンツーマン指導塾を始めました。 ・週1回のハンズオン ・全12回で業務自動化AIエージェントを自作 ・講義は課題に合わせカスタマイズ 画面共有で一緒に手を動かすから、初心者でも心配なし! すぐる | ChatGPTガチ勢 𝕏 @SuguruKun_ai · Mar 24 経営者・リーダー層が Claude Codeを「自分で使える」ようになる マンツーマン指導塾を始めます! ㅤ ・週1回 のハンズオン ・全12回で業務自動化AIエージェントを自作 ・講義は課題に合わせカスタマイズ ㅤ 画面共有で一緒に手を動かすから 初心者でも心配なし。 ㅤ 先着3社モニター価格で受付中 3 4 76 27K AI情報を追うならフォロー 👉 @SuguruKun_ai 法人向けClaude Code研修や登壇などはこちら 👉 https://uravation.com/contact/

AIFCC — AI Fluent CxO Club

読み書きそろばん、AI。経営者が AI を自分で動かせるようになるコミュニティ。

Claude Code「ベスプラ」スキルを12分で自作した話 | AIFCC