Claude Code Skillsに入門しよう！
Agent Skills
Claude CodeにはSkillsという仕組みがある。Claudeに特定の知識やワークフローを教え込むことができる機能だ。
VercelやAnthropicが提供する公式Skillsを使っている人も多いと思うが、実は自分でゼロから作ることもできる。
今回はskill-creatorのような補助ツールを使わず、手動でSkillsを作成する方法を解説する。
:::note info
skill-creatorはClaude.aiで使用できるプラグインで、
「このSkillを作りたい」と説明するだけでSKILL.mdの雛形を生成してくれる。
自力でやるのが面倒な方はそちらからとりあえず作ってみて、Skillsの第1歩を踏み出すのもいいだろう。
:::
そもそもSkillsって何？
Skillsは、Claudeに専門知識やワークフローを追加するための仕組みだ。
例えば「うちの会社ではこういう用語を使っている」「UIはこのガイドラインに従って」といった情報をSkillとしてまとめておくと、Claudeがそれを参照しながら作業してくれる。
ポイントは、Claudeが自動的に「このタスクにはあのSkillが必要だな」と判断して読み込んでくれること。毎回プロンプトで説明する必要がない。
公式ドキュメントにはこう書かれている。
Skills extend what Claude can do. Create a SKILL.md file with instructions, and Claude adds it to its toolkit. Claude uses skills when relevant, or you can invoke one directly with /skill-name.
作成するだけでSkillsをClaudeCodeが必要に応じて呼び出すことも、/skill-nameのように明示的に呼び出すこともできるというわけだ。
Skillsが効果的な場面
公式ガイドによると、Skillsは以下の3つのカテゴリで特に効果を発揮する。
カテゴリ1: ドキュメントと資産の作成
- 一貫性のある高品質な出力（docx、pptx、デザインなど）
- 例：フロントエンドデザインスキル、Officeスキル
カテゴリ2: ワークフロー自動化
- 一貫した方法論から恩恵を受ける複数ステップのプロセス
- 例：スキルクリエータースキル
カテゴリ3: MCP強化
- MCPサーバーが提供するツールアクセスにワークフローガイダンスを追加
- 例：Sentryのsentry-code-reviewスキル
本記事で行う実践例（社内用語集、UIデザインガイドライン）はカテゴリ1に該当する。
Skillsの保存場所
Skillsには2種類の保存場所がある。
Personal Skills
~/.claude/skills/
ここに置いたSkillsは、すべてのプロジェクトで使える。個人的なワークフローや好みの設定を入れておくのに向いている。
Project Skills
.claude/skills/
プロジェクトのルートディレクトリに置く。gitで管理すればチームで共有できる。
プロジェクト固有のルールやガイドラインはここに入れるのがよさそうだ。
Progressive Disclosure（段階的開示）の3層構造
Skillsを理解する上で最も重要な概念が「Progressive Disclosure（段階的開示）」だ。
Skillsは3層のシステムで設計されている。
第一層（YAMLフロントマター）
- 常にClaudeのシステムプロンプトに読み込まれる
- 「このSkillをいつ使うべきか」の判断材料
- 軽量に保つ必要がある
---
name: skill-name
description: この部分の記述をフロントマターと呼ぶ
---
第二層（SKILL.md本文）
- Claudeがスキルを使うと判断したときに読み込まれる
- 完全な指示とガイダンスを記述
第三層（リンクされたファイル）
- references/やscripts/内のファイル
- Claudeが必要に応じてナビゲートして読み込む
この仕組みにより、専門知識を維持しながらトークンの使用を最小限に抑えることができる。
ディレクトリ構成を理解する
Skillsのディレクトリ構成は以下のようになっている。
skill-name/
├── SKILL.md # 必須：メインの指示ファイル
├── scripts/ # 任意：実行可能なコード
│ └── helper.py
├── references/ # 任意：参照用ドキュメント
│ └── detailed-guide.md
└── assets/ # 任意：出力に使うファイル
└── template.txt
命名規則（重要）
フォルダ名とファイル名には厳格なルールがある。
フォルダ名：
notion-project-setup ✅ ケバブケース
company-glossary ✅ ケバブケース
Notion Project Setup ❌ スペース禁止
notion_project_setup ❌ アンダースコア禁止
NotionProjectSetup ❌ 大文字禁止
SKILL.mdファイル名
- 必ず
SKILL.md（大文字小文字を区別） -
skill.md❌
また、スキルフォルダ内にREADME.mdを含めてはいけない。
すべてのドキュメントはSKILL.mdまたはreferences/に入れる。
GitHubで配布する場合は、リポジトリのルートにREADMEを置くようにしよう。
次はそれぞれのディレクトリの役割を見ていこう。
SKILL.md（必須）
Skillの本体。YAMLフロントマターとMarkdownで構成される。
---
name: skill-name
description: このSkillが何をするか、いつ使うべきかを書く
---
# スキル名
## 使い方
ここに指示を書く
nameとdescriptionは必須。
特にdescriptionが重要で、Claudeはここを見て「このSkillを使うべきか」を判断する。
scripts/（任意）
PythonやBashなどの実行可能なスクリプトを置く場所。
descriptionやSKILL.mdに「このルールを守ってね」と記載するよりも、スクリプトに任せて確実な実行を担保することが推奨されている。
scripts/
├── analyze.py # 解析用スクリプト
├── validate.py # バリデーション用
└── convert.sh # 変換用シェルスクリプト
SKILL.mdからはこんな感じで参照する。
## 解析の実行
以下のコマンドを実行してください
```bash
python scripts/analyze.py input.pdf
```
期待される出力：解析結果のJSONファイルが生成される
「期待される出力」を書くのがポイント。何が成功なのかを明示することで想定していない動作を防ぐことができる。
references/（任意）
詳細なドキュメントや参照資料を置く場所。
SKILL.mdに全部書くとコンテキストを圧迫するので、詳細は別ファイルに分けてClaudeが必要なときだけ読み込むようにする。これが先述の「第三層」だ。
references/
├── api-reference.md # APIリファレンス
├── troubleshooting.md # トラブルシューティング
└── examples.md # 具体例集
SKILL.mdからはリンクで参照する。
詳細なAPIリファレンスは
[references/api-reference.md](references/api-reference.md)
を参照してください。
assets/（任意）
テンプレートやアイコン、フォントなど、出力に使うファイルを置く場所。
assets/
├── template.docx # ドキュメントテンプレート
├── logo.png # ロゴ画像
└── config.json # 設定ファイル
例えばレポート生成Skillなら、会社のテンプレートをここに置いておくと便利だ。
YAMLフロントマターの詳細
フロントマターはClaudeがSkillを読み込むかどうかを決定する最も重要な部分だ。
必須フィールド
---
name: skill-name-in-kebab-case
description: What it does and when to use it. Include specific trigger phrases.
---
nameフィールド
- ケバブケースのみ（例：
company-glossary） - スペースや大文字は使用しない
- フォルダ名と一致させる
- 64文字未満
descriptionフィールド
- 「何をするか」と「いつ使うか」の両方を含める
- 1024文字未満
- XMLタグ（< >）は含めない（セキュリティ制限）
- ユーザーが言うかもしれない具体的なフレーズを含める
オプションフィールド
---
name: skill-name
description: [必須の説明]
license: MIT
compatibility: Claude Code CLI環境向け。Python 3.10以上が必要。
allowed-tools: "Bash(python:*) Bash(npm:*) WebFetch"
metadata:
author: Your Name
version: 1.0.0
mcp-server: server-name
tags: [productivity, automation]
---
licenseフィールド
- オープンソースで公開する場合に使用
- 一般的：MIT、Apache-2.0
compatibilityフィールド
- 環境要件を示す（1-500文字）
- 例：対象製品、必要なシステムパッケージ、ネットワークアクセスのニーズなど
allowed-toolsフィールド
- Skillが使用できるツールを制限する
- セキュリティ上の理由で特定のツールのみ許可したい場合に使用
- 例：
"Bash(python:*) Bash(npm:*) WebFetch"
metadataフィールド
- 任意のキー-バリューペア
- 推奨：author、version、mcp-server、tags
セキュリティ制限
フロントマターで禁止されていること：
- XMLの角括弧（< >）
- 名前に「claude」または「anthropic」を含むスキル（予約済み）
理由：フロントマターはClaudeのシステムプロンプトに表示される。悪意のあるコンテンツが指示を注入する可能性があるため。
descriptionの書き方（最重要）
Claudeは「どのSkillを使うか」をdescriptionを見て判断している。ここが曖昧だと、必要なときに使ってもらえない。
構造
[何をするか] + [いつ使うか] + [主な機能]
悪い例
# あまりにも曖昧
description: プロジェクトを手伝う
# トリガーが欠けている
description: 洗練されたマルチページのドキュメントシステムを作成する
# 技術的すぎてユーザートリガーがない
description: 階層的な関係を持つプロジェクトエンティティモデルを実装する
良い例
# 具体的かつ実行可能
description: Figmaデザインファイルを分析し、開発者向けの引き渡しドキュメントを生成する。ユーザーが.figファイルをアップロードしたり、「デザイン仕様」「コンポーネントドキュメント」「デザインからコードへの引き渡し」を求めるときに使用する。
# トリガーフレーズを含む
description: スプリント計画、タスク作成、ステータストラッキングを含むLinearプロジェクトワークフローを管理する。ユーザーが「スプリント」「Linearタスク」「プロジェクト計画」と言及したり、「チケットを作成する」と要求したときに使用する。
オーバートリガー対策
Skillsが無関係なクエリに対して読み込まれる場合は、ネガティブトリガーを追加する。
description: CSVファイルの高度なデータ分析。統計モデル、回帰、クラスタリングに使用。
単純なデータ探索には使用しない（代わりにdata-vizスキルを使用）。
実践1：社内用語集スキルを作る
では実際にSkillを作ってみよう。まずはシンプルな社内用語集スキルから。
ディレクトリの作成
mkdir -p ~/.claude/skills/company-glossary && cd ~/.claude/skills/company-glossary
SKILL.mdの作成
---
name: company-glossary
description: 社内用語や略語の意味を提供する。社内用語、略語、専門用語について質問されたとき、またはドキュメントやコードで社内特有の表現を使うときに参照する。「PJって何」「MTGの意味」「部署の略称を教えて」「FYIってどういう意味」などの質問に対応。
---
# 社内用語集
このSkillは社内で使われる用語や略語の定義を提供します。
## 基本用語
| 用語 | 正式名称 | 意味 |
|------|----------|------|
| PJ | プロジェクト | 案件のこと |
| MTG | ミーティング | 会議 |
| ASAP | As Soon As Possible | できるだけ早く |
| FYI | For Your Information | 参考までに |
| TBD | To Be Determined | 未定 |
## プロダクト用語
詳細は [references/products.md](references/products.md) を参照してください。
## 部署・チーム名
詳細は [references/departments.md](references/departments.md) を参照してください。
## トラブルシューティング
### 用語が見つからない場合
1. references/内のファイルを確認
2. 類似の用語がないか検索
3. ユーザーに確認を求める
### 略語が複数の意味を持つ場合
文脈から判断し、不明な場合はユーザーに確認する。
descriptionに具体的なトリガーフレーズ（「PJって何」「MTGの意味」など）を追加しているのがポイントだ。
references/の作成
mkdir -p references
references/products.md
# プロダクト用語集
## サービス名
| 用語 | 説明 |
|------|------|
| ProjectX | 社内の主力プロダクト。顧客管理システム。 |
| AdminPortal | 管理者向けダッシュボード |
| MobileApp | iOS/Android向けモバイルアプリ |
## 技術用語
| 用語 | 説明 |
|------|------|
| Core API | バックエンドの中核API |
| Gateway | APIゲートウェイ。認証とルーティングを担当 |
| DataPipeline | データ処理パイプライン |
references/departments.md
# 部署・チーム名
## 開発部門
| 略称 | 正式名称 | 担当 |
|------|----------|------|
| FE | フロントエンドチーム | Web/モバイルUI |
| BE | バックエンドチーム | API/インフラ |
| QA | 品質保証チーム | テスト/品質管理 |
| SRE | Site Reliability Engineering | 運用/監視 |
## ビジネス部門
| 略称 | 正式名称 | 担当 |
|------|----------|------|
| CS | カスタマーサクセス | 顧客支援 |
| Sales | 営業チーム | 新規開拓/既存顧客 |
| Mkt | マーケティング | 広告/PR |
最終的なディレクトリ構成
company-glossary/
├── SKILL.md
└── references/
├── products.md
└── departments.md
これで完成。Claude Codeを再起動すると、社内用語について質問したときに自動的にこのSkillが参照される。
このSkillsをGitで管理しておけば、新人用の研修コンテンツになるだろう。
もちろんNotebookLMでいいじゃんという意見はおっしゃるとおりだし私もそう思うが、
少なくともこれであなたは自分でSkillsを作るというその第1歩を踏み出したわけだ。
実践2：UIデザインガイドラインスキルを作る
次はもう少し複雑な例。UIデザインのガイドラインをSkillにしてみる。
ディレクトリ構成
ui-design-guidelines/
├── SKILL.md
├── references/
│ ├── colors.md
│ ├── typography.md
│ └── components.md
├── scripts/
│ └── validate_colors.py
└── assets/
└── color-palette.json
SKILL.md
---
name: ui-design-guidelines
description: UIデザインのガイドラインを提供する。UIコンポーネントの作成、スタイリング、カラー選択、タイポグラフィの設定を行うときに参照する。ReactやHTML/CSSでUIを実装する際、「ボタンのスタイル」「カラーパレット」「フォントサイズ」「デザインガイドライン」などを質問されたときに使用する。
---
# UIデザインガイドライン
このSkillは社内のUIデザイン基準を提供します。
## 基本原則
1. 一貫性を保つ：同じ要素には同じスタイルを適用する
2. アクセシビリティを考慮する：コントラスト比4.5:1以上を確保
3. レスポンシブ対応：モバイルファーストで設計
## クイックリファレンス
### カラー
プライマリカラー: `#3B82F6`（Blue 500）
セカンダリカラー: `#10B981`（Green 500）
エラーカラー: `#EF4444`（Red 500）
詳細は [references/colors.md](references/colors.md) を参照。
### タイポグラフィ
フォント: Inter（見出し）、Noto Sans JP（本文）
詳細は [references/typography.md](references/typography.md) を参照。
### コンポーネント
ボタン、フォーム、カードなどの仕様は [references/components.md](references/components.md) を参照。
## カラーバリデーション
カラーコードが正しいか、アクセシビリティ基準を満たすか確認するには：
```bash
python scripts/validate_colors.py "#3B82F6"
```
期待される出力：
- 有効/無効の判定
- 白背景とのコントラスト比
- WCAG AA準拠の可否
## トラブルシューティング
### カラーコードが無効と表示される
原因：HEX形式が不正（#が欠けている、桁数が間違っている）
解決策：#RRGGBB形式で入力する
### コントラスト比が基準を満たさない
原因：背景色と前景色の明度差が不十分
解決策：references/colors.mdで代替カラーを確認
references/の作成
references/colors.md
# カラーパレット
## ブランドカラー
### Primary
| 名前 | HEX | 用途 |
|------|-----|------|
| Primary 50 | #EFF6FF | 背景（ホバー時） |
| Primary 100 | #DBEAFE | 背景（選択時） |
| Primary 500 | #3B82F6 | メインカラー |
| Primary 600 | #2563EB | ホバー時 |
| Primary 700 | #1D4ED8 | アクティブ時 |
### Secondary
| 名前 | HEX | 用途 |
|------|-----|------|
| Secondary 500 | #10B981 | 成功/確認 |
| Secondary 600 | #059669 | ホバー時 |
### Semantic
| 名前 | HEX | 用途 |
|------|-----|------|
| Error | #EF4444 | エラー表示 |
| Warning | #F59E0B | 警告表示 |
| Info | #3B82F6 | 情報表示 |
| Success | #10B981 | 成功表示 |
## グレースケール
| 名前 | HEX | 用途 |
|------|-----|------|
| Gray 50 | #F9FAFB | 背景 |
| Gray 100 | #F3F4F6 | カード背景 |
| Gray 200 | #E5E7EB | ボーダー |
| Gray 500 | #6B7280 | サブテキスト |
| Gray 900 | #111827 | メインテキスト |
references/typography.md
# タイポグラフィ
## フォントファミリー
### 見出し
```css
font-family: 'Inter', sans-serif;
```
### 本文（日本語含む）
```css
font-family: 'Noto Sans JP', 'Inter', sans-serif;
```
## フォントサイズ
| 名前 | サイズ | 行高 | 用途 |
|------|--------|------|------|
| xs | 12px | 16px | 注釈 |
| sm | 14px | 20px | サブテキスト |
| base | 16px | 24px | 本文 |
| lg | 18px | 28px | リード文 |
| xl | 20px | 28px | 小見出し |
| 2xl | 24px | 32px | セクション見出し |
| 3xl | 30px | 36px | ページ見出し |
| 4xl | 36px | 40px | 大見出し |
## フォントウェイト
| 名前 | 値 | 用途 |
|------|-----|------|
| normal | 400 | 本文 |
| medium | 500 | 強調テキスト |
| semibold | 600 | 小見出し |
| bold | 700 | 見出し |
references/components.md
# コンポーネント仕様
## ボタン
### サイズ
| サイズ | padding | font-size | height |
|--------|---------|-----------|--------|
| sm | 8px 12px | 14px | 32px |
| md | 10px 16px | 16px | 40px |
| lg | 12px 20px | 18px | 48px |
### バリアント
```jsx
// Primary
<button className="bg-primary-500 text-white hover:bg-primary-600">
ボタン
</button>
// Secondary
<button className="bg-gray-100 text-gray-900 hover:bg-gray-200">
ボタン
</button>
// Outline
<button className="border border-primary-500 text-primary-500 hover:bg-primary-50">
ボタン
</button>
```
## フォーム
### インプット
```tsx
<input
className="border border-gray-200 rounded-lg px-4 py-2 focus:border-primary-500 focus:ring-2 focus:ring-primary-100"
/>
```
### ラベル
```tsx
<label className="text-sm font-medium text-gray-700">
ラベル
</label>
```
## カード
```tsx
<div className="bg-white rounded-xl shadow-sm border border-gray-100 p-6">
カードコンテンツ
</div>
```
scripts/の作成
scripts/validate_colors.py
#!/usr/bin/env python3
"""カラーコードのバリデーションスクリプト"""
import sys
import re
import json
from pathlib import Path
def validate_hex_color(color: str) -> bool:
"""HEXカラーコードの形式をチェック"""
pattern = r'^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$'
return bool(re.match(pattern, color))
def check_contrast_ratio(color1: str, color2: str) -> float:
"""2色間のコントラスト比を計算（簡易版）"""
def hex_to_luminance(hex_color: str) -> float:
hex_color = hex_color.lstrip('#')
r, g, b = tuple(int(hex_color[i:i+2], 16) / 255 for i in (0, 2, 4))
def adjust(c):
return c / 12.92 if c <= 0.03928 else ((c + 0.055) / 1.055) ** 2.4
return 0.2126 * adjust(r) + 0.7152 * adjust(g) + 0.0722 * adjust(b)
l1 = hex_to_luminance(color1)
l2 = hex_to_luminance(color2)
lighter = max(l1, l2)
darker = min(l1, l2)
return (lighter + 0.05) / (darker + 0.05)
def main():
if len(sys.argv) < 2:
print("Usage: python validate_colors.py <color>")
print("Example: python validate_colors.py '#3B82F6'")
sys.exit(1)
color = sys.argv[1]
if not validate_hex_color(color):
print(f"❌ Invalid color format: {color}")
print("Expected format: #RRGGBB or #RGB")
sys.exit(1)
print(f"✅ Valid color: {color}")
# 白背景とのコントラスト比をチェック
white = "#FFFFFF"
ratio = check_contrast_ratio(color, white)
print(f"Contrast ratio with white: {ratio:.2f}:1")
if ratio >= 4.5:
print("✅ Passes WCAG AA for normal text")
elif ratio >= 3:
print("⚠️ Passes WCAG AA for large text only")
else:
print("❌ Does not meet WCAG AA requirements")
if __name__ == "__main__":
main()
assetsの作成
assets/color-palette.json
{
"primary": {
"50": "#EFF6FF",
"100": "#DBEAFE",
"500": "#3B82F6",
"600": "#2563EB",
"700": "#1D4ED8"
},
"secondary": {
"500": "#10B981",
"600": "#059669"
},
"semantic": {
"error": "#EF4444",
"warning": "#F59E0B",
"info": "#3B82F6",
"success": "#10B981"
},
"gray": {
"50": "#F9FAFB",
"100": "#F3F4F6",
"200": "#E5E7EB",
"500": "#6B7280",
"900": "#111827"
}
}
アプリを作成する上で必要なUIもSkillsに追加すればこのとおり。
すでに決まったデザインがあるなら、Skillsに記載すればコンテキストも大幅に削減しながらデザイン通りにUIを作成することができる。
Skillsのテスト方法
Skillsを作ったら、必ずテストしよう。
基本的には以下の3項目について動作すれば問題ない。
1. トリガーテスト
Skillが適切なタイミングで読み込まれるか確認する。
トリガーされるべきクエリ：
- 「PJって何の略？」
- 「MTGの意味を教えて」
- 「社内用語集を見せて」
トリガーされないべきクエリ：
- 「天気を教えて」
- 「Pythonのコードを書いて」
- 「一般的なビジネス用語を教えて」
デバッグ方法：Claudeに聞いてみる
「company-glossaryスキルはいつ使いますか？」
Claudeがdescriptionを引用するので、欠けている部分に基づいて調整する。
2. 機能テスト
Skillが正しい出力を生成するか確認する。
テスト：PJの意味を質問する
入力：「PJって何？」
期待される結果：
- 用語集スキルが読み込まれる
- 「プロジェクト」という説明が返される
- 追加の関連用語があれば提示される
3. パフォーマンス比較
Skillがベースラインに対して結果を改善するか確認する。
Skillを使用しない場合：
ユーザーが毎回「うちの会社ではPJはプロジェクトの略で...」と説明
複数回のやり取りが必要
Skillを使用した場合：
自動的に用語集を参照
1回の質問で正確な回答
トラブルシューティング
Skillがアップロードされない
エラー：「アップロードされたフォルダーにSKILL.mdが見つかりませんでした」
原因：ファイル名が正確にSKILL.mdではない
解決策：`ls -la`でファイル名を確認し、SKILL.mdに名前を変更
エラー：「無効なフロントマター」
原因：YAMLフォーマットの問題
確認事項：
- `---`で始まり`---`で終わっているか
- クォートが閉じているか
- インデントが正しいか
エラー：「無効なスキル名」
原因：名前にスペースや大文字が含まれている
解決策：ケバブケースに修正（例：`my-cool-skill`）
Skillがトリガーされない
症状：Skillが自動的に読み込まれない
解決策：
1. descriptionに具体的なトリガーフレーズを追加
2. 「何をするか」と「いつ使うか」の両方が含まれているか確認
3. ユーザーが実際に言う言葉を含めているか確認
Skillが頻繁にトリガーされる
症状：無関係なクエリに対してSkillが読み込まれる
解決策：
1. ネガティブトリガーを追加（「...には使用しない」）
2. より具体的なトリガー条件に修正
3. スコープを明確に限定
指示が守られない
症状：Skillは読み込まれるがClaudeが指示に従わない
解決策：
1. 指示を簡潔に保つ（箇条書きや番号付きリスト使用）
2. 重要な指示を最上部に置く
3. 曖昧な表現を避け、具体的に記述
4. 重要な検証はスクリプトで実行する（言語より決定論的）
SKILL.mdを書くときのコツ
SKILL.mdは5,000語未満に
長すぎるとコンテキストを圧迫する。MCPよりもずっと少ないコンテキスト量で効果を発揮するSkillsにとってこれは本末転倒だ。
詳細はreferences/に分けて、Claudeが必要なときだけ読み込むようにする。
公式ドキュメントでは「Progressive Disclosure（段階的開示）」と呼んでいる。
目次のように、まずSKILL.mdで概要を示して、詳細は別ファイルへ誘導するイメージだ。
SKILL.mdは500行以下を目指そう。
具体的かつ実行可能であること
悪い例
進む前にデータを検証してください。
良い例
`python scripts/validate.py --input {filename}`を実行してデータ形式を確認してください。
検証が失敗した場合、一般的な問題は以下の通りです：
- 必須フィールドが欠けている（CSVに追加してください）
- 無効な日付形式（YYYY-MM-DDを使用）
Claudeは賢いので、説明しすぎない
PDFが何かとか、ライブラリの基本的な使い方とか、Claudeが既に知っていることは書かなくていい。
悪い例（冗長）
PDF（Portable Document Format）ファイルは、テキスト、画像、
その他のコンテンツを含む一般的なファイル形式です。
PDFからテキストを抽出するにはライブラリが必要です。
様々なライブラリがありますが、pdfplumberをお勧めします......
良い例（簡潔）
## テキスト抽出
pdfplumberを使用
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
```
実はClaude.aiのGUIでも作れる
ここまでCLIでの方法を説明してきたが、実はClaude.aiの画面からもSkillsを追加できる。
手順
- 設定 > 機能 を開く
- スキルセクションで+追加をクリック
- 選択肢を選んでスキルを追加
ZIPファイルの中身は、これまで説明してきた構成と同じだ。
my-skill.zip
└── my-skill/
├── SKILL.md
├── references/
└── ...
チームで共有するならgit上からProject Skillsとして管理するのが良いが、
個人で試すならGUIからのアップロードも手軽で便利だ。
状況に応じて使い分けてほしい。
まとめ
Claude Code Skillsを手動で作成する方法を紹介した。
ポイントをおさらいしよう
- Skillsは
~/.claude/skills/（個人用）または.claude/skills/（プロジェクト用）に置く - 必須ファイルは
SKILL.mdのみ（大文字小文字区別） - フォルダ名はケバブケース、README.mdは含めない
-
references/に詳細ドキュメント、scripts/に実行スクリプト、assets/にテンプレート等を配置 -
descriptionは「何をするか」＋「いつ使うか」＋具体的なトリガーフレーズ - SKILL.mdは5,000語未満に収めて、詳細は別ファイルへ
- テストはトリガー、機能、パフォーマンスの3領域で実施
- 重要な検証はスクリプトで実行
既存のSkillsを参考にしながら、自分のワークフローに合ったSkillを作ってみてほしい。
社内用語集やコーディング規約、デザインガイドラインなど、参照元が変わらないなら全ての仕事がSkills化の候補だ。
参考リンク
- Claude Code Skills 公式ドキュメント
https://code.claude.com/docs/en/skills - The Complete Guide to Building Skills for Claude
https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf?hsLang=en - Skill authoring best practices
https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices - Agent Skills Overview
https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview - Anthropic Skills GitHub
https://github.com/anthropics/skills - Awesome Claude Skills（コミュニティスキル集）
https://github.com/travisvn/awesome-claude-skills
Discussion