skillkit

skillkit

個人用スキルコレクションを作成するためのスキルです。「X を行うスキルが欲しい」という大まかなアイデアを、ホストコレクションのスキルレイアウトに沿った、簡潔で規約に準拠した SKILL.md に変換し、実際に試すためのライブテストループをユーザーに案内します。各スキルは必ずゼロから作成し、フォークはしません。以下に記載する規約に従います。skillkit を使えば、毎回そのルールを自分で導き出す必要はありません。

呼び出し

/skillkit、または「スキルを作成／執筆／ひな形作成して」のような自然なリクエストです。スキルで何をするかユーザーがまだ伝えていない場合は、ほかのことに取りかかる前に質問してください。以下の手順を一つずつ進め、草案を作成する前に、意図、公開範囲、由来、名前を確定します。

既存のスキルの確認や更新を依頼された場合は、作成手順を省略し、既存のスキルを保守するに進みます。

手順

1. 意図を確認する

スキルで何を行うか、また「どのようなときに起動するか」（実際のユーザーの言い回し）を質問します。任意で、参考となるスキルのリンクを尋ねてもかまいません。リンクが提供された場合は、構成の参考にするためにざっと確認します。これは必須ではなく、取得できる場合にのみ行う価値があります。役割、起動条件、必須の制約（必要なツール、してはならないこと）を把握します。

次に、新しいスキルという形が適切か確認します。コレクションのインデックスを把握するのは人間だからです。人がそのスキルを明確に選びたいと思う場合、つまり、意図的に選ぶ明確なタイミングや判断がある場合は、独立したディレクトリを設ける価値があります。一方、エージェントがコンテキストに応じて判断すべき選択であれば、既存スキル内のモードにします。新しいスキルを作ると、ユーザーが覚えておくべき恒久的な項目が増えますが、モードなら既存スキルの説明に分岐を一つ加えるだけで済むためです。該当する既存スキルの名前を示し、ユーザーに選んでもらってください。リクエストを拒否してはいけません。役割、それが扱うすべての分岐と各分岐の実際の言い回しを一つ以上、そして新しいスキルとモードのどちらを選ぶかを確認できたら完了です。

2. 公開範囲（内部用か公開用か？）

後続のすべてのルールに関わるため、スキルが内部用（リポジトリ限定）か、公開用（公開可能）かを尋ねます。

• 内部用：ホストリポジトリの保守／メタスキルです。リポジトリへの依存は問題ないため、リポジトリの規約ドキュメントやビルドツールを参照したり、リポジトリ相対リンクを使ったりできます。metadata.internal: true を設定します。skills.sh での検索結果には表示されません。
• 公開用：共有可能なスキルです。以下のポータビリティ（公開スキルのみ）に従い、metadata.internal: false を設定する必要があります。公開コレクションリポジトリにプッシュすると、skills.sh で自動的に検出され、一覧に掲載されます。

ユーザーがどちらかを選んだら完了です。

3. 由来（オリジナルか、「自分版」か）

これはオリジナルか、それとも上流スキルの自分版かを尋ねます。どちらの場合も、ここでゼロから作成します。回答は、上流スキルを構成の参考にする度合いを決めるためのものです（意図を確認するを参照）。ユーザーから回答を得たら完了です。上流スキルがある場合は、そのリンクも確認します。

4. 名前を提案する

ホストコレクションに命名規約があれば、それに従います。ない場合は、kit を使った名前を3～5個提案し、そのうち一つを推奨します。名前は小文字一語とし、検索しやすいように機能を表す語を先頭に置きます（kit ではなく commit で検索するため）。最後に kit を付け、つなげると不自然な場合は、無理に結合せず語幹を短くします（humanize → humanizekit ではなく humankit）。よく知られたツール（speckit、shipkit、すでに人気のあるもの）との名前の衝突は避けます。ネットワークに接続できる場合は、候補名をウェブと skills.sh ディレクトリで検索します。オフラインの場合は、人気度の確認を省略したことを伝えます。ユーザーに名前を選んでもらいます。選ばれた名前は、ディレクトリ名と一致していなければなりません。ユーザーが名前を選び、名前の衝突確認が完了するか、省略したことを報告したら完了です。

5. 下書き

以下のFrontmatter templateに従い、ホストコレクションで文書化されているレイアウトでスキルを作成し、品質基準を適用したうえで、Visibilityに基づいてmetadata.internalを設定します。コレクションリポジトリでは、通常skills/<name>/SKILL.mdに配置します。単独で使う場合は、.claude/skills/<name>/SKILL.mdなど、エージェントが検出したスキルディレクトリを使用します。簡潔に保ちます。一連の処理を行うスキルならファイルは1つにし、モードが分岐する場合は情報階層にあるモード・サテライト型を使います。

• 公開する場合は、以下の移植性チェックリストを必須条件として適用します。インストール後、スキル単独で機能する必要があります。
• 下書きの横にトリガーケースを記載します。各分岐について、このスキルが発動すべき現実的なプロンプトを2〜3件と、発動すべきでない類似ケースを2〜3件用意します（隣接する別のスキルに該当するプロンプトや、ベースモデルだけで対応できる依頼など）。コレクションでケースを管理している場所に保存します。そのような場所がない場合は、スキルのディレクトリ内にevals/triggers.mdを作成し、Should fireとShould not fireの2つの見出しを付けてリストを記載します。このファイルによりルーティングを繰り返し検証できます。以後、説明を編集するたびに同じプロンプトを再実行します。

フロントマターの全項目が入力済みで、すべての手順に完了基準があり、スキルが引き継ぎで終わり、各分岐にトリガーケースがある状態になれば完了です。

6. レビューループ

下書きを提示します。ユーザーが明示的に承認するまで、修正を受け付けて反復します。ユーザーが言葉で下書きを承認した時点で完了し、その後にのみテストを開始します。

7. 実環境でのテスト

スキルを自分でインストールしてはいけません。実環境での試用を進めるためのコマンドをユーザーに提示します。コレクションに開発用リンク機能がある場合（READMEまたはMakefileでリンク／リンク解除用のターゲットを確認します）は、それを使ってスキルを注入するよう伝えます。ない場合は、skills/<name>をエージェントのスキルディレクトリ（例：~/.claude/skills/<name>）にシンボリックリンクするか、コピーするよう案内します。スキル一覧は起動時に読み込まれるため、必ず新しいセッションでテストしてください。実行中のセッションでは新しいスキルは認識されません。テスト計画用の一時ファイルは作りません。ここでのテストは、実際の環境で直接行います。実際の状況を使って試すよう提案します。

• トリガーケースファイル内のすべてのプロンプトを、それぞれ新しいセッションで実行し、どのケースでスキルが発動したかを記録します（類似ケースは過剰な発動を防ぐためのものです）。
• 実際の実行で、下書きの手順に最初から最後まで従い、スキルが約束する成果物または結果が得られることを確認します。
• 何もしない指示だと思われるものは、議論で済ませずに実行して確かめます。何もしない指示とは、モデルがすでに標準で従う指示です。テストはモデルに依存するため、疑わしい行を削除して同じ言い回しで再実行し、挙動が変わった場合にのみ、その行を残します。

テストが完了したら、追加時と同じ方法で開発用リンクを解除します（コレクションのリンク解除コマンドを使うか、シンボリックリンクまたはコピーを削除します）。すべてのトリガーケースについて発動したかどうかの結果が記録され、想定と異なる結果があった場合は、説明を編集するか、ユーザーが同意したケースの変更につながっていれば完了です。

8. 引き継ぎ

このセクションでは手順に沿った表現を使います。1文につき指示を1つ記述し、能動態と現在形を使い、比喩は使いません。

まず、仕上げの機械的な作業を完了します。リポジトリにある場合は、コレクションでスキルの一覧表示やドキュメント作成に使うすべての箇所を更新します。

• README のスキル一覧表；
• skills.sh.json ディレクトリ分類ファイル（公開スキルのみ）；
• ドキュメントのインデックスにあるスキルへのリンク（例：docs/wiki/index.md）；
• 生成されるチートシート：コレクションの生成コマンドを実行します（例：make cheatsheet）。

次に、コレクションにスキルの lint がある場合は実行し、エラーを修正して警告にも対処します。ない場合は、規約、品質基準、および公開スキルの場合は移植性に照らして自己チェックします。リポジトリにあるすべての箇所が更新され、lint でエラーが報告されない状態になれば完了です。その後、次の内容を伝えて締めくくります。

変更内容。 作成したスキル（名前、公開設定、ファイル数）、更新した一覧表示とドキュメントの箇所、トリガーケースの結果、lint または自己チェックの結果を報告します。

配置先。 スキルのディレクトリパスと、ライブテストで作成した開発用リンクがまだ残っているかを伝えます（この時点では削除されているはずです。残っている場合はその旨を伝えます）。

次の作業。 変更はまだコミットされていないため、コミットを提案します。ユーザーが実行するための慣例的なコミットメッセージを提案します（例：feat(<name>): add <name> skill）。自動でコミットしてはいけません。コミットするかどうかはユーザーが決めます。

既存のスキルを保守する

すでに存在するスキルに変更を加えた場合は、各チェックを実行してから、新規作成と同じ3つの項目で引き継ぎを行います。

1. トリガーケースを再実行します。 スキルのトリガーケースファイルにあるすべてのケースを新しいセッションで実行します。まだケースがない場合は、下書きの手順で先に作成します。すべてのケースに結果があり、不一致がすべて修正または報告されれば完了です。
2. 説明と分岐を照合します。 すべてのモードまたは分岐にトリガーが1つずつあり、スキルに存在しない分岐を指すトリガーがないことを確認します。各分岐が1つのトリガーに対応すれば完了です。
3. ドキュメントの箇所を更新します。 引き継ぎにある箇所のうち、変更が影響したものを更新します。説明を変更した場合はチートシートを再生成し、公開設定または名前を変更した場合は README の行とドキュメントのインデックスを更新します。変更が影響したすべての箇所が更新されれば完了です。
4. コレクションの lint を実行します。 エラーが報告されなければ完了です。

規約

Frontmatter テンプレート

---
name: <matches directory>
description: >-
  <what it does>. Use when <explicit English trigger>.
license: MIT
allowed-tools: <only if the skill needs a restricted set>
metadata:
  internal: true   # true = repo-only meta skill; false = public/publishable
---

情報の階層

スキルは、手順（エージェントが実行する順序付きのアクション）とリファレンス（必要に応じて参照する定義、ルール、事実）で構成されます。どちらを中心にしても、両方を組み合わせてもかまいません。それぞれの要素をどこに置くかは、エージェントがどれだけすぐに必要とするかで順位付けした階層によって決まります。ファイル内の手順は主要な層です。ファイル内のリファレンスは必要に応じて参照するものであり、同じ階層にあるルールを横並びにするのは、問題のある構成ではなく、適切な配置です。開示型リファレンスはスキルのディレクトリ内にある別ファイルに切り出され、そのポインターが参照されたときだけ読み込まれます。

サイズではなく分岐ごとに切り分けます。 すべての分岐で必要な内容はインラインにし、一部の分岐でしか使わない内容はポインターの先に置きます。各実行で3分の1ずつ読む、モード別にフィルタリングされたカタログはその好例です。切り分けすぎるとエージェントに必要な内容が隠れ、切り分けが足りないと冒頭部分が肥大化します。どちらか一方を無条件に安全な既定策とすることはできません。

モード別ファイルには決まった形式があります。 モードが互いに読み飛ばされる分岐（各実行で1つのモードだけを選び、ほかのモードは読まない）になっているスキルは、ルーティング用のルート SKILL.md と modes/<mode>.md に分け、モードごとに1ファイルを用意します。ルートにはモードの選択、ガード、すべてのモードに共通する用語を残し、各モードに1つずつポインターを置きます。ポインターはモード名を示し、その modes/<mode>.md ファイルにリンクし、読み込んだうえで内容に従うよう指示するリスト項目です。モードファイルはルートが読み込まれていることを前提とし、ルートの内容を繰り返しません。各モードの引き継ぎ事項は、そのモードの本文と一緒に移動します。毎回本文全体を順に進む直線的なスキルは、どれだけ長くても1つのファイルにまとめます。

概念ごとにまとめます。定義、ルール、注意事項は、ファイル内に散らばらせず、1つの見出しの下にまとめます。散在は重複とは異なります。重複は同じ意味を2か所で繰り返しますが、散在は1つの意味を複数の箇所に分断します。その問題は別の形で現れ、エージェントが一部だけを読み、残りに気づかないことがあります。

肥大化とは、すべての行が有効で独自の内容であっても、スキルが単に長すぎる状態です。内容が過剰になるにつれて注意が薄れていきます。解決策は階層化であり、単なる削減ではありません。

完了基準

すべての手順は、作業が完了したことをエージェントに伝える条件、つまり完了基準で終わります。 完了基準のない手順は、エージェントが完了したと感じた時点で終わります。これは実行ごとのばらつきを生む最大の要因です。完了基準が効果を発揮するのは、2つの特性があるためです。明確さ：エージェントは完了と未完了を見分けられるでしょうか？「理解できた」「簡潔にする」といった曖昧な基準では、先に見えている後続の手順へ注意が移ってしまい、作業を早く切り上げる早すぎる完了を招きます。要求水準：文言がどれだけの作業を求めているでしょうか？「変更リストを作成する」よりも「変更されたすべてのモデルについて確認する」のほうが、実際に詳しく調べる必要があります。そのため、成果物を求める形式より、網羅を求める形式を優先します。要求水準は手順に限られません。「すべてのルールを適用する」のような基準は、平坦なリファレンス全体にも同じように求められます。これにより、リファレンスだけで構成されたスキルにも基準が設けられます。最も強い完了基準は、確認可能であり、かつ網羅的です。

急いでしまう手順は、まず完了条件を明確にします。この修正はその箇所だけで済み、コストも低いためです。条件を明確にするだけではどうしても曖昧さが残り、実際に急いでしまう様子も確認できた場合にのみ、手順を分割します。また、分割が効果を発揮するのは、引き継ぎ用ドキュメントやサブエージェントへのタスク割り当てなど、実際にコンテキストの境界がある場合だけです。インラインで呼び出しても後続の手順がコンテキストに残るため、何も隠れません。

文章の書式

強制的な折り返しはしません。 各段落とリスト項目は、連続した1行で記述します。エディターやレンダラーによるソフトラップに任せてください。文の途中で固定幅に合わせて改行しても意味はなく、エージェントは改行に関係なくテキストを読み、Markdownレンダラーもいずれにせよソフトラップするためです。構造が意味を持つ箇所、つまりコードフェンス、表、YAMLフロントマターでは行構造を保ちます（折りたたみ形式の description: >- スカラーも問題ありません）。

文体の使い分け

スキルは、相反する文章を必要とする二種類の読み手に向けて書きます。 スキルが自身のオペレーターに返すテキスト（QA 手順、引き継ぎ文書、状況のスナップショット、Hand off セクション、次のアクションを示す行、プレビューと確認を促す行）は手順を示す文章です。ASD-STE100 Simplified Technical English で書いてください。1 文につき 1 つの指示にします。手順を示す文は 20 語以下、説明文は 25 語以下にします。能動態、現在形を使い、行為者を明示してください。比喩、慣用句、複数の意味を持つ表現は使わないでください。概念ごとに用語を 1 つ選び、1 つの文書内で統一してください。このルールは文書をまたいでは適用されません。意見を形成するために読むテキスト（計画の背景、調査の推奨事項、ADR の根拠、レビューの判定）は説明的な文章とし、リズムに変化をつけ、立場を明示してください。ここには STE を適用しないでください。機械で読み取るテキストや、形式が決まっているテキストは対象外です。コミットの件名、イシューのタイトル、プロンプト、デザイントークン、コード、パス、コマンド、引用したソースがこれに該当します。**スキルが第三者向けに作成するコンテンツはすべて対象外です。**プロジェクトのドキュメント、公開する文章、UI の文言などが該当します。これらはセッション外の読み手に向けた制作物であり、概念を説明する余地が必要だからです。優先順位は、明示的なユーザー指示、対象リポジトリに文書化された規約、文体ルールの順です。このルールは公開スキル内に記載し、リンクで代用しないでください。

ドキュメント成果物の命名

スキルが docs/ 内に永続的な Markdown 成果物を作成するときは、ホストコレクションに命名規約があればそれに従ってください。規約がない場合は、NNNN-<type>-<slug>-YYYY-MM-DD.md を使用します。4 桁の連番、小文字の種類プレフィックス、短い小文字のケバブケースの主題スラッグ、末尾の成果物の ISO 作成日を含めます（例：docs/plans/0001-plan-sso-login-2026-07-23.md）。連番はディレクトリごとに管理し、ゼロ埋めし、単調増加させ、再利用しないでください。この作業ツリー、git worktree list が示すすべてのほかの作業ツリー、origin/HEAD を対象に、ディレクトリ内で先頭に付く最大の連番を確認して 1 を加えてください。最初の番号は 0001 です。並行する作業ツリーで同じ連番が使われないよう、3 つすべてを確認してください。リモートがない場合など、確認元へのアクセスに失敗した場合はその確認元を省略します。git が使えない場合は、ディレクトリだけを一覧表示してください。ファイルを編集しても名前全体は変更せず、同じ成果物をそのまま更新してください。ADR では、決定番号を連番として使います：docs/adr/NNNN-adr-<slug>-YYYY-MM-DD.md。複数ファイルの成果物では、docs/verify/NNNN-verify-<slug>-YYYY-MM-DD/ のように、バンドルディレクトリに命名規約を適用します。構造上の子ファイル名は固定のままにします。名前で成果物を探すスキルは、先頭に NNNN- が付く場合と付かない場合の両方に一致させてください。これにより、連番導入前に作成されたファイルも見つかります。そのような成果物を作成するすべての公開スキルに、該当するルールを明記してください。そうすることで、インストールされたスキルだけで完結できます。連番を対象リポジトリのエージェントガイドに委ねるスキルでは、新しいリポジトリごとに番号なしのファイルが作成されます。

手順の相互参照

手順を番号で参照しないでください（単に「手順 N を参照」と記す形式）。単独の番号は手順の位置に結び付いているため、手順を挿入したり並べ替えたりすると、参照先が知らないうちに誤った手順へ変わります。番号ではなく、手順の識別情報を使って参照してください。見出しがある手順は、GitHub アンカーを使って見出し名でリンクします（[意図を把握する](#1-gather-intent)。GitHub は見出し全文を小文字に変換し、句読点を取り除き、スペースをハイフンに置き換えてアンカーを作成します）。見出しのないリスト項目は、序数を示さず、文章でアクション名を挙げてください。

引き継ぎ

すべてのスキルは、実行した内容を報告し、次に行うことを示して終了します。締めくくりのセクションは ## Hand off（番号付き手順内では ### N. Hand off、モードごとにセクションが分かれているスキルでは各モードに1つ）とします。最後に何も伝えずに終わるスキルでは、ユーザーがディスク上の変更内容と次の手順を自分で調べることになります。それこそ、スキルが取り除くべき作業です。順番に3つの要点を示します。変更内容：実際に加えた変更を具体的に記載し、変更されなかったものも含めます。反映先：パス、ブランチ、URLを記載し、何も探し回らずに済むようにします。次の手順：最善の手順を1つだけ明確に示し、同等の選択肢を並べません。実行せずに案内します。次に行う作業と、その1行の呼び出し方法を示します。兄弟スキルの名前を挙げるのは、それがインストールされている場合に限ります。また、必ず平易な代替手段を示します（「PR スキルで PR を作成し、利用できない場合は gh pr create を実行します」）。最後に実行するスキルは、次の手順がないことを明確に伝え、無理に作り出しません。読み取り専用スキルでは、実際に空となる要点を省略してもかまいません。埋め合わせのために内容を足してはいけません。

品質基準

下書き中に以下を適用してください。スキルが実行され、読みやすいものになるかどうかを左右します。

• 先頭に主要語を置きます。 主要語とは、そのスキルが何をするかを示す簡潔な語です。name と description の最初の語が呼び出しを担うため、そこに置いてください。モデルがすでに知っている語（commit、review、slop、ledger）なら、その効果はさらに高まります。事前学習済みの語は、定義のためのトークンを使わずに行動の領域を定めますが、新たに作った語では、同じ位置づけのために定義トークンが必要です。本文ではその語を トークン として繰り返し使い、文として言い直してはいけません。
• 「Use when」トリガー。 description はスキルの機能から始め、そのあとに平易な英語で「Use when …」節を続けます。発火不足を防ぐため、少し強めの表現にし、発火すべき言い回しやコマンドを挙げてください。description は コンテキストへのポインター であり、スキルが発火するかどうかにかかわらず毎ターン読み込まれるため、類義語ごとではなく、分岐ごとに 1 つのトリガー を割り当てます。すべてのモードを網羅し、単一のモードを言い換えただけの表現はまとめてください。ポインターが示すのは、その資料の内容と参照するタイミングであり、スキルのルールや対象範囲に関する免責事項ではないため、本文ですでに示されている役割の説明は削ります。網羅性は保ったまま類義語を削ってください。トリガーのない分岐は、気づかれないまま発火しません。
• スキルは、モデルがまだできないことに使います。 基本モデルが直接処理できないタスクに対してのみ、スキルが発火します。ガイダンスが自明であれば、どのように表現しても発火しません。
• 簡潔に保ち、分岐ごとに情報を開示します。 情報の階層を適用します。スキップされる分岐を持つスキルでは、モードとサテライトの形式に従います。すべての分岐に必要な内容は本文に置き、一部の分岐だけが参照する内容はスキル専用ディレクトリ内のサテライトファイルに移し、それぞれの概念を 1 つの見出しの下にまとめます。簡潔化の見直しでは解消できない、内容の肥大化に注意してください。
• 完了条件に従い、すべてのステップを完了条件で終えます。エージェントが完了と未完了を判断できるよう、条件を明確に定めます。「X の一覧を作る」という生産的な形式より、「すべての X を確認する」という網羅的な形式を優先してください。感覚的な表現で終わるステップは、実行ごとのばらつきの原因になります。
• 決まり文句より意図を優先します。 スキルでは 達成することとその理由 を示し、具体的な呼び出し方はエージェントに判断させます。正確なコマンドを固定するのは、安定した公開仕様（git commit、gh pr create、grep、jq）の場合に限ります。毎回導き直すだけでトークンを消費し、ばらつきを招くためです。その場合も、「gh pr create … を実行し、フラグが拒否されたら gh pr create --help を確認する」のように、自己修正できる指示にしてください。変化しやすいツールやベンダー製ツールの構文は決して固定せず、ツールの 内部 動作（出力形式の解析、ヘルプテキストのスクレイピング、既定の形式に関する仮定）を契約仕様のように記述してはいけません。そうした記述は壊れやすく、ツールの更新で機能しなくなるためです。目指す結果を説明し、エージェントにドキュメントを読ませてください。避けるべき失敗は両極端にあります。壊れやすい構文を固定して、目立つ形で失敗することと、固定されたコマンドを「やり方を考える」と曖昧にし、毎回気づかれない形で負担をかけることです。
• 1 つの意味は 1 か所にだけ記述します。 重複させてはいけません。内部スキルでは、規約を繰り返さず、ホストリポジトリの規約ドキュメントを参照してください。公開スキルでは、必要な内容を本文に記載します（Portability を参照）。環境 も信頼できる情報源です（package.json のスクリプト、Makefile、設定ファイル、--help の出力など）。環境の情報を繰り返すスキルはキャッシュであり、参照にコストがかかる場合に限って、そのキャッシュを読み込む価値があります。文書化されていない規約と、選択の理由をキャッシュしてください。古くなる心配のない、1 コマンドで確認できる情報はその場で参照してください。
• 望ましい行動を促します。 禁止による誘導は、禁じた行動をコンテキストに持ち込み、減らすどころか 利用しやすく してしまいます。目標とする行動を述べてください（「1 行のコメントを書く」は「長いコメントを書かない」より効果的です）。禁止事項を設けるのは、肯定的な表現では示せない強いガードレールが必要な場合に限り、その場合も目標とする行動を併記してください。
• 効果のない指示を削ります。 効果のない指示とは、モデルが既定ですでに守っているため、読み込みコストをかけても何も伝えない指示です。判断基準は読者ではなくモデルに依存します。ある指示が効果のないものかについて意見が分かれる場合、それは 既定の動作 について意見が分かれているということです。議論ではなく、実地テストでスキルを実行して判断してください。語句を削るのではなく、文全体を削除します。ルールの理由が自明でない場合は、その 理由 を説明してください。
• 本文の書式に従い、本文を固定幅で改行しないでください。
• 本文の文体に従い、出力の文体を分類します。 スキルがオペレーターに返すテキストは手順説明であり、STE に従います。読者が意見を評価するためのテキストは解説文です。第三者に向けて作成するコンテンツは対象外であり、独自の基準に従います。文体を取り違えると、判断が曖昧になったり、手順書が肥大化したりします。
• 引き継ぎで締めます。 最後の引き継ぎに従い、Hand off セクションで終えます。変更内容、保存先、最優先の次のアクションを、手順の文体で記述してください。
• 長期保存されるドキュメント成果物。 スキルが docs/ 内に Markdown を作成する場合は、ドキュメント成果物の命名を適用し、公開スキルには該当する規約を本文に記載してください。
• kit の命名とフロントマター。 名前の提案の命名規則とフロントマターのテンプレートに正確に従ってください。name はディレクトリ名と一致させ、metadata.internal を宣言してください。

移植性（公開スキルのみ）

公開スキルは、さまざまな環境に単独でインストールされます。スキル自身のディレクトリだけが移動するため、単独で機能する必要があります。

• 自己完結型。 依存する規約はスキル内に記述します。リポジトリ相対リンク（../…）を使わず、ホストリポジトリの Makefile、規約ドキュメント、ヘルパーツールにも強く依存しないでください。ヘルパースクリプトが必要な場合は、スキル自身のディレクトリに含めます。
• マシン／OSに依存しない。 絶対パスやプラットフォーム固有の前提を避け、どのシェルでも、あるいはシェルがなくても使える手順を優先します。
• 環境に応じて出力を切り替える。 ファイルシステムとシェルが利用できる場合は、ファイルを直接作成・編集します。利用できない場合（ブラウザベースのエージェントなど）は、完成した成果物をユーザーが保存できるようコードブロックで出力し、開発用リンクの作成やリントなど、リポジトリ内でしか行えない手順は省略します。

内部スキルはリポジトリ内でのみ使用するため、この制約の対象外です。リポジトリの仕組みを自由に利用できます。

メモ

• skillkit 自体は公開されています（metadata.internal: false）。ホームコレクション内ではリポジトリのリンク／リントツールを利用できますが、スキルの作成に必要なものはすべてここに記載されているため、インストール先を問わず単独で機能します。
• 新しいスキルにスクリプトや付属ファイルを追加するのは、本当に必要な場合に限り、先回りして追加しないでください。スキルごとのスクリプトは、リポジトリのルートではなく、スキル自身のディレクトリに置きます。