/note/tech

有名企業や一流開発者のノウハウをそのまま持ち込める、Claude Codeスキル11選

要約:

■ 1. Claude Codeスキルの概要と選定基準

  • スキルとは:
    • 決まった手順やルールをフォルダ/ファイルにまとめておく仕組み
    • 必要な場面でClaude Codeが自動的に読み込む
    • Sentry社のコードレビュー基準のような他社のノウハウを自分のプロジェクトにそのまま適用できる
  • GitHubでの大量公開:
    • Karpathy氏のLLMコード生成の欠陥を避ける原則が公開されている
    • Matt Pocock氏の要件定義からレビューまでの進め方が公開されている
    • Addy Osmani氏のWebサイト品質監査の基準が公開されている
  • オープンソースとの類似性:
    • 優秀なエンジニアがノウハウをスキルとして公開し、利用者のフィードバックで改善されていく
    • ライブラリをインストールする感覚で開発ナレッジを自分の環境に持ち込める
  • スキルの経緯:
    • 2025年10月に発表され、同年12月にAIの種類を問わない共通仕様として公開された
    • 公開数が増えすぎて、どれを入れるべきか判断がつかない状況にある
  • 選定基準:
    • 他のスキルやClaude Code本体の機能では代わりがきかない点があるかどうか
    • 各スキルはそのスキルにしかできないことを中心に紹介する

■ 2. getsentry/skills

  • 概要:
    • Sentry社が自社の開発チームで実際に使っているスキルを公式に公開したスキル集
    • 個人開発では自分のコードのセキュリティやパフォーマンスの問題に気づきにくい
  • フレームワーク特化のレビュー観点:
    • django-access-reviewはDjangoにおけるIDORに絞ってチェックする
    • IDORは権限の設定ミスで本来アクセスできないデータが見えてしまう脆弱性
    • django-perf-reviewはN+1問題に絞ってチェックする
    • N+1問題はデータを1件ずつ取得するせいでDBへの問い合わせが大量に発生する問題
  • 実運用由来の強み:
    • Djangoで大規模サービスを運用するSentry社の実際のレビュー観点がもとになっている
    • 画面上は普通に動くため気づきにくい、他ユーザーのデータが見える問題を拾える
  • その他の収録スキル:
    • find-bugsはブランチの差分からロジックエラーや脆弱性を探す
    • commitはGitのコミットメッセージを一貫した形式で書く
    • iterate-prはCIが通りレビュー指摘が片付くまで修正を繰り返す
  • 注意点:
    • django系スキルはDjango前提のため、他のフレームワークではそのまま使えない
    • Opusなどにスキルの中身を任意の言語向けにカスタマイズさせるとよい

■ 3. ui-ux-pro-max-skill

  • 概要:
    • AIっぽいテンプレート感のある配色を避けるための業界別スタイル・カラーパレット集
    • デザイナー不在でAIにUIを作らせる場面で有効
  • デザインデータベースの保持:
    • AIのセンスに任せず、スキル自体がデザインのデータベースを持つ
    • 「フィンテックのダッシュボード」等を伝えると業界ルールに沿った組み合わせを探す
    • スタイル・配色・フォントの組み合わせに加え、業界で避けるべきデザインまで提案する
  • デザインシステムの書き出し:
    • 決まった内容をプロジェクト内にデザインシステムのファイルとして書き出せる
    • ページ追加のたびに配色がぶれることを防げる
  • 無料版のボリューム:
    • 84種類のUIスタイル(グラスモーフィズム、ブルータリズム等)
    • 192種類の業界別カラーパレット
    • 74種類のフォントの組み合わせ
    • 22種類のフレームワーク別コード出力
  • アクセシビリティ対応:
    • WCAG AAに準拠したコントラスト比の担保が自動で組み込まれる
    • キーボード操作への配慮も自動で組み込まれる
  • 注意点:
    • ロゴやオリジナルのビジュアル素材の生成には有料のプレミアム版が必要

■ 4. andrej-karpathy-skills

  • 概要:
    • Karpathy氏が指摘したLLMのコーディングにありがちな欠陥をもとにまとめたもの
    • 曖昧な指示で丸投げするとAIが勝手な前提で書き始め、やり直しが発生する
  • コードを書く前の振る舞いを変える:
    • 書き終わったコードを後から整理するのではない
    • 推測での実装や頼んでいない箇所の書き換えを最初から防ぐ
  • 4つの原則:
    • Think Before Coding: 推測で実装せず前提を確認してから進める
    • Simplicity First: 将来を見越した不要な抽象化を入れない
    • Surgical Changes: 関係ない箇所を書き換えない
    • Goal-Driven Execution: テストが通るまで自律的にループする
  • 構成:
    • 中身はCLAUDE.mdに書くルールが中心
    • Cursor向けのルールファイルも同梱され、両ツールで同じ規律を適用できる
  • 注意点:
    • タイポ修正のような単純作業でも確認のやり取りが増える
    • 体感速度が落ち、トークン消費量が増える
    • 大きめの変更や修正の際に明示的に使うとよい

■ 5. web-quality-skills

  • 概要:
    • ChromeチームのAddy Osmani氏が公開した、表示速度やアクセシビリティのチェックスキル
    • モバイル表示が遅く検索順位が上がらない原因を自分で特定できない問題に対応する
  • 評価観点:
    • 「動くか」ではなく「速いか・誰にとっても使いやすいか」を見る
    • Performance・Accessibility・SEO・Best Practicesの4軸で採点する
    • LCPやCLSといったCore Web Vitalsを基準とする
  • 実測による評価:
    • ブラウザ操作できる環境があればLighthouseで実際に計測する
    • 「計測で確認できた問題」と「コードから推測される問題」を分けて報告する
  • アクセシビリティ問題の検出:
    • 視覚障害や色覚特性のある人にとって使いにくい箇所を見つける
    • 入力欄に説明ラベルがない、背景と文字の色が近すぎる等の問題が対象
    • 修正方法のコードまで提案する

■ 6. caveman

  • 概要:
    • Julius Brussee氏が公開した、トークン消費を抑えるためのスキル
    • AIの応答から挨拶、前置き、言い換えの繰り返しを削り、結論だけを短く返させる
    • CLAUDE.mdのようなAIに読み込ませるファイルの圧縮も可能
  • 背景にある問題:
    • 長い作業でコンテキストが埋まり、会話の自動圧縮や利用上限への早期到達が起きる
    • 原因の一部はAI自身の丁寧すぎる応答
    • 前置きや言い換えもすべてトークンとしてコンテキストに積み上がる
  • 圧縮レベル:
    • ultraでは「New object ref each render. Wrap in useMemo.」のように結論と修正箇所だけが1行で返る
    • lite: 軽めに簡潔化
    • full: 標準、無駄を削りつつ内容は保つ
    • ultra: 最大限に圧縮
    • wenyan: 漢文調で最大効率
  • /caveman-compress:
    • CLAUDE.mdのようなルールファイルは会話開始ごとに毎回読み込まれ、作業前からコンテキストを消費する
    • ルールの中身はそのままに文章を約46%圧縮した版に書き換える
    • 一度圧縮すれば以降のセッションはその分コンテキストが空いた状態で始まる
    • 応答短縮モードと組み合わせると入力と出力の両側から消費を抑えられる
  • /caveman-commit:
    • コミットメッセージを50文字以内の簡潔な形で書く
  • 使い分け:
    • エラー原因だけを知りたいときや長時間作業でコンテキストを温存したいときはultraを使う
    • 設計をじっくり相談したいときは通常モードに戻す
  • 注意点:
    • 説明が削られる分、AIがその修正を選んだ背景が読み取りにくくなる
    • 理解しながら進める場面は通常モード、手を動かす場面はcavemanという割り切りがよい

■ 7. mattpocock/skills

  • 概要:
    • Matt Pocock氏が公開した、要件定義・実装・テスト・レビューまでをカバーするスキル集
    • 曖昧なアイデアのまま実装を進め、AIが文脈を見失って挙動が崩れる失敗パターンに対応する
  • ドキュメントを軸にした一気通貫の進行:
    • 設計時にドキュメントを作り、それを軸に設計からタスク分割、レビューまで進める
  • /grill-with-docs:
    • AIが設計上のトレードオフを質問してくる
    • 決定事項をADR(設計の意思決定記録)や用語集ファイルに書き込む
  • /to-tickets:
    • 固まった仕様を小さな作業単位に分割する
  • /code-review:
    • 仕様に照らしてレビューを行う
    • 「リポジトリの規約順守」と「元の仕様どおりの実装」を別々のサブエージェントが並行チェックする
    • バグの有無だけでなく、頼んだものが作られているかまで確認する
  • ドキュメント参照の利点:
    • どの工程も設計時のドキュメントを参照するため、途中で方向がぶれにくい
    • 人間も同じドキュメントで、どういう前提で作られたかをあとから見直せる
  • 注意点:
    • 一連の流れを踏む分、ちょっとした修正にも一手間かかる
    • 小規模な変更には重たく感じる場合がある

■ 8. claude-skills

  • 概要:
    • 法務、マーケティング、経営分析まで含む388個の実践的スキルと大量のPythonツールのパッケージ
    • ツールごとにルールを個別管理し直す手間を解消する
  • 13種類のAIツールでの使い回し:
    • Claude Codeに加え、CodexやGemini CLIに標準対応する
    • 同梱のconvert.shでCursor・Windsurf・Aider等の形式にもまとめて書き出せる
  • 開発以外の領域の厚さ:
    • マーケティング、財務分析、GDPRやSOC 2等のコンプライアンス関連まで含む
  • Virtual C-Suite:
    • CTO・CFO・CMOなど役割ごとの仮想アドバイザーが互いの視点から意見を検証し合う機能

■ 9. cavekit

  • 概要:
    • Julius Brussee氏が公開した軽量なプラグイン
    • SPEC.mdという1枚のファイルに要件と進捗を集約する
    • SPEC.mdを起点にAIが自律的にビルドとテストを繰り返す
    • 長い会話でコンテキストが埋まり、AIが決定事項を見失う問題に対応する
  • 作業状態をファイルに保持:
    • 目標・制約・タスク・バグの情報をすべてリポジトリ直下のSPEC.mdに書く
    • AIは毎回SPEC.mdを読んで作業を進める
  • 再開性と可視性:
    • 会話の満杯、リセット、別日の新セッションでもSPEC.mdを読み直せば同じ場所から再開できる
    • 進捗が人間にも読める形で残り、AIの到達点を自分の目で確認できる
  • 作業の流れ:
    • /ck:grillで要件を1問1答形式で詰める
    • /ck:buildで計画から実行まで進める
    • テスト失敗の原因はSPEC.mdのバグ欄に自動で書き戻される
    • 同種のバグを繰り返さないためのルールとして仕様書に蓄積される
  • 活用場面:
    • セッションをまたぐ作業で、リセット後もSPEC.mdだけ見せれば続きから再開できる
  • 注意点:
    • 仕様が1枚に集約されるため、複数人で同時に同じ仕様書を触る使い方には向かない

■ 10. ECC

  • 概要:
    • 計画・実装・レビュー等の役割ごとに専門化した多数のサブエージェントを使い分ける開発システム
    • 複数人開発でAIが設定ファイルを勝手に書き換えたり、コードを誤削除したりするリスクに対応する
  • 設定済みセットとしての提供:
    • 対策を一から書かずに済む設定済みのセットとして手に入る
  • サブエージェント(68個):
    • planner、architect、code-reviewer、security-reviewerを含む
    • build-error-resolver、refactor-cleaner、e2e-runnerを含む
  • フック:
    • 設定ファイルの書き換えを防ぐ
    • 作業の終わりにフォーマットと型チェックを走らせる
    • 編集したファイルにconsole.logが残っていたら警告する
  • ルール:
    • コーディングスタイル、Git運用、テスト、セキュリティ、パフォーマンス等の共通ルール
  • 自作した場合の作業量:
    • エージェントごとの役割と指示、フックのスクリプト、チームのルール文書の作成が必要
    • それだけで一つのプロジェクトになるほどの作業量
  • 言語別ルールパック:
    • TypeScript・Python・Go等の言語ごとに分かれ、使う言語のものだけを選んで導入できる

■ 11. notebooklm-py

  • 概要:
    • GeminiNotebook(旧NotebookLM)をブラウザ操作なしで操作できるようにする非公式API
    • Python、CLI、Claude Code等のエージェントから直接操作できる
    • ライブラリの古い書き方や存在しないオプションを提案されエラーから抜け出せない問題に対応する
  • ハルシネーション抑制:
    • ClaudeにGeminiNotebookへ質問させ、信頼できるソースから答えを取り出せる
    • GeminiNotebookは入れたソースだけをもとに回答し、根拠の資料も示す
  • 活用方法:
    • 使用中のライブラリやフレームワークの公式ドキュメントだけを入れたノートブックを用意する
    • Claudeが行き詰まったときに質問させ、公式ドキュメントに基づく回答で修正を進める
  • 導入:
    • Claude Code向けスキルが同梱され、notebooklm skill installで導入できる
    • 「詰まったらノートブックに聞いて」と頼むだけでClaudeが自ら質問する
  • 開発以外での活用:
    • 事業戦略の壁打ちで市場全体の情報をGeminiNotebookに入れておく
    • 必要に応じてClaudeにGeminiNotebookへ質問させ、真偽確認や情報補足を行う
  • 注意点:
    • Googleが公式に提供していない非公式APIを使っている
    • Google側の仕様変更で突然動かなくなったり利用制限がかかったりするリスクがある
    • 自己責任での利用が必要

■ 12. awesome-claude-skills

  • 概要:
    • Claude Code、Claude.ai、Codex、Cursor、Gemini CLI等で使える1000個以上のスキル・プラグインのキュレーションリスト
    • GitHub検索では似た名前のリポジトリが大量に出て、実用的なものを見分けにくい問題に対応する
  • 用途別カテゴリでの整理:
    • 1行の説明を読みながら目的のものを探せる
  • 収録例:
    • Document Processing: Word文書を変更履歴やコメントごと編集するdocx
    • Document Processing: PDFからテキストや表を抽出・結合するpdf
    • Development & Code Tools: MCPサーバーの作り方をガイドするMCP Builder
    • Data & Analysis: CSVの傾向をまとめるCSV Data Summarizer
    • Data & Analysis: PostgreSQLに読み取り専用SQLだけを安全に投げるpostgres
    • Business & Marketing: 広告ライブラリから競合広告を集めて分析するCompetitive Ads Extractor
    • Business & Marketing: サービス名に合うドメイン名候補を出すDomain Name Brainstormer
    • Communication & Writing: 会議の文字起こしから話し方の傾向を分析するMeeting Insights Analyzer
    • Productivity & Organization: 請求書や領収書を確定申告用に整理するInvoice Organizer
    • Productivity & Organization: 求人票に合わせて履歴書を書き分けるTailored Resume Generator
  • SaaS自動化スキル:
    • 運営元のComposio社ならではの、Jira・Linear・Slack・Gmail・GitHub・HubSpot等のSaaS別自動化スキル
    • AIのまとめた情報を手作業でSlackやチケットに転記する一手間を解消する
  • MCP Gateway経由の接続:
    • Composio社のMCP Gatewayを経由し、1000種類以上のアプリとOAuthで安全に接続できる
    • 生のAPIキーをAIに直接渡さずに済む
  • Chrome Relay:
    • ログイン済みのChromeセッションをCLI経由でAIに操作させられる
  • 推奨される使い方:
    • 業務に合うものが見当たらない場合や開発以外の作業を楽にしたい場合は、まずこのリストを眺める
    • カテゴリ単位で見ると、思いつかなかったスキルの使い道に出会える

■ 13. 導入の考え方

  • 段階的な導入:
    • 11個のスキルは入れれば入れるほど良いものではない
    • 実際につまずいている部分に効くものから1つずつ試すのがちょうど良い導入方法