CreateSkill

カスタマイズ

実行する前に、次の場所にユーザー設定があるか確認してください。 ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/CreateSkill/

このディレクトリが存在する場合は、そこにある PREFERENCES.md、設定、またはリソースを読み込んで適用してください。これらはデフォルトの動作より優先されます。ディレクトリが存在しない場合は、スキルのデフォルト設定で進めてください。

🚨 必須：音声通知（操作を行う前に必須）

このスキルが呼び出されたら、ほかのことを行う前に必ずこの通知を送信してください。

1. 音声通知を送信する：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the CreateSkill skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. テキスト通知を出力する：

   Running the **WorkflowName** workflow in the **CreateSkill** skill to ACTION...
   

これは任意ではありません。このスキルの呼び出し直後に、この curl コマンドを実行してください。

CreateSkill

スキル開発のライフサイクル全体：構造（作成、検証、標準化）＋有効性（テスト、改善、トリガーの最適化）。構造のワークフローにより、スキルが LifeOS の規約に準拠します。有効性のワークフローは Anthropic の skill-creator に着想を得ており、スキルが実際に機能し、確実にトリガーされることを確認します。

権威ある情報源

スキルを作成する前に、必ず次を読んでください： ~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md

準拠する標準例： ~/.claude/skills/ にある、適切に整備された公開スキル（例：Research/SKILL.md、Daemon/SKILL.md、CreateSkill/SKILL.md 自体）。

命名規則 — 公開と非公開

スキル名によって公開／非公開が決まります。有効な形式は次の2つだけです。

スキルの種類	ディレクトリ形式	例	許可される内容
公開	TitleCase	Blogging、Daemon、CreateSkill	テンプレート化され、安全で、汎用的な、公開リリースに適した内容
非公開	_ALLCAPS（先頭にアンダースコア、すべて大文字）	_MYSKILL、_MYINBOX、_MYINFRA	個人向けの 機能。本文は公開可能な状態にし、機密データはすべて LIFEOS/USER/ を参照する

先頭のアンダースコアが公開リリースとの境界です。 リリースツールは _* のスキルを完全にスキップするため、~/.claude の外に出ることはありません。公開スキル（アンダースコアなし）は LifeOS の公開リリースにミラーされるため、汎用的でテンプレート化された内容のみを含める必要があります。

サブファイルの命名（公開・非公開の両スキルに適用）：

コンポーネント	形式	例
ワークフローファイル	TitleCase.md	Create.md、UpdateDaemonInfo.md
リファレンスドキュメント	TitleCase.md	ProsodyGuide.md、ApiReference.md
ツールファイル	TitleCase.ts	ManageServer.ts
ヘルプファイル	TitleCase.help.md	ManageServer.help.md

誤った形式（絶対に使用しないでください）：

• スキルのディレクトリ：createskill、create-skill、CREATE_SKILL（公開名ではアンダースコアなしの大文字、非公開名ではケバブケース／スネークケースを使用しない）
• ファイル：create.md、update-info.md、SYNC_REPO.md

公開と非公開の選択 — 判断基準

次のように問いかけてください：「このスキルをそのまま見知らぬ人の ~/.claude/skills/ に配置して、問題なく使えるだろうか？」

• はい → 公開スキル（TitleCase）。本文は汎用的にし、ユーザー固有の設定は LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/ を通じて追加します。
• いいえ。自分の身元、連絡先、事業、顧客、有料 API、非公開インフラ、ドメイン、非公開リポジトリ、パートナー、または財務／健康／セキュリティのデータを参照するため → 非公開スキル（_ALLCAPS）。

判断に迷ったら、まず非公開（_ALLCAPS）として作成してください。後から _FOO を Foo に昇格させるのは簡単です。公開スキルによって自分の生活が漏えいしたと気づいても、取り返しはつきません。

---

公開リリースの準備状況（必須）

公開スキル（TitleCase）は世界に公開されます。非公開スキル（_ALLCAPS）がローカルリポジトリの外に出ることはありません。 機密性は、共有時のファイルごとのチェックではなく、スキル名によって判断されます。

明確な境界線

公開スキル（TitleCase）— コンテンツのルール：

テンプレート化され、安全で、公開可能な、すぐに使えるコンテンツのみです。以上です。

• ✅ すべての LifeOS ユーザーが実行できる汎用的な手順
• ✅ ユーザー固有の値をプレースホルダーにしたテンプレートパターン
• ✅ 公開 API のリファレンスと公開ツールへの依存関係
• ❌ 実在する名前（人物、製品、企業、顧客）
• ❌ 実在するドメイン、ホスト名、IP、内部 URL
• ❌ API キー、トークン、認証情報、セッション Cookie、OAuth シークレット — 例に見えるものも含みます
• ❌ 非公開リポジトリのパスや参照（github.com/<org>/<private-repo>）
• ❌ 顧客データ、顧客固有のワークフロー、顧客とのやり取りの背景
• ❌ 特定のインシデント、プロジェクト、人物に結び付いた一人称の苦労話
• ❌ ユーザー固有のファイルシステムパス（/Users/<name>/...、/home/<name>/...）
• ❌ 個人に結び付いた設定や情報（DA 名、本人の名前、パートナーの名前、ペットの名前、金額、健康データ）

非公開スキル（_ALLCAPS）— コンテンツのルール（2026-07-23 分離指示）：

公開スキルと同じく、公開可能なクリーンさの基準を満たす必要があります。アンダースコアは引き続きリリースの境界です（リリースツールは _* をスキップします。この安全策は維持されます）が、個人情報を埋め込むことは、もはや認められません。非公開スキルの本文（SKILL.md、ワークフロー、ツール）に含めるのは汎用的なコードと手順のみとし、機密情報はすべて LIFEOS/USER/ に置き、スキルからパスで読み込みます。

• 個人データ（コーパス、インベントリ、設定、レジストリ、状態）→ LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/ — ただし、正規の USER ホームがすでに所有している場合（GEAR.md、FINANCES/、TELOS/、CONTACTS.md）は除きます。その場合はそちらを参照し、重複させないでください。
• 個人設定（ドメイン、アカウント ID、リポジトリのパス、エンドポイント）→ 同じ CUSTOMIZATIONS ディレクトリ内の Config.md/.yaml。スキルが実行時に読み込みます。
• 認証情報 → スキル内には環境変数の 名前 を記述し、値は ~/.claude/.env に置きます。値を記述してはいけません。URL にトークンを含めてはいけません。
• 説明文では実名ではなく「本人」と表記します。ホームディレクトリのパスを直接記述してはいけません（~ からの相対パス、または設定で解決するパスのみ使用できます）。

理由：この状態であれば、非公開スキルは名前を変えるだけで公開に移行でき、ツリー全体に単一の衛生チェックを適用でき、スキルツリーが漏洩しても個人情報は漏れません。スキルを 非公開 にする理由は、その FUNCTION が個人に限定されていること（本人の受信トレイ、顧客、インフラなど）であり、ファイルに個人データが含まれていることではありません。

適用： LIFEOS/TOOLS/SkillHygieneGate.ts（拒否リストに抵触しないことを確認し、/ic 内で実行）と SystemFileGuard の書き込みゲート。ゲートが違反を報告している間は、新しいスキルは完成していません。

判断テスト

次のいずれかをスキル本文に書き込みたくなった場合、そのスキルは必ず _ALLCAPS にしてください。

スキルに含まれる内容…	スキル名
特定の人物の名前（本人、パートナー、チーム、顧客の名前）	_ALLCAPS
所有または販売している特定の製品名	_ALLCAPS
特定の顧客またはクライアント	_ALLCAPS
特定の有料 API アカウント、請求先環境、サブスクリプション	_ALLCAPS
特定の非公開ドメイン、ホスト名、内部 IP、VPN	_ALLCAPS
特定の非公開リポジトリ、ドットファイルの場所、ローカルインフラ	_ALLCAPS
自社に結び付いた特定の業務プロセス	_ALLCAPS
特定の財務、健康、セキュリティ、または法的な状況	_ALLCAPS
特定のインシデントや一度限りの苦労話	_ALLCAPS
他人の ~/.claude/ にあった場合に、誤解を招く、恥ずかしい、または危険なもの	_ALLCAPS

上記のいずれにも該当せず、スキルが完全に汎用的であれば、TitleCase（公開）にできます。

公開スキルでの個人設定の適用先

公開スキルは、実行時に ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/PREFERENCES.md を通じてユーザーごとに設定できます。スキル本体は汎用のままにし、ユーザーのカスタマイズファイルでインスタンスごとのコンテキストを重ねます。スキル自体は基本的に汎用ですが、ユーザーごとの調整（好みの文体、デフォルトの形式、個人の好み）が役立つ場合に使用してください。

公開スキルに非公開のコンテンツを紛れ込ませるために、CUSTOMIZATIONS/SKILLSを使用してはいけません。 スキルの動作に非公開のコンテキスト（実在する顧客名、実際のAPIアカウント、実際の社内インフラ）が必要な場合、そのスキルは非公開スキルです。名前を _ALLCAPS にして、そこで止めてください。

公開スキルで許可されるもの

• 汎用的な ~/ パス（~/.claude/skills/、~/Projects/<tool>/） — ユーザーごとに解決されます
• スキルが依存するツールの公開リポジトリURL
• 秘密情報ではなく慣例として使われる公開APIエンドポイント（例：localhost:31337/notify）
• プレースホルダーであることが明確なサンプル値（<url>、<SESSION_ID>、[email protected]）
• 汎用的な環境変数の名前（値は不可）：STRIPE_API_KEY、OPENAI_API_KEY

出荷前ゲート（すべてのスキル — 公開・非公開を問わず）

スキルを出荷または変更する前に、衛生チェックを実行してください：

bun ~/.claude/LIFEOS/TOOLS/SkillHygieneGate.ts --skill <SkillName>

これは、標準拒否リスト（LIFEOS/USER/SECURITY/DENY_LIST.txt — このリストはアイデンティティデータであるため、USERツリーに置かれます）とホームパスの形式に照らしてスキャンします。終了コード0 = 問題なし。違反があれば、データを LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/（または標準のUSERホーム）に移動し、パスで参照してください。2026-07-23以降、非公開スキルの例外はありません。_ALLCAPS が決めるのはスキルをどこに出荷するか（どこにも出荷しない）であり、ファイルに何を含めてよいかではありません。

---

フラットなフォルダー構造（必須）

重要：フォルダー構造はフラットに保ち、深さは最大2階層にしてください。

ルール

最大の深さ： skills/SkillName/Category/

✅ 許可（最大2階層）

skills/SkillName/SKILL.md                    # Skill root
skills/SkillName/Workflows/Create.md         # Workflow - one level deep - GOOD
skills/SkillName/Tools/Manage.ts             # Tool - one level deep - GOOD
skills/SkillName/QuickStartGuide.md          # Context file - in root - GOOD
skills/SkillName/Examples.md                 # Context file - in root - GOOD

❌ 禁止（深すぎる、または場所が不適切）

skills/SkillName/Resources/Guide.md              # Context files go in root, NOT Resources/
skills/SkillName/Docs/Examples.md                # Context files go in root, NOT Docs/
skills/SkillName/Workflows/Category/File.md      # THREE levels - NO
skills/SkillName/Templates/Primitives/File.md    # THREE levels - NO
skills/SkillName/Tools/Utils/Helper.ts           # THREE levels - NO

許可されるサブディレクトリ

次のサブディレクトリは許可されています：

• Workflows/ - 実行ワークフローのみ
• Tools/ - 実行可能なスクリプト／ツールのみ
• References/ - 大規模なスキル向けの拡張リファレンス資料（APIドキュメント、詳細なガイド）

コンテキストファイル（ドキュメント、ガイド、リファレンス）はスキルのルート、またはReferences/に置いてください。

References/を使用する場合： SKILL.mdが約500行を超え、相当量のリファレンスコンテンツ（APIシグネチャ、詳細な例、トラブルシューティングガイド）を含む場合に使用します。SKILL.mdはルーティングガイドとして保ち、百科事典的な内容はReferences/に移動してください。

理由

1. 見つけやすさ - ファイルを簡単に見つけられます
2. シンプルさ - 移動にかかる手間を減らせます
3. 速度 - ファイル操作が速くなります
4. 一貫性 - すべてのスキルで同じパターンに従います

多数のワークフローを整理する必要がある場合は、サブディレクトリではなく、わかりやすいファイル名を使用してください：

参照先： ~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md（フラットなフォルダー構造のセクション）

---

動的読み込みパターン（大規模なスキル）

SKILL.mdが100行を超えるスキルでは： スキル呼び出し時のコンテキストを減らすため、動的読み込みを使用してください。

読み込みの仕組み

セッション開始時： ルーティング用にフロントマターのみを読み込みます スキル呼び出し時： SKILL.md全体を読み込みます コンテキストファイル： ワークフローから参照された場合にのみ読み込みます

パターン

SKILL.md = 最小限（30～50行）— スキル呼び出し時に読み込み

• トリガーを含むYAMLフロントマター
• 簡単な説明
• ワークフローのルーティング表
• クイックリファレンス
• コンテキストファイルへの参照

追加の.mdファイル = コンテキストファイル — 特定の側面に関するSOP（必要に応じて読み込み）

• これらは単なるドキュメントではなく、標準作業手順書です
• 具体的な対応手順を示します
• Workflows/、Tools/などを参照できます

🚨 重要：Context/サブディレクトリは禁止 🚨

Context/またはDocs/サブディレクトリを作成してはいけません。

追加の.mdファイルがコンテキストファイルです。スキルのルートに直接置いてください。

誤り：

skills/Art/
├── SKILL.md
└── Context/              ❌ NEVER CREATE THIS
    └── Aesthetic.md

正しい例：

skills/Art/
├── SKILL.md
├── Aesthetic.md          ✅ Context file in skill root
├── Examples.md           ✅ Context file in skill root
└── Tools.md              ✅ Context file in skill root

スキルディレクトリ自体がコンテキストです。

構成例

skills/Art/
├── SKILL.md              # 40 lines - minimal routing
├── Aesthetic.md          # Context file - SOP for aesthetic
├── Examples.md           # Context file - SOP for examples
├── Tools.md              # Context file - SOP for tools
├── Workflows/            # Workflows
│   └── Essay.md
└── Tools/                # CLI tools
    └── Generate.ts

最小限のSKILL.mdテンプレート

---
name: SkillName
description: Create, test, and optimize LifeOS skills — scaffolding, effectiveness testing, description optimization. USE WHEN create skill, new skill, validate skill, test skill, improve skill, optimize description.
---

# SkillName

Brief description.

## Workflow Routing

| Trigger | Workflow |
|---------|----------|
| "trigger" | `Workflows/WorkflowName.md` |

## Quick Reference

**Key points** (3-5 bullet points)

**Full Documentation:**
- Detail 1: `SkillSearch('skillname detail1')` → loads Detail1.md
- Detail 2: `SkillSearch('skillname detail2')` → loads Detail2.md

使用するタイミング

✅ 次の場合は動的読み込みを使用します：

• SKILL.md が100行を超える
• ドキュメントのセクションが複数ある
• API リファレンスが広範にわたる
• 詳細な例がある

❌ 次の場合は使用しないでください：

• シンプルなスキル（50行未満）
• 単純なユーティリティラッパー（代わりにLIFEOS/TOOLS.mdを使用）

メリット

• トークンの節約： スキルの呼び出し時に70％以上削減（ドキュメント全体が不要な場合）
• 整理： SKILL.md ＝ルーティング、コンテキストファイル＝特定の側面に関するSOP
• 効率性： ワークフローは実際に必要なものだけを読み込みます
• 保守性： 個々のセクションを簡単に更新できます

参照： ~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md（Dynamic Loading Pattern セクション）

---

ワークフローのルーティング

構造ワークフロー（スキャフォールディングと規約）

ワークフロー	トリガー	ファイル
CreateSkill	「新しいスキルを作成」	Workflows/CreateSkill.md
ValidateSkill	「スキルを検証」「スキルを確認」	Workflows/ValidateSkill.md
UpdateSkill	「スキルを更新」「ワークフローを追加」	Workflows/UpdateSkill.md
CanonicalizeSkill	「正規化」「スキルの構造を修正」	Workflows/CanonicalizeSkill.md

有効性ワークフロー（テストと最適化）

ワークフロー	トリガー	ファイル
TestSkill	「スキルをテスト」「このスキルは動作するか」「スキルが動作しない」	Workflows/TestSkill.md
ImproveSkill	「スキルを改善」「スキルの品質」「スキルの指示を修正」	Workflows/ImproveSkill.md
OptimizeDescription	「説明を最適化」「スキルが起動しない」「トリガーの精度」	Workflows/OptimizeDescription.md

スキルの種類（作成前に選択）

スキルを作成する前に、Anthropicの社内スキル分類（Thariq Shihipar、2026年3月）に基づく9種類のうち、どれに該当するかを特定してください。種類によって構造やテスト方法の判断が変わります。

種類	焦点	主な構造	例
1. ライブラリ／APIリファレンス	Claudeが誤りやすい落とし穴、エッジケース	軽量、落とし穴を重視、リファレンス用スニペット	HonoReference、D1Reference
2. 製品の検証	コードの動作をテスト／検証	状態のアサーション、ブラウザーの自動化、出力の記録	Browser
3. データ取得	データシステムへの接続	認証情報の参照、クエリパターン、ダッシュボードへのポインター	USMetrics、ビジネスメトリクスのスキル
4. ビジネスプロセス	反復的なワークフローの自動化	実行ログ、一貫性の追跡	タスクトラッカーのスキル、シンジケーションのスキル
5. コードスキャフォールディング	フレームワークのボイラープレートを生成	テンプレートファイル、プロジェクトを考慮したスクリプト	CreateCLI、CreateSkill
6. コード品質	標準の適用、レビュー	決定論的なスクリプト、フックとの統合	/simplify、/code-review
7. CI/CDとデプロイ	安全パターンに基づくデプロイ	デプロイ前チェック、スモークテスト、ロールバック	（未対応 — Deployスキルが必要）
8. 運用ランブック	現象を診断方法に対応付ける	現象 → ツール → クエリ → レポート	サイトヘルスのスキル
9. インフラ運用	安全対策を備えたメンテナンス	安全ゲート、監査ログ、孤立したリソースの検出	システム管理のスキル、dotfilesのスキル

スキル作成のガイダンス

スキルの指示を作成または改善する際は、Anthropicのskill-creatorの方法論、およびThariq Shihiparの「Lessons from Building Claude Code」（2026年3月）にある次の原則に従ってください：

基本原則

• 自明なことは書かないでください。 Claude はプログラミングに長けており、コードベースを把握しています。Claude のデフォルトのパターンから外れる情報、つまり指示がないと間違えることに注力してください。判断基準：「言われなければ、Claude はこれを間違えるでしょうか？」そうでなければ、削除してください。
• 何をするかだけでなく、なぜそうするかを説明してください。 心の理論が優れ、明確な推論ができるモデルは、厳格な制約を課すモデルよりも良い結果を出します。「必ず箇条書きで3項目」と指示するのではなく、箇条書きが対象読者にとって重要な理由を説明してください。
• 簡潔にしてください。 コンテキストウィンドウは共有資源です。出力を改善しない指示は削除してください。テストの記録から、エージェントが実りのない手順に時間を浪費していると分かったら、その手順を削除してください。SKILL.md は500行未満にしてください。
• 強調するだけの行は削除してください。 ルールは一度述べれば指示になります。MANDATORY、CRITICAL、「任意ではない」といった表現や、3度目の言い換えは、制約を強めず分量を増やすだけです。モデルが従うのは強調ではなく、具体性とコードです。他の箇所ですでに述べたルールを声高に繰り返すだけの行は削除してください。## Best Practices / ## Tips セクションには注意してください。ここには「徹底する」「シンプルに保つ」「慎重に検証する」といった、デフォルトの動作を言い換えただけの余計な記述が集まりがちです。すべての行に対し、Prompting/Standards.md § Signal-to-Noise の削除テストを実施してください。その行を削除し、具体的にどのデフォルト動作以外の行動を促すのか説明できる場合にのみ、元に戻してください。
• 過剰適合ではなく、一般化してください。 特定のテスト失敗ではなく、根本的なパターンを修正してください。スキルはテストセット以外のさまざまなプロンプトにも使われます。
• 繰り返しの作業はまとめてください。 テストエージェントがそれぞれ同じようなヘルパースクリプトを作成した場合は、そのスクリプトを Tools/ に追加し、以降のすべての実行で活用できるようにしてください。
• 適切な自由度を設定してください。 タスクの失敗しやすさに応じて具体性を調整してください。データベースのマイグレーションには正確なコマンドが必要ですが、コードレビューには大まかな指針で十分です。
• 制約を課しすぎないでください。 スキルは繰り返し使われます。具体的すぎる指示は避けてください。必要な情報は提供しつつ、さまざまな状況に対応できる余地を残してください。

説明のベストプラクティス

• 説明は人間ではなくモデル向けです。 説明はシステムプロンプトに挿入されます。Claude はそれを読み、スキルを呼び出すかどうかを判断します。
• 説明には少し強めの表現を使ってください。 モデルはスキルを呼び出さない傾向があります。ユーザーがスキルについて明示的に触れていなくても、具体的な状況を挙げてください。
• 混同されやすいスキルには、対象外の条件を含めてください。 スキル間で用語が重複する場合は、「NOT FOR」の条件を追加してください（例："NOT FOR web pentesting (use WebAssessment)"）。
• 呼び出しが少なすぎる兆候： 必要な場面でスキルが読み込まれない、ユーザーが手動で呼び出している。
• 呼び出しが多すぎる兆候： 関係のない質問でスキルが読み込まれる、ユーザーがスキルを無効にしている。

Gotchas セクション（必須）

すべてのスキルには、ワークフローの振り分け表の後に ## Gotchas セクションを必ず設けてください。Thariq 曰く：「どのスキルでも、最も情報密度が高いのは Gotchas セクションです。」

以下を記載してください。

• Claude が知らない API の癖
• 使用中に確認されたよくあるミス
• 自明ではない順序や手順の要件
• 失敗しても気づきにくいエッジケース

Gotchas は時間とともに蓄積されます。 スキルが失敗するたびに、その教訓を追加してください。

理想状態のプロンプト設計（HOW ではなく WHAT）— 必須の執筆スタイル

新しいスキルの本文とワークフローはすべて、理想状態のスタイルで記述してください。完了した成果物がどのようなものか（テスト可能な成果として）、制約、ツールを明確にしたうえで、HOW はモデルに任せます。 オープンエンドな認知作業について、モデルの推論を手順どおりに進める番号付きのステップリストは、BPE に違反する足かせです。能力の高いモデルの力を制限し、モデルの進化とともに時代遅れになります。スキルで正当な HOW として認められるのは、次の 4 つです。安全ゲート、検証済みの注意点（## Gotchas はこのためにあります）、ツール契約（ワークフローにおける正確な呼び出し手順）、出力形式の契約。決定論的なツール（*.ts）は対象外です。スキルを新規作成または改善するときは、手法の説明を削り、理想状態、制約、ツール、および上記 4 つのクラスだけを残してください。完全な標準については、LIFEOS/DOCUMENTATION/Skills/SkillSystem.md § Authoring Standard を参照してください。

BPE（Bitter-Pilled Engineering）チェック

スキルを仕上げる前に、次の問いを投げかけてください。「より賢いモデルなら、このスキルは不要になるだろうか？」

• 耐性がある（残す）： 検証ハーネス、データパイプライン、ツールラッパー、蓄積された注意点、決定論的なスクリプト
• 脆弱（再検討する）： CoT オーケストレーター、形式パーサー、再試行カスケード、複雑な推論の足場

スキルは、Claude が導き出せない知識（失敗パターン、API の癖）、Claude が再現できないツール（API 呼び出し、自動化）、一貫性が役立つワークフローに重点を置いてください。

段階的な情報開示（Anthropic による）

情報を読み込む 3 つのレベルです。大規模なスキルを管理するために活用してください。

1. レベル 1（YAML フロントマター）： 常にシステムプロンプトに含まれます。トリガー情報のみです。
2. レベル 2（SKILL.md の本文）： スキルの呼び出し時に読み込まれます。ルーティングと主要な指針です。
3. レベル 3（参照ファイル）： ルートレベルの .md ファイル、または References/ サブディレクトリにあり、必要に応じて読み込まれます。

どのファイルがあるかを Claude に伝えてください。適切なタイミングで読み込みます。SKILL.md は 500 行未満にしてください。それを超える場合は、詳細な内容を参照ファイルに切り出してください。

テストのベストプラクティス（Anthropic による）

スキルのテストには 3 つのレベルがあります。

1. 手動テスト — クエリを実行し、挙動を観察します
2. スクリプトによるテスト — テストケースを自動化します（TestSkill ワークフローを使用）
3. プログラムによるテスト — 評価スイートを構築します（Evals スキルを使用）

評価駆動開発： スキルの構築を始める前に、「このスキルが機能している」状態を定義します。Claude が成功するまで、難易度の高い単一のタスクで反復し、その後、成功したアプローチを抽出します。

オンデマンドフックのパターン（Anthropic による）

スキルには、呼び出されたときだけ有効になり、セッション中は効果が持続するフックを含められます。

• /careful — 危険なコマンド（rm -rf、DROP TABLE、強制プッシュ）をインターセプトします
• /freeze — 指定したディレクトリ以外への編集をブロックします
• /audit — セッションレビュー用に、すべてのツール呼び出しを記録します

上記の指針はすべて、Thariq Shihipar の「Lessons from Building Claude Code」（2026 年 3 月）、Anthropic の公式スキルガイド、およびプラットフォームのドキュメントに基づいています。

バージョン管理

各スキルは、SKILL.md のフロントマターに独自の version: セマンティックバージョンを持ちます（Major.Feature.Patch — 中央の数字は「minor」ではなく Feature です）。OS のバージョンや他のスキルのバージョンとは独立しています。新しいスキルは version: 1.0.0 で生成されます。スキルの変更は OS の変更でもあります。skills/ は LifeOS のバージョン管理システムが監視するコアファイル領域に含まれているためです。そのため、スキルを編集すると、スキル独自のバージョンと（集約された）正式な LIFEOS/VERSION の両方が更新されます。この2つの行は別々のものです。スキルの version: はそのスキル独自の系譜を示し、LIFEOS/VERSION は全体を統括するバージョンです。CreateSkill が LIFEOS/VERSION 自体を編集することはありません。

変更を分類し、適切なバージョン更新レベルを選んでください（同じ基準をスキル単位の更新と集約バージョンの更新の両方に適用します）。

• patch — 注意点の追加、誤字の修正、説明の微調整、ドキュメントの同期。新しい機能はありません。
• feature — 新しいワークフローまたは新しいツール（まったく新しいスキルは自身の feature 更新ではなく、1.0.0 から開始します）。追加的で、互換性を損ないません。
• major — スキルの名称変更や削除、または公開契約やルーティング動作の破壊的変更。人による確認が必要です。major 更新の前に停止して確認してください。独断で major と判断してはいけません。

スキル単位のバージョン更新が行われるタイミング： 編集時ではなく、プライベート同期時です。UpdateKaiRepo の出荷フローは BumpSkillVersions.ts を実行します。前回の OS タグ以降に変更されたすべての skills/<name>/ に対して ClassifyChange --path skills/<name> を適用し、そのスキルの version: を更新します（major は確認まで保留）。更新内容はそれぞれ SYSTEMUPDATES レジストリに記録されます。これにより、CreateSkill を経由しないワークフロー本文の編集も検出されます。ここで version: を手動更新してはいけません。出荷フローが管理します。（この出荷フローはメンテナー向けの仕組みであり、公開リリースには含まれません。インストール済みシステムにこの仕組みがない場合は、編集時に上記のセマンティックバージョン基準に従って version: を手動更新してください。）スキルの編集は プライベート同期 の変更です。リリースの カット（ステージングのみ）でも 公開（公開リポジトリ）でもありません。この3つの操作を明確に区別してください。

公開スキルには個別のバージョン行はありません。リリース／出力では、各スキルのプライベートな version: が変更されずに引き継がれます。

（このインストール層の具体的なコマンド／パスは、上記の Customization ブロックがある場合はそちらを参照してください。）

例

例1：新しいスキルをゼロから作成する

User: "Create a skill for managing my recipes"
→ Invokes CreateSkill workflow
→ Reads SkillSystem.md for structure requirements
→ Creates skill directory with TitleCase naming
→ Creates SKILL.md, Workflows/, Tools/
→ Suggests running TestSkill to verify effectiveness

例2：適切にルーティングされない既存のスキルを修正する

User: "The research skill isn't triggering - validate it"
→ Invokes ValidateSkill workflow
→ Checks SKILL.md against canonical format
→ Verifies TitleCase naming and USE WHEN triggers
→ Reports compliance issues with fixes

例3：スキルが実際に役立つかテストする

User: "Test the Blogging skill to see if it's effective"
→ Invokes TestSkill workflow
→ Generates 3 realistic test prompts
→ Spawns with-skill and baseline agents in parallel
→ Compares outputs, presents results
→ Iterates with ImproveSkill based on feedback

例4：関連するプロンプトでスキルが起動しない

User: "The Security skill doesn't trigger when I ask about pentesting"
→ Invokes OptimizeDescription workflow
→ Generates 20 should/shouldn't-trigger queries
→ Tests description accuracy via subagents
→ Rewrites description, re-tests, reports improvement

例5：出力の質が低いスキルを改善する

User: "The research skill output is too verbose — improve it"
→ Invokes ImproveSkill workflow
→ Reads skill + user feedback
→ Diagnoses root cause (over-specified instructions)
→ Rewrites with reasoning instead of rigid MUSTs
→ Suggests TestSkill to verify improvement

注意点

• このファイル自体の説明は約1022文字で、上限の1024文字まであと2文字です。 フロントマターの説明に文字を追加する編集を行う場合は、保存前に必ず再計測してください（2026-06-13 の監査）。
• このファイルには ## Workflow Routing ヘッダーが2つあります。 1つ目（約 l.276）は埋め込みテンプレートの例の中にあり、2つ目（約 l.315）が実際のヘッダーです。ヘッダーを走査するツールは、最初ではなく最後の一致を採用してください。
• このスキルのワークフローを読んで、手作業で手順を実行するのは手作業での模倣というアンチパターンです。 skills/CLAUDE.md では、スキルを模倣するのではなく呼び出すことが求められています。Gotchas セクションを必須とするスキル自体に、2026-06-13 までそのセクションがありませんでした。チェックリスト項目はこのスキルにも適用されるものとして扱ってください。

実行ログ

ワークフローの完了後、JSONL エントリーを1つ追加してください。

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"CreateSkill","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

WORKFLOW_USED は実行したワークフローに、8_WORD_SUMMARY は入力の簡潔な説明に、SECONDS はおおよその実時間に置き換えてください。ワークフローが失敗した場合は、status: "error" を記録してください。