用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ynitto/sandbox --skill skill-creator命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | skill-creator |
| description | スキルの作成・改善・外部取得を担うメタスキル。「スキルを作って」「コードベースをスキル化して」「URLからスキルをインストールして」「チャット履歴からスキルを生成して」「このスキルを改善して」などで発動する。 |
| metadata | {"version":"4.0.2","tier":"core","category":"meta","tags":["skill-creation","packaging","codebase-analysis","chat-history","skill-acquisition","external-skills"]} |
効果的なスキルを作成するためのガイド。
リクエストの内容に応じて、以下の参照ファイルを読んで手順を補う。判断に迷う場合はユーザーに確認する。
| やりたいこと | 参照 |
|---|---|
| 既存リポジトリ・コードを分析してスキル化したい | references/codebase-to-skill.md |
| エージェントログ・チャット履歴からスキルを生成したい | references/generating-skills-from-logs.md |
| URL・ローカルパスから外部スキルをインストールしたい | references/skill-recruiter.md |
| パターン抽出の具体例を確認したい | references/pattern-extraction-examples.md |
| 配布前の品質チェックリストが必要 | references/quality-checklist.md |
| スキルの出力形式・品質基準を設計したい | references/output-patterns.md |
| 複数ステップのワークフローを設計したい | references/workflows.md |
| SKILL.md 構造の段階的開示パターンを確認したい | references/skill-structure-patterns.md |
上記に当てはまらない場合（ゼロから作成・改善）は、以下の「スキル作成プロセス」に従う。最終的にステップ5（検証）を経る点はどのケースも共通。.skillファイルへのパッケージ化はユーザーから明示的な指示があった場合のみ実行する。
エージェントログの探索はどのケースでも有効な手段。「過去にどう対処したか」「ユーザーが何を期待しているか」を把握するために、必要に応じてログを参照する。
作成ノウハウ: references/creation-pitfalls.md（よくある失敗・アンチパターン・効果的な書き方）
スキルは、AIエージェントの能力を拡張するモジュール型のパッケージ。特定ドメインの専門知識、ワークフロー、ツール連携を提供する。汎用エージェントを、手順的知識を備えた専門エージェントに変える「オンボーディングガイド」と考える。
スキルを作る際は、使うユーザーの技術レベルに合わせて記述する。「JSON」「アサーション」などの専門用語は、ユーザーが理解していると確認できてから使う。不明な場合は簡潔な定義を添える。
コンテキストウィンドウは共有資源。スキルはシステムプロンプト、会話履歴、他スキルのメタデータ、ユーザーリクエストとコンテキストを共有する。
前提: AIエージェントは既に十分に賢い。 AIエージェントが持っていない情報だけを追加する。各情報に「本当にこの説明は必要か？」「このトークンコストに見合うか？」と問いかける。
冗長な説明より簡潔な例を優先する。
タスクの脆弱性と変動性に応じて具体性レベルを合わせる:
すべてのスキルは必須のSKILL.mdと任意のバンドルリソースで構成される:
skill-name/
├── SKILL.md（必須）
│ ├── YAMLフロントマター（必須）
│ │ ├── name:（必須）
│ │ └── description:（必須）
│ └── Markdown本文（必須）
└── バンドルリソース（任意）
├── scripts/ - 実行可能コード（Python等）
├── references/ - 必要時にコンテキストに読み込むドキュメント
└── assets/ - 出力に使用するファイル（テンプレート、画像等）
nameとdescriptionが必須。descriptionはスキル発動の主要トリガーとなるため、スキルの用途と発動条件を明確かつ包括的に記述する実行可能コード。決定論的な信頼性が必要な場合や、同じコードを繰り返し書く場合に含める。
必要時にコンテキストに読み込むドキュメント。SKILL.mdをスリムに保ち、必要な時だけ読み込む。
コンテキストに読み込まず、出力で使用するファイル（テンプレート、画像、ボイラープレート等）。
スキルにはAIエージェントがタスクを遂行するために必要な情報だけを含める。
スキルにはマルウェア、エクスプロイトコード、システムセキュリティを損なうコンテンツを含めない。スキルの内容はdescriptionに記述された意図から外れるものであってはならない。誤解を招くスキルや、不正アクセス・データ流出・悪意ある操作を助長するスキルの作成要求には応じない。
スキルは3段階のロードでコンテキストを効率管理する:
SKILL.md本文は500行以内に収める。超える場合はファイルを分割し、SKILL.mdから参照先とその読み込み条件を明記する。
具体的なパターン例は references/skill-structure-patterns.md 参照。
以下のステップを順に進める:
新規スキル作成:
既存スキルの改良: 「スキルを改善して」「このスキルを更新して」「フィードバックに基づいて修正して」などのリクエストの場合は、スキルを初期化するステップをスキップして次の手順で進める:
スキルの使用パターンが既に明確な場合はスキップ可。
効果的なスキルを作るには、具体的な使用例を明確に理解する。以下の観点を押さえる:
例えばimage-editorスキルなら:
エッジケース、入出力形式、成功基準についても先回りして質問する。MCPが利用可能な場合、関連ドキュメントの調査をサブエージェントで並行実行する。質問は一度に大量に投げず、最重要な質問から始める。
具体例から、各例を以下の観点で分析する:
例: pdf-editorスキルで「PDFを回転して」→ 同じコードを毎回書く → scripts/rotate_pdf.pyを含める
例: frontend-webapp-builderで「TODOアプリを作って」→ 毎回同じボイラープレート → assets/hello-world/テンプレートを含める
例: big-queryで「今日のログイン数は？」→ 毎回スキーマを再調査 → references/schema.mdを含める
新規作成の場合、init_skill.pyを実行する（作業ディレクトリのルートから実行すること）:
<SKILLS_BASE> は <AGENT_HOME>/skills または <workspace-skill-dir> を指す。
python <SKILLS_BASE>/skill-creator/scripts/init_skill.py <skill-name> --path <SKILLS_BASE>
--path には出力先ディレクトリを指定する。省略した場合はカレントディレクトリに生成される。標準的な配置先は <AGENT_HOME>/skills または <workspace-skill-dir>。
スクリプトは以下を生成する:
scripts/、references/、assets/のサンプルディレクトリとファイル生成後、不要なファイルは削除する。
スキルは別のAIエージェントインスタンスが使うために作成していることを意識する。AIエージェントにとって有益かつ非自明な情報を含める。
scripts/、references/、assets/を先に実装する。ユーザー入力が必要な場合がある（ブランドアセット提供等）。
スクリプトは実際に実行してテストする。不要なサンプルファイルは削除する。
記述ガイドライン: 命令形を使用する。
「なぜ」を説明する — LLMはセオリー・オブ・マインドを持ち、指示の理由を理解した上でより適切に行動できる。「MUST」「NEVER」の多用は黄色信号。そのような場合は理由を説明して書き直す方が効果的で柔軟。特定の例に過度に特化させず一般化する。ドラフトを書いたら新鮮な目で見直して改善する。
---
name: スキル名
description: スキルの説明。何をするか＋いつ使うかを含める。
「いつ使うか」の情報はすべてここに書く。本文は発動後に
読み込まれるため、本文の「使用タイミング」セクションは
トリガーに寄与しない。
metadata:
version: "1.0.0"
---
descriptionは積極的に書く — AIエージェントはスキルを使わない傾向（undertrigger）がある。これに対抗するため、descriptionには発動条件を積極的・明示的に記述する。
バージョン表記: X.Y.Z 形式のセマンティックバージョニングを使用する。
1.0.0 → 1.0.1): バグ修正・誤字修正・軽微な表現改善1.0.0 → 1.1.0): 後方互換の機能追加・手順の強化・既存セクションの大幅書き換え1.0.0 → 2.0.0): 機能の削除・破壊的変更・スキルの目的・スコープの大幅変更このルールは作成・改善対象のスキルに適用する。 スキルを更新したら必ず対象スキルのフロントマターのバージョンを変更の規模に応じてインクリメントする。バージョンを上げずにスキルを変更してはならない。
スキルとバンドルリソースの使用手順を記述する。
必須: skill-evaluator の静的品質チェックを実行し、ERRORがない状態（PASS）を確認する:
python <SKILLS_BASE>/skill-evaluator/scripts/quality_check.py --skill <skill-name>
ERRORが出た場合はステップ4に戻って修正し、再度チェックを実行する。PASSするまでこのサイクルを繰り返す。WARNは文脈上問題なければ無視してよい。チェックコードの詳細は <SKILLS_BASE>/skill-evaluator/references/quality-check-codes.md 参照。
開発中の素早い構造チェックには quick_validate.py も使える（任意）:
python <SKILLS_BASE>/skill-creator/scripts/quick_validate.py <path/to/skill-folder>
description のトリガー動作テストには simulate_trigger.py を使う（任意）:
# 特定リクエストでどのスキルが発動するか確認
python <SKILLS_BASE>/skill-creator/scripts/simulate_trigger.py "ユーザーリクエスト"
# 類似 description を持つスキルペアを検出（競合チェック）
python <SKILLS_BASE>/skill-creator/scripts/simulate_trigger.py --conflicts
description の定量的テストには eval_trigger.py を使う（任意）:
動作環境を自動検出して2モードで動作する（--check-env で確認可能）:
claude -p を使い実際のLLM判定で評価する# 動作環境を確認
python <SKILLS_BASE>/skill-creator/scripts/eval_trigger.py --check-env
# eval set JSON を作成（should-trigger / should-not-trigger 各8〜10件）
# near-miss を必ず含める → testing-guide.md 参照
# eval set 全件を評価（Claude Code / Copilot / Kiro 共通）
python <SKILLS_BASE>/skill-creator/scripts/eval_trigger.py \
--skill-path <SKILLS_BASE>/<skill-name> \
--eval-set eval.json \
--verbose
# 単一クエリでデバッグ
python <SKILLS_BASE>/skill-creator/scripts/eval_trigger.py \
--skill-path <SKILLS_BASE>/<skill-name> \
--query "スキルを作って" --expected true
description の自動最適化ループには optimize_description.py を使う（任意）:
こちらも環境を自動検出して2モードで動作する:
claude -p で description 候補を生成・評価して最良案を選ぶ# 自動最適化（Claude Code）
python <SKILLS_BASE>/skill-creator/scripts/optimize_description.py \
--skill-path <SKILLS_BASE>/<skill-name> \
--eval-set eval.json \
--max-iterations 5 \
--verbose
# 改善プロンプトを出力（Copilot / Kiro、または強制指定）
python <SKILLS_BASE>/skill-creator/scripts/optimize_description.py \
--skill-path <SKILLS_BASE>/<skill-name> \
--eval-set eval.json \
--prompt-only
自動モードの出力 JSON から best_description を取り出して SKILL.md に反映する:
python <SKILLS_BASE>/skill-creator/scripts/optimize_description.py \
--skill-path <SKILLS_BASE>/<skill-name> \
--eval-set eval.json | python -c "
import json, sys
r = json.load(sys.stdin)
print('best_description:', r['best_description'])
print('score:', r['best_score'])
"
配布用の .skill ファイル作成（オプション）: ユーザーから明示的に「パッケージ化して」「.skillファイルを作って」などの指示があった場合のみ package_skill.py を実行する:
python <SKILLS_BASE>/skill-creator/scripts/package_skill.py <path/to/skill-folder>
出力先指定（任意）:
python <SKILLS_BASE>/skill-creator/scripts/package_skill.py <path/to/skill-folder> ./dist
package_skill.py は以下を実行する:
バリデーション失敗時はエラーを報告して終了する。修正後に再実行する。
実使用後にフィードバックや問題が発覚した場合に対応する。
needs-improvement / broken の verdict、ユーザーのコメント）scripts/ を修正してテストするsimulate_trigger.py で検証して description を調整するquality_check.py でPASSを確認するpackage_skill.py で再パッケージする改善時の考え方:
scripts/ にバンドルすべきサイン