skillify

/skillify — スキルを作成、適応、または更新する

1つのスキルに4つのモードがあります。入力のシグナルに基づいて、適切なモードに自動で振り分けます。

以前の create-skill、adapt-skill、update-skill を統合して置き換えます（-ify の3本柱で用語を統一するため、v0.2.0 ですべて統合されました）。

ステップ 0 — モードを検出する

シグナルに基づいて振り分けます。

シグナル	モード
実質的な最近のワークフローについて会話している途中で呼び出された	CREATE / from-chat（デフォルト）
/skillify from-video <url> または /skillify + 動画 URL	CREATE / from-video
/skillify from-dump + 貼り付けられた概要／文字起こし／メモ	CREATE / from-dump
/skillify from-scratch <name> または、コンテキストなしで「X という新しいスキルを作って」	CREATE / from-scratch
/skillify <github-url> または、外部ソースとともに「このスキルを適応して」／「このスキルを移植して」／「このスキルをフォークして」	ADAPT
/skillify <existing-skill> <change> または「X スキルを更新して」／「この学びを反映して」	UPDATE / targeted
/skillify update（会話の途中）	UPDATE / from-chat — 最近のチャットから学びを探します
/skillify usage <skill>	UPDATE / usage — 最近の実行を確認し、改善案を提案します
/skillify test <skill-or-path> または「このスキルをテストして」／「X を実行して」／「X をドライランして」	TEST — 評価基準に照らしてシミュレーションします

曖昧な場合は、作業を進める前に確認してください。外部 URL が関係する場合、CREATE と ADAPT のどちらかを決して推測しないでください。

---

モード：CREATE

チャット／動画／ダンプ／一からの作成を基に、新しいスキルを作成します。

ステップ 1 — 入力ソースを確認する

サブモード	内容
from-chat（デフォルト）	この会話で話し合ったワークフローからスキルを抽出します。最も一般的なケースです。
from-video	ユーザーが Loom／Zoom／画面共有を録画しています。ビジュアルモードで watch-video を呼び出し、文字起こしと重要な視覚的場面から SKILL.md を作成します。視覚的要素や UI が中心のワークフローに最適です。
from-dump	ユーザーが概要、過去の会話の文字起こし、書き出したチャット、またはメモを貼り付けます。
from-scratch	ソース資料のない新しいアイデアです。対話形式の質疑応答で進めます。

ステップ 2 — スキーマは Anthropic のガイダンスに従う

SKILL.md の書式ルールを一から作らないでください。フロントマター、説明文の作成、references/ の構成、スキルのベストプラクティスについては、以下を参照してください。

• compound-engineering:create-agent-skill（エージェント）— Claude Code スキルの作成と編集に関する専門的なガイダンス
• compound-engineering:skill-creator（スキル）— 効果的なスキル作成の詳細なガイド
• compound-engineering:heal-skill（スキル）— 既存のスキルの修正用
• anthropics/skills — Anthropic 公式の例
• agentskills.io — Agent Skills のオープン仕様

書式に迷った場合は、これらを直接参照してください。skillify が統括するのは、どのリポジトリを使うか、どの規約に従うか、どの相互参照を含めるかといった、あなたのワークフローです。書式に関する専門知識は上流にあります。

ステップ 3 — 対象リポジトリを選択する

${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/skillify/repos.yaml があれば、そこからユーザーの兄弟リポジトリ一覧を読み込みます。なければ、デフォルトで makerskills（このリポジトリ）を使います。形式の例：

# ~/.config/makerskills/skillify/repos.yaml
repos:
  - name: makerskills
    domain: Personal cross-cutting operator work
    path: ~/code/makerskills
  - name: marketingskills
    domain: Generic marketing tactics
    path: ~/code/marketingskills

スキルの分野から対象を明確に判断できる場合は推定し、曖昧な場合は確認してください。

ステップ 4 — サブモードごとに統合する

from-chat:

1. この会話をさかのぼって読みます。何度も繰り返されているワークフロー、再説明されたプロセス、改めて述べられた意見、ツールや文体、出力に関する決定を探します。
2. 重要な要素を特定します。トリガー、手順、参照資料、成功時の形、文体です。
3. スキャフォールディングの前に確認が必要な不足点を洗い出し、簡潔な質問を2〜4つします。
4. SKILL.md を作成し、ユーザーが確認できるよう、チャット内の発言を引用として本文中に示します（「X についてのあなたのメッセージによると……」など）。

from-dump:

1. ダンプ（Notion ページ、Slack スレッド、Loom のトランスクリプト、チームメイトからのブリーフ、エクスポートした ChatGPT の会話）を解析します。
2. from-chat と同じ統合ロジックを使います。
3. 各ルールの出典となったダンプ内の箇所を引用します。

from-video:

1. URL またはローカルパスを受け取ります。
2. watch-video <url> visual を呼び出し、トランスクリプト、重要な視覚的場面、要約を取得します。
3. 出力を読み込みます。<workdir>/transcript.txt、<workdir>/moments.md、<workdir>/summary.md。
4. 統合します。トリガー（最初の30秒）、手順（視覚的な場面と対応するトランスクリプト）、使用ツール、判断ポイント（「X なら Y をする」という場面）、成功時の形（最後の数秒）、話し方のリズムをまとめます。
5. 不明確な場面など、確認が必要な不足点を洗い出します。
6. タイムスタンプを引用しながら SKILL.md を作成します。
7. 必要に応じて、ソースを second-brain に call-<slug>.md または note-<slug>.md として保存できます。

ヒューリスティック：録画が10分を超える場合、1つのスキルにするにはプロセスが大きすぎる可能性があります。作成前に分割するよう提案してください。

from-scratch: 対話形式の Q&A：

1. 名前（ケバブケース。watch-video、read-book、paste に合わせ、動詞-名詞の形式を推奨）
2. 目的を一行で説明
3. トリガーフレーズ（4〜8個）
4. 最初に参照するファイルはありますか？
5. ほかのどのスキルと組み合わせますか？

ステップ 5 — フロントマターを生成する

---
name: <kebab-case>
description: <rich, trigger-rich, ~2–4 sentences. Lead with "When you want to..." Include 4–8 trigger phrases in quotes. Differentiate from adjacent skills.>
metadata:
  version: 0.1.0
---

説明のルール（重要 — エージェントは説明との一致度に基づいてルーティングします）：

• ユースケースから始めます（「X したい場合に……」）
• 明示的なトリガーフレーズを含めます
• 関連する他のスキルとの違いを明確にします
• スキルが読み込む主要な参照資料に触れます
• 約500文字以内にします（Agent Skills 仕様の上限は1024文字ですが、より厳しいホストでは長すぎる説明が拒否される場合があります）

説明の書き方について詳しくは、compound-engineering:skill-creator を参照してください。

ステップ 6 — ディレクトリをスキャフォールディングする

<target-repo>/skills/<name>/
├── SKILL.md
└── references/
    └── ...

本文は既存のスキル（pm、decide、second-brain）のパターンに従います：

• # /<name> — <one-line purpose>
• 番号付きの ## Step N — <phase> セクション
• 組み合わせ可能なスキルへの相互参照
• 最後に品質に関する注記

ステップ 7 — README を更新し、コミットしてプッシュする

対象リポジトリの README にあるスキルの表に追記します：

| [`<name>`](./skills/<name>/SKILL.md) | <one-line purpose> |

コミットしてプッシュします。新しいスキルのパス、コミットハッシュ、および /plugin install やシンボリックリンクの更新が必要になる場合があることを伝えます。

ステップ 8 — 次の対応を提案する

• 「コミットする前に、下書きを TEST モードで実行しますか？」（ユーザーへの質問があるスキルでは推奨）
• 「特定のステップを今、詳しく作り込みますか？ それとも後で再開しますか？」
• 「品質確認として compound-engineering:heal-skill を実行しますか？」
• 「このスキルを [関連するスキル] と組み合わせますか？」

---

モード：ADAPT

外部のスキル（GitHub URL、agentskills.io、ローカルディスク、または貼り付けられた SKILL.md）を自分の名前空間に移植します。

ステップ 1 — ソースを取得する

次を受け付けます：

• GitHub URL：SKILL.md またはリポジトリ（https://github.com/<owner>/<repo>、または SKILL.md へのフルパス）
• agentskills.io URL または skills.sh URL
• ローカルパス：ディスク上の既存スキル（他のインストール済みプラグインなど。Claude Code では ~/.claude/plugins/、それ以外では ~/.agents/skills/ または ~/.codex/skills/）
• 貼り付けられた SKILL.md の内容

# GitHub repo: clone shallow
git clone --depth 1 <url> /tmp/skillify-adapt-<short-id>/
# OR fetch a single file
gh api -H "Accept: application/vnd.github.raw" repos/<owner>/<repo>/contents/SKILL.md > /tmp/adapt-source.md

帰属先を変更されないリビジョンで示せるよう、コミット SHA を記録します。

ステップ 2 — 分析 + 分類

ソースの SKILL.md と、それが同梱する references/ を読みます。references/adapt-buckets.md に従って 3 つのバケットに分類します:

バケット	内容	例
そのまま保持	フォーマット、スキーマ、仕組み、スクリプト、フレームワーク	問題バンク、ffmpeg フラグ、正規表現パターン、JSON スキーマ
適応	ツールのデフォルト、パス、文体、命名、方針	相手の動画ツール → あなたの watch-video、相手のカンバン → あなたの pm、相手の文体 → あなたの文体
追加	既存スキルへの相互参照、組み合わせに関する注記、あなたの規約	「decide と組み合わせる」「second-brain raw/ に保存する」「MLX-Whisper ローカルを使用する」

何かを書き込む前に、分類を表として出力して承認を得ます。黙って書き換えないでください — 変更点を明示します。

ステップ 3 — ライセンス確認

ソースの LICENSE を読みます。references/adapt-license-check.md に従います:

ライセンス	対応
MIT / Apache-2.0 / BSD / ISC / CC0	✅ グリーン — 続行
MPL-2.0 / LGPL	🟡 イエロー — 適応は OK。ファイル単位の相互性について警告
GPL-2.0 / GPL-3.0 / AGPL	❌ レッド — 伝染リスク。続行前に明示する。
プロプライエタリ / ライセンスなし	❌ レッド — 中止。コピーの法的根拠がない。
不明	🟡 イエロー — 確認する。不確かな場合はスキップをデフォルトとする

寛容なライセンスの場合、帰属表示だけが要件です — ステップ 6 で対応します。

ステップ 4 — 対象リポジトリを選ぶ

CREATE のステップ 3 と同じ表です。

ステップ 5 — 書き換え

そのまま保持: そのままコピーします。役立つ場合は `` マーカーを追加します。

適応:

• 命名: 動詞-名詞になっていなければ名前を変更する(watch-video、read-book、paste に合わせる)
• ツールの差し替え: 相手の汎用カンバン → pm、相手の動画ツール → watch-video、相手のノートシステム → second-brain、相手の意思決定フレームワーク → decide
• 文体: あなたの文体ルールを適用する — 直接的で、確信を込めた表現。ソーシャル系のスキルには、リンク配置ルールを適用する。
• パス: 相手の ~/outputs/ → あなたの ~/Documents/<skill>-<...>/ 規約;相手の設定 → あなたの references/ パターン
• 名前 + 文脈: 汎用的な例 → スキルがそれを必要とする場合は、あなたのポートフォリオの文脈

追加:

• 既存の兄弟スキルへの相互参照
• 組み合わせに関する注記(このスキルが呼び出す、または供給する他のスキル)
• あなたの規約(frontmatter の version、references/ サブディレクトリ構造、サブアイデアを生む場合は BACKLOG エントリ)

ステップ 6 — 帰属表示ファイル

references/attribution.md を書きます:

# Attribution

- **Source**: <original SKILL.md URL>
- **Repository**: <repo URL>
- **Author**: <name + handle>
- **Commit SHA**: <SHA at time of adapt>
- **License**: <license name + URL>
- **Adapted**: <YYYY-MM-DD>

## What was kept verbatim
- ...

## What was adapted
- <old> → <new>

## What was added
- ...

## License compliance
<upstream LICENSE text if MIT/BSD/Apache requires it, OR reference where in this repo it lives>

## Upgrade path
Run `git ls-remote <repo-url> HEAD`. If SHA differs from above, re-run `/skillify <same-url>` for a 3-way merge.

MIT / Apache / BSD の場合、LICENSE のテキストをこのファイルにコピーするか、ソースの LICENSE ファイルをスキルディレクトリにコピーします。

ステップ 7 — 雛形作成 + コミット

CREATE のステップ 6〜7 と同じです。コミットメッセージ: "Adapt <name> skill from <source-name>"。

ステップ 8 — 報告 + フォローアップの提案

• コミットハッシュ + 新しいスキルのパス
• 差分が明確になるよう、3 バケットの分類をもう一度示す
• 提案:
  • 「適応部分を肉付けしますか？デフォルトの一部はまだあなたの手を必要とするかもしれません。」
  • 「compound-engineering:heal-skill を QA パスとして実行しますか？」
  • 「loopify でアップストリームチェックのリマインダーを設定しますか？」

---

モード: UPDATE

学びをもとに既存のスキルを改善します。

ステップ 1 — サブモードを確認

サブモード	いつ
from-chat(デフォルト)	最近の会話から学びをスキャンし、影響を受けるスキルを特定する
from-dump	ユーザーがブリーフ、フィードバック、トランスクリプト、ポストモーテムを提供する
targeted	ユーザーがスキル + 変更を直接指定する。探索をスキップ。
usage	指定されたスキルの最近の実行をレビューし、ギャップを特定する

実質的な最近の活動がある会話の途中で呼び出された場合のデフォルト: from-chat。

ステップ 2 — 学びを抽出する

チャット／ダンプ／使用状況から抽出する場合は、変更に値するシグナルを探します（分類の全容は references/update-change-types.md を参照）。

• 修正 — 「もうそれはしないで」
• 検証 — 「うまくいったので、標準にしてください」
• 新しいパターン — ユーザーが未文書化のワークフローを実行したので、記録します
• 文体／トーンの更新 — スライドデッキの読み上げルールなど
• ツールの変更 — デフォルトを切り替えた
• アーキテクチャ上の決定 — 命名規則、ファイル構成、フロントマター
• 不足 — スキルが対応すべきだったのに、対応できなかったこと

それぞれを単一の変更として表現した、明確な N 件の学び のリストを出力します。

targeted の場合：抽出は省略します。ユーザーがすでに変更内容を指定しています。

ステップ 3 — 影響を受けるスキルを特定する

学びごとに、現在のリポジトリ内のすべての SKILL.md と references/ を検索します（また、必要に応じて --cross-repo を指定して repos.yaml にあるすべての兄弟リポジトリも検索します）。

grep -rln "<key terms>" ~/code/makerskills/skills/ --include="*.md"

# Across all sibling repos (list yours in $MAKERSKILLS_CONFIG/skillify/repos.yaml):
config="${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/skillify/repos.yaml"
for raw in $(yq -r '.repos[].path' "$config"); do
  repo="${raw/#\~/$HOME}"  # expand leading ~ to $HOME so grep resolves the real path
  grep -rln "<terms>" "$repo/skills/" --include="*.md" 2>/dev/null
done

確信度で分類します。

確信度	内容	対応
高	直接的なキーワードの一致があり、トピックも明らかに同じ	変更を提案する
中	関連するトピックで、ルールが当てはまる可能性がある	明示的な承認を求める
低	関連性が薄く、ルールを拡大解釈しないと当てはまらない	言及するが、提案はしない

スキル間の伝播方法については、references/update-propagation.md のプレイブックを参照してください。

ステップ 4 — メモリとスキルの振り分けを確認する

学びごとに、この内容は特定のスキルに限られるものか、それともより広く適用される原則かを確認します。

種類	保存先
スキル固有のルール	SKILL.md または references ファイルを直接編集する
複数のスキルにまたがる原則	メモリストアの feedback_<topic>.md（エージェントのメモリ、または ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/）
両方	メモリファイルを作成し、すぐに適用されるスキルも更新する

例：「リンクは本文ではなく最初のコメントに記載する」 → jab-hook に適用され、より広いソーシャルメディアの原則でもあるため、jab-hook を更新するとともに feedback_social_link_placement.md を保存します。

メモリへの書き込みを明示的に提案します。「これは単なるスキルのルールではなく、原則のようです。feedback_<slug>.md としてメモリに保存しますか？」

ステップ 5 — ファイルごとに差分を提案する

影響を受けるファイルごとに、変更前／変更後、または統一差分で変更内容を示します。

### `skills/<skill>/SKILL.md` — proposed change

**Before** (lines NN–NN):
> <existing text>

**After**:
> <new text>

**Why**: <one-line rationale>

**Version bump**: 0.2.0 → 0.2.1 (PATCH — clarification)

**Approve / edit / skip?**

ファイルごとに承認を得ます。まとめてはいけません。小さな変更なら簡単に承認できますが、まとめるとすべてを一括で承認するか、却下するかになってしまいます。

セマンティックバージョニングのルールについては、references/update-versioning.md を参照してください。

ステップ 6 — 承認された変更を適用する

1. Edit を使って、承認された変更をそのまま適用します
2. 推奨されるレベルに応じて metadata.version を上げます
3. 名前の変更を伴う場合は、相互参照の更新手順に従います（すべてのファイルを grep し、参照をすべて更新します）

1 つのスキル内で複数のファイルを変更する場合は、1 つのコミットにまとめます。

ステップ 7 — コミットしてプッシュする

スキルごとにまとめます。例：

• 1 つのスキルの更新："slide-deck: 読み上げる声を重視する（ページではなく耳に向けて書く）"
• 複数スキルへの伝播："jab-hook, marketingskills:social: リンクの配置（URL を本文に入れない）"
• 複数リポジトリにまたがる変更：リポジトリごとに 1 つのコミットにします。リポジトリをまたいでアトミックコミットしてはいけません。

ステップ 8 — 報告する

以下を示します。

• 抽出した学び
• 更新したスキル（バージョンの変更を含む）
• 作成したメモリファイル
• compound-engineering:heal-skill が QA に役立つかどうか
• TEST の実行が妥当かどうか（大規模な再設計では実行します。以前のパスでは旧テキストが認定されているためです）
• 指摘したものの、変更を見送った項目

UPDATE モードを使わない場合

単発の編集に余計な手順を加えないでください。ユーザーが「X.md にこの箇条書きを 1 つ追加して」と言った場合は、そのまま Edit します。UPDATE モードが役立つのは、次の場合です。

1. 1 つの学びが複数のスキルに影響する場合（スキル間の伝播）
2. 長いセッションから学びをまとめて抽出する場合
3. メモリとスキルのどちらに保存すべきか不明な場合（明示的な振り分けが必要）
4. バージョン管理が重要な場合（コミット前に妥当なセマンティックバージョニングを確認したい）

スキル間の影響がない 1 行の更新なら、そのまま Edit します。

---

モード：TEST

実際のユーザーが使う前に、スキルの実行を確認します。SKILL.md に沿って現実的なユーザーをロールプレイし、各トランスクリプトを固定のルーブリックで評価して、すべての失敗をパッチにします。公開済みスキル（UPDATE の前後の回帰チェック）にも、新規の CREATE／ADAPT ドラフトにも対応します。

シナリオ一式、ルーブリック、評価ルール：references/test-rubric.md。ステップ 2 の前に読んでください。

ステップ 1 — 対象の解決と隔離

• スキル名 → <repo>/skills/<name>/SKILL.md（リポジトリは CREATE のステップ 3 に従います）
• 明示されたパス → そのファイル
• どちらも指定されていない場合 → 確認します

テスト対象のバージョンを固定します。 サブエージェントは実行中にディスクからファイルを読み込みます。作業ツリーがその間に変更される可能性がある場合（ブランチの切り替え、マージ、編集など）は、固定コピーを使うようにします。git worktree add <scratch>/wt-<skill> <commit>（テスト後に削除）を使うか、スキルフォルダーのスナップショットを作成してください。そうしない場合、サブエージェントは着手時点でチェックアウトされている内容をテストし、実際には存在しない問題を報告する可能性があります。

SKILL.md と、エージェントに読み込むよう指示している references/ 内のファイルをすべて、一度だけ読みます。以降、シミュレーション上の実行者が知っているのはそれらのファイルだけです。必要な情報が記載されていない場合は、補完するのではなく指摘事項とします。ホスト環境でサブエージェントを起動できる場合は、各シナリオをそれぞれ別のサブエージェントで実行します。プロンプトにはスキルのパス、シナリオ、ドライランのルールだけを記載し、ほかは何も読まないよう指示します。それができない場合は、最初に隔離について一行で述べてから、両方の役を自分で演じます。

常にドライランで実行します。 シミュレーション上の実行者が行うことは、何もトランスクリプトの外には出しません。つまり、ファイルへの書き込み、ドラフトの作成、課題の作成、コミット、プッシュ、有料 API の呼び出しは行わず、その内容を表示するだけにします。詳細なルールは references/test-rubric.md に記載されています。

ステップ 2 — シナリオの選択

references/test-rubric.md の表から 3～6 件を選びます。標準、簡潔、境界の各シナリオは必須です。スキルの設計上必要な場合は、拒否、手抜き回答者、停止して再開、設定不足も選びます。各シナリオのペルソナは一行で記述します。リストを提示したら、ユーザーが変更を希望しない限り、そのまま進めます。

ステップ 3 — トランスクリプトの実行

各シナリオを 6～12 ターンで実行し、USER:／WIELDER: 形式で記述します。ユーザーは現実的に振る舞わせます（回答が不十分、反論する、近道を試みるなど）。実行者はファイルに忠実に従い、曖昧さを指摘し、理想化した振る舞いはしません。シナリオの問いに答えられた時点で終了します。

ステップ 4 — 評価

該当するルーブリックの各基準を、根拠となる引用行とともに PASS／WEAK／FAIL で評価します。引用がなければ、指摘事項とはみなしません。

ステップ 5 — 報告とパッチ

1. 評価表 — シナリオ × 基準
2. パッチ一覧 — FAIL／WEAK ごとに原因となったセクションを示し、不足／曖昧 または 逸脱しやすい と分類し、具体的な編集案を提示します
3. パッチを UPDATE モードに渡します（ファイルごとに承認し、バージョンを更新）。その後、失敗したシナリオだけを再実行します

すべて合格した場合も、その結果を明確に伝えて終了します。

---

組み合わせて使う

• watch-video — CREATE／from-video の要となります。ビジュアルモードの出力（トランスクリプト＋重要な視覚的場面＋要約）が、スキル作成の入力になります。プロセスの録画には、必ず visual モードを使います。UI の状態も発話と同じくらい重要です。
• second-brain — 必要に応じて、ソース動画／ダンプを raw/call-<slug>.md または raw/note-<slug>.md として保存し、元の素材を、その素材から作成したスキルと一緒に保管できます。
• toolify — -ify 三部作の兄弟スキルです。目標がスキルの作成ではなく、インテグレーション／MCP／API の追加である場合は toolify を使います。
• loopify — -ify 三部作の兄弟スキルです。スキルではなくエージェントループを設定する場合は loopify を使います。
• compound-engineering:create-agent-skill（エージェント） — 形式とベストプラクティスに関する専門知識を得るために呼び出します
• compound-engineering:skill-creator（スキル） — より詳しいベストプラクティスを参照します
• compound-engineering:heal-skill（スキル） — いずれかのモードの後に QA を実行します

品質に関する注意事項

• 出典を明記してください。 チャット、動画、ダンプ、外部 URL、ユーザーが指定した学習内容のいずれであっても、各判断の根拠を SKILL.md の本文に記載してください。改訂しやすくなります。
• v0.1 では過剰に作り込まないでください。 最小限の SKILL.md と 1～2 個の参照ファイルを用意してください。初回の使用後に反復して改善します。生成されるスキルの多くは対象範囲が広すぎます。
• 可能な限り動詞＋名詞の命名にしてください（watch-video、read-book、paste に合わせます）。特徴的な概念には、1 語の名詞名も適しています（decide、pm、paste、skillify）。
• スキーマについては、**必ず Anthropic の公式ガイダンスを参照してください。**形式に関する慣例を独自に作らないでください。
• Claude Code だけでなく、どのホストのエージェントでも使えるように書いてください。
  • ツール名ではなく機能を記載してください（「URL を取得する」。Claude Code の fetch ツールのようなホスト固有のツール名ではありません。「Typefully の下書き作成ツール」。生の MCP ツール ID ではありません）。
  • メモリは、エージェントのメモリ、または ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/ に保存します。Claude Code のメモリパスをハードコードしないでください。
  • ユーザー所有のスキーマ／設定ドキュメントを確認するには、CLAUDE.md または AGENTS.md を読み取ってください。
  • macOS 専用コマンド（クリップボード、open、MLX）には Linux での代替手段を示してください。例：wl-copy／xclip、xdg-open、faster-whisper。
  • スキルで Claude Code の機能が本当に必要な場合は、その旨を本文に記載し、他のホスト向けの手順も示してください（loopify を参照）。
• **ADAPT モードでは、出典の明記が必須です。**適応したすべてのスキルに references/attribution.md を含めてください。
• **ライセンスは厳格な条件です。**明示的な承認がない限り、GPL／プロプライエタリのライセンスを対象に進めないでください。
• **UPDATE モードでは、ファイルごとに承認を得てください。**小さな変更は承認しやすく、まとめると一括承認か全却下かの二択になります。
• **スキルを読むだけでは、テストしたことになりません。**読みやすいルールでも、発動しないことがあります。TEST モードでは文章ではなくトランスクリプトを評価します。ライブ実行で TEST が見逃した問題が発生した場合は、不足していたシナリオや基準を references/test-rubric.md に追加してください。