skill-creator-plus

Skill Creator+

Design and review reusable skills that trigger reliably and stay lean.

Decision Flow

Start by deciding whether the user really needs a skill.

Need	Use
Reusable multi-step workflow with bundled scripts, references, or templates	Skill
Single focused slash task with parameterized input (Local harness only; deprecated for Agent Host)	Prompt
Always-on or file-scoped guidance	Instruction
Persona, tool restrictions, delegation, or handoffs	Custom Agent
Deterministic enforcement or lifecycle automation	Hook

If the answer is not Skill, stop and create the right primitive instead.

上表は「skill にすべきか」の即時ゲート。

→ references/customization-primitives.md for the full selection guide

When to Use

• Create skill, /create-skill, new skill, review skill, fix skill trigger, SKILL.md, workflow, スキル作成
• Creating a new skill from scratch
• Extracting a repeated workflow from a conversation, incident, or checklist
• Updating or refactoring an existing skill
• Reviewing existing SKILL.md files
• Deciding whether a customization should be a skill before authoring it

Start Here

1. Extract the workflow you want to package.
2. Clarify only the missing dimensions: target outcome, personal vs workspace scope, checklist vs full workflow.
3. Draft the smallest useful SKILL.md, then move detail into references.

License And Validation Gate

Classify the target before creating or changing it: self-authored, third-party, or derivative. A self-authored target uses independent content; copying this Skill's prose, code, templates, or notices makes it a derivative and requires preserved upstream evidence.

For a new self-authored Skill, propose CC BY-NC-SA 4.0 as a candidate, show the exact display attribution, and get confirmation. Do not silently copy this Skill's Apache-2.0 license into the target. Preserve an existing or upstream license when updating or importing.

Use the target license profiles and validation lanes. Baseline review is always required; Python helpers and packaging are conditional.

注意点

• init_skill.py --path には既存の親ディレクトリを指定します。生成先は <path>/<skill_name> です。スキルのディレクトリ自体を指定すると、重複して入れ子になります。
• 生成される成果物は 3 つです：SKILL.md、LICENSE.txt、skill-license.json。
• quick_validate.py は、LICENSE.txt の内容がレンダリングされたテンプレートと完全に一致することを確認し、metadata.author が authorAttribution.value と文字単位で一致することを必須とします。LICENSE.txt を手動で編集しないでください。ツールで再生成し、結果を上書きコピーしてください。
• ゲートに合格しても、正しさではなく一貫性が証明されるだけです。 マニフェストはテンプレートのレンダリング結果のハッシュを記録するため、テンプレートに問題があれば、検証には合格しても通知の内容に問題が残ります。スキャフォールディング後に、レンダリングされた LICENSE.txt を一度確認してください。
• 分類の基準は、コピーしたという行為ではなく、ソースが独自に作成されたかどうかです。自分の素材を再利用する場合は self-authored のままです。PROVENANCE.md と upstreamAttributions が必要なのは third-party と derivative の場合に限られます。
• skill-license.json がない Skill はレガシーとして扱われ、内容の比較は省略されます。そのため、共有テンプレートを修正しても古い Skill は無効になりません。マニフェストがある Skill は、テンプレート変更後に profile snapshot disagrees で失敗します。ツールチェーンを使って、LICENSE.txt とプロファイルスナップショットを再レンダリングするか（self-authored）、スナップショットのみを更新してください（derivative）。
• Skill を別のリポジトリにインポートする場合は、そのリポジトリのツールチェーンを使って LICENSE.txt と skill-license.json を再生成してください。マニフェストにはテンプレートのハッシュが固定されるため、コピーした一対のファイルはそのリポジトリで検証に失敗します。
• Microsoft 365 Agent Builder（Preview、Frontier のみ）にアップロードする前に、文書化された制限を確認してください：エージェントごとに 8 個のスキル、zip は 50 MB、SKILL.md は 20,000 文字未満、ディレクトリの深さは 3、ファイル数は 350、スクリプトは .py .js .mjs .cjs .ts .mts .sh .bash のみ（.ps1 は不可）で、サンドボックス内でネットワーク接続やインストールはできません。package_skill.py は <skill_name>/ の下にファイルを格納しますが、文書化された例では zip のルートに SKILL.md があります。どちらの構成でインポートできるかもテストされていないため、可能だと断言しないでください。出典：learn.microsoft.com/microsoft-365/copilot/extensibility/declarative-agent-skills

基本原則

原則	説明
簡潔さが重要	コンテキストウィンドウは共有されています。Claude がすでに知っていることは追加しないでください。
まず発見しやすさを重視	説明文がルーティングの窓口です。トリガーは明示してください。
自由度の段階	タスクの壊れやすさに応じて、具体性を調整してください（自由度：高／中／低）。
段階的な開示	3 つのレベルに分けてください：メタデータ → 本文 → リファレンス
追加する前に統合	さらに追加する前に、既存のガイダンスを更新、統合、または置き換えてください。
適切なプリミティブ	優れたスキルは、プロンプト／エージェント／指示の設計の代替にはなりません。
ファイルの前にスコープ	何かを作成する前に、ワークスペースとプロファイルのどちらにするかを決めてください。
自己完結型	スキル自体に必要な知識を含めてください。リファレンスやスクリプトにまとめ、コピー先で使えなくなるワークスペースのファイル（指示、メモリ、台帳）へのリンクだけで済ませないでください。環境固有の値（パス、名前）は引数や設定に抽象化してください。

デフォルトの前提： Claude はすでに非常に賢いということです。それぞれの要素について、「これにトークンを費やす価値があるか？」と問い直してください。

新しいセクションを追加する前に、既存のルールを置き換えられないか、references/ に移せないか、またはセッション固有のものとして削除できないかを検討してください。

スキルの構成

ルーティングと判断は SKILL.md に記述し、決定論的なヘルパーは scripts/ に、必要に応じて参照する詳細情報は references/ に、再利用可能な出力は assets/ に配置してください。リファレンスは必要に応じて読み込まれ、多くの場合は一度も読まれません。そのため、許可リスト、禁止値、安全制限など、取り消せない操作を制御する制約は、詳細情報のように見える場合でも SKILL.md 内に記載し、その根拠のみを references/ に記述してください。除外対象ファイルも含め、スキルの構成を参照してください。

作成プロセス

作成プロセスに従ってください。プリミティブとスコープを選び、再利用可能なワークフローを抽出し、リソースを計画し、実装してから、実際のトリガープロンプトで検証とテストを行います。

リファクタリングの順序

既存のスキルを改善する場合は、次の順序で進めてください。

1. 古くなったガイダンスや価値の低いガイダンスを削除する
2. 重複するルールを統合する
3. 長い詳細情報を references/ に移す
4. 本当に不足しているガイダンスを最後に追加する

Frontmatter とトリガー条件

必要最小限の frontmatter を使用します。name、description、および動作を変える場合に限り任意のフィールドを指定します。name はフォルダー名と一致させ、description にはトリガー条件を含める必要があります。

frontmatter の詳細と、気づきにくい失敗については、references/common-pitfalls.md を参照してください。

SKILL.md のガイドライン

SKILL.md は簡潔に保ちます。150 行未満が望ましく、300 行を超える場合は内容をリファレンスに分割する必要があります。「When to Use」はユーザーが使うフレーズから始め、不可欠なワークフローだけを残し、長い例、スキーマ、レシピはリファレンスに移します。

詳細なレビュー基準については、references/skill-review-checklist.md を参照してください。

反復のサイクル

1. スキルの草案を作成して保存します。
2. 最も弱い部分、または最も曖昧な部分を特定します。
3. その部分を改善し、スキルが生成するものと、試すためのプロンプト例をまとめます。

主なリファレンス

プリミティブの選択、構成、作成、レビュー用チェックリスト、肥大化のレビュー、よくある落とし穴を参照してください。構成のギャラリー、ワークフロー、出力パターンは任意の例です。

完了条件

• リクエストが別のプリミティブではなく、スキルであることを確認済み
• ファイルを作成する前にスコープを決定済み
• SKILL.md を作成し、150 行未満にしている
• frontmatter にトリガー条件を含む name と description がある
• 手動で使用するスキルには argument-hint がある
• user-invocable を意図的に設定している
• 動作が変わる場合に限り、任意のフィールドを追加している
• 詳細を references/ に移している（プログレッシブ・ディスクロージャー）
• 自己完結型：他のスキルやワークスペースファイルを直接参照していない。環境固有の値（パス、顧客名、テナント ID）は抽象化している
• レビューチェックリストに合格している