publish-skill

スキル：publish-skill

フェーズ 0：初期化とソースの特定

必須入力

ユーザーから以下を収集します。

1. ソーススキルのパス：個人用スキルが含まれるディレクトリ（例：~/.claude/skills/my-skill/ または ~/.agents/skills/my-skill/）
2. ターゲットパッケージのパス：配布可能なパッケージのディレクトリ（例：~/workspace/<your-package>/）
3. ターゲットライセンス：パッケージのライセンス。必ず確認し、デフォルトとして MIT を提示します。決めつけてはいけません。

アクション

1. ソーススキルのディレクトリから SKILL.md を読み込みます。
2. すべてのファイルを再帰的に一覧表示します（ls -R）。
3. スキルの種類を分類します。
   • スタンドアロン：エージェントへの委任がなく、自己完結しているスキル
   • オーケストレーター：サブエージェントに処理を委任するもの（リファクタリングなしでの配布には不適切）
   • ラッパー：別のツール／API を薄く包むもの
4. インベントリ表をユーザーに提示します。

| File | Lines | Type | Notes |
|------|-------|------|-------|

以降の修正はすべて、作業用コピー（以下の <cleaned_skill_path>）またはターゲットディレクトリで行ってください。 ユーザーの作業用オリジナルであるソーススキルを、その場で変更してはいけません。

ゲート：先に進む前に、ユーザーがソーススキルとターゲットパッケージを確認します。

---

フェーズ 0.5：スキルとしての価値のゲート

PII の削除や汎用化に手間をかける前に、ワークフローをそもそも「スキル」として配布する価値があるかを確認します。次の 3 つのゲートをすべて適用してください。

ゲート	質問	合格条件
独自性	有能なユーザーが、約 5 分のウェブ検索、またはスキルをインストールしていない汎用アシスタントへの質問で、同じ結果を得られますか？	いいえ
具体性	一般的なコードスニペットや標準ライブラリの例ではなく、この分野や繰り返し発生するタスクに固有のワークフロー、判断基準、制約、慣例を記述していますか？	はい
労力	発見に実際のデバッグ、設計の検討、運用上の労力、またはレビュー担当者の視点を先取りした知見（落とし穴、検証手順、分野固有の慣例）が必要でしたか？	はい

ゲート：「いいえ」がある場合（または逆の条件で「はい」の場合）は、公開を中止し、代わりにドキュメントまたはメモリーへの記録を推奨します。価値はあるものの、プライベートエージェントに処理を委任するスキルの場合は、フェーズ 1 でオーケストレーターと判断し、まずスタンドアロンにリファクタリングしてください。3 つすべてに明確に合格した場合のみ、先に進みます。

---

フェーズ 1：独自性の確認

確認項目

1. 外部ソース：このスキルは、別のパッケージや作者の成果を基にしていますか？帰属表示のヘッダー、ライセンス条項、「based on」コメントがないか確認します。
2. サードパーティコンテンツ：references/ 内のファイルに、外部ソース（公開されたガイドライン、教科書、標準化団体の資料）が含まれていますか？
3. 競争上の機密性：非公開にすべき独自のビジネスロジックや競争優位性が、スキルによって明らかになりますか？ユーザーに確認してください。この判断を独断で下してはいけません。

判断基準

確認結果	対応
完全にオリジナル	フェーズ 2 に進む
互換性のあるライセンスで利用している	帰属表示ヘッダーを追加し、続行する
互換性のないサードパーティコンテンツを含む	削除または URL 参照への変換を検討する
プライベートエージェントへの参照があるオーケストレーター	停止 — まずスタンドアロンにリファクタリングする必要があります
競争上の機密情報／独自ロジック	停止 — オープンソースには不適切です

---

フェーズ 2：PII の匿名化監査

許容範囲ゼロ：先に進む前に、スキル内の PII 検出数が正確に 0 件でなければなりません。

事前スキャンの準備

実行前に、PII 検出対象に含めるべきユーザー固有の情報をすべてユーザーに確認します。

• すべての言語表記およびローマ字表記での名前（プレースホルダー形式：<First Last>|<native-script name>）
• 所属機関（プレースホルダー形式：<Institution>|<Hospital>）
• 下書きやファイル名に含まれる可能性のある共同研究者の姓

入力を単一の grep -E の選択パターン（パイプ区切り）にまとめます。

自動スキャン

同梱の監査スクリプトを実行します。第 1 引数はスキルディレクトリ、第 2 引数は事前スキャン設定で指定したユーザー固有の追加パターンです。

bash ${CLAUDE_SKILL_DIR}/scripts/audit_skill.sh --strict <source_skill_path> \
    "<First Last>|<native-script name>|<Institution>|<Hospital>"

このスクリプトは、次の 10 カテゴリとユーザーパターンをスキャンします。

1. ハードコードされたパス（/Users/<name>/、/home/<name>/、~/Documents、~/Desktop、~/Downloads、~/Projects）
2. メールアドレス（アドレス形式の文字列すべて）
3. IP アドレス／内部 URL（*.internal、*.local、*.corp）
4. 所属機関への言及（SNUH / AMC / SMC / KAIST / SNU / ASAN / MGH / UCSF / Mayo Clinic / Johns Hopkins / Samsung Medical / Severance / Asan Medical）
5. 氏名を伴う職位（professor <Surname>、Prof. <Surname>、Dr. <Surname>、PGY[0-9]、<한글이름> 교수님）
6. 言語のハードコード（「in Korean」、「한국어로」、「in Japanese」、「in Chinese」）
7. 具体的な場所（Seoul / Busan / Daegu / Tokyo / Beijing / Shanghai / Boston / Stanford および韓国語表記）
8. 日付付きの引用ブロック内の前例（内部レビューのタイムラインが明らかになる > YYYY-MM-DD ... の行）
9. 著者名形式のファイル名（<Surname>{Year}_* パターン。例：<Surname>2025_<Journal>_Fig01.png。Issue2024_、Sample2025_ などの一般的なトークンは許可リストで除外）
10. バイナリの EXIF メタデータ（DOCX / PPTX / XLSX / PDF / PNG / JPG / TIFF — exiftool でホームパス、メールアドレス、ユーザーパターンをスキャンし、大文字と小文字を区別せず照合します。バイナリファイルがあり、exiftool がインストールされていない場合、RESULT 行は INCOMPLETE となり、--strict は終了コード 3 で終了します）

終了コード：0 は問題なし、1 は検出あり、2 は使用方法の誤り／無効なユーザー正規表現／スキャンを実行できなかった場合、3 はチェックを実行できなかった場合（--strict のみ）です。終了コード 0 の場合のみ、問題なしと判断できます。

既知の制限：韓国語の職位分岐（項目 5）では、敬称 -nim の接尾辞が必要です。職位を表す語の前に韓国語の名前だけがある三人称の言及は、このスクリプトでは検出されません。「advising professor」などの職務記述と区別するには、grep -E では指定できない除外リストが必要になるためです。このような言及は手動で確認してください。

相互検証

スクリプトが検出したカテゴリについては、${CLAUDE_SKILL_DIR}/references/pii-patterns.md を使い、Grep ツールでも手動で確認してください。特に次の点に注意してください。

• 追加パターンの引数に含まれていない名前（例：初期の草稿 1 つにのみ登場した共著者）
• 分野固有の所属機関略称（所属機関が既定のリストに含まれていない場合があります）
• CK-NN、MA-NN、日付付きコホート名など、プロジェクト固有の識別子

出力形式

すべての検出結果を次の修正表にまとめてください。

| # | File:Line | Category | Match | Suggested Fix |
|---|-----------|----------|-------|---------------|

ゲート：ユーザーがすべての検出結果を確認します。作業コピー内でそれぞれを修正し、作業コピーに対して監査を再実行してください。検出件数が 0 件であることを確認してから、次に進んでください。

---

フェーズ 3：一般化

言語

• 置換：「in Korean」／「한국어로」／「Korean language」→「in the user's preferred language」
• 置換：「communicate in [specific language]」→「Communicate with the user in their preferred language」
• 維持：metadata.triggers フィールド（または対象パッケージに相当するフィールド）の多言語トリガーキーワード（これらは検索性を高めます）

職位

• 置換：「radiology researcher」→「medical researcher」（スキルが特定の分野に限定されない場合）
• 置換：「professor」／「fellow」→「researcher」または「user」（文脈に応じて）
• 維持：スキルの対象範囲を定める分野固有の用語（例：「diagnostic accuracy」はそのままで問題ありません）

パス

• 置換：ハードコードされた絶対パス → 同梱の参照ファイルには ${CLAUDE_SKILL_DIR} を使用
• 置換：~/Documents/... → ユーザー指定の出力ディレクトリ
• 維持：スキルディレクトリ構造内の相対パス

環境

• 削除：特定の OS（macOS、Linux）を前提とする記述
• 削除：特定のエディターや IDE を前提とする記述
• 削除：個人のインフラ（エージェント、その他の個人用スキル）への言及
• 維持：スキル本文に記載されているツール要件（前提条件のセクション）。スキーマには tools: フィールドがなく、allowed-tools はツールを説明するのではなく、あらかじめ使用を許可するものなので、要件をそこへ移動しないでください

相互運用性

• 確認：スキルが他のスキルを名前で参照しているか（例：「analyze-stats に振り分ける」）
• 参照先のスキルが対象パッケージに存在する場合：参照を維持する
• 参照先のスキルが対象パッケージに存在しない場合：フォールバック手順を追加して任意のものとして扱う

出力

汎用化に関する変更をすべて統一差分で示し、ユーザーが確認できるようにしてください。

---

フェーズ 4：ライセンス互換性の確認

スキルの references/ および scripts/ ディレクトリ内の各ファイルについて、以下を行います。

1. ファイル内のライセンスヘッダーまたはライセンス宣言を確認する
2. 同じディレクトリ内に LICENSE ファイルがあるか確認する
3. ファイルに既知の標準（報告ガイドライン、臨床スコアなど）の内容が含まれている場合は、出典とライセンスを特定する

${CLAUDE_SKILL_DIR}/references/license-compatibility-matrix.md（MIT を対象とし、一般的なチェックリストおよびパッケージのライセンスも記載）を使って各ファイルを分類します。互換性のあるコンテンツは、必要な帰属表示ヘッダーまたはライセンス通知とともに同梱します。互換性のないコンテンツは、マトリックスの URL 参照パターンに変換します。GPL/LGPL のツールは任意の外部依存関係として扱います。不明なライセンスは互換性がないものとして扱い、削除するか許可を取得します。

出力

ライセンス監査表を提示してください。

| File | Source | License | Compatible? | Action |
|------|--------|---------|------------|--------|

---

フェーズ 5：検証とテスト

構造の検証

1. YAML フロントマター：Agent Skills 仕様で必須のフィールド（name と description）に加え、対象パッケージ独自のバリデーターが要求するフィールドを解析して検証する
2. ファイル参照：すべての ${CLAUDE_SKILL_DIR}/... パスが実在するファイルを指している
3. スクリプトの実行可能性：scripts/ 内のスクリプトに適切なシバンがある
4. 行数：最適な読み込みのため、SKILL.md は 500 行未満にする
5. 説明の品質：説明は動詞で始まり、トリガーとなるキーワードを含める

最終 PII 再確認

整理済みのスキルに対して audit_skill.sh --strict を最後にもう一度実行します。終了コードが 0 である必要があります。

クロスプラットフォームアダプターの確認

一般的なデスクトップエージェント環境でスキルを実行できるか確認します。

プラットフォーム	確認項目
Claude Code	文書に記載されている場合を除き、プライベートな ~/.claude パスへのハードコードされた依存がないこと。
Codex	SKILL.md が自己完結しており、~/.agents/skills/ にインストールできること。
Cursor	正式な SKILL.md を参照する簡潔な .cursor/rules/*.mdc アダプターを用意できること。
Windows	コマンドが Unix のみの前提を避けるか、PowerShell/Python の代替手段を提示していること。
macOS/Linux	シェルの例で、可能な限り移植性のあるパスを使用していること。

パッケージがワークショップまたは教室での利用を想定している場合は、${CLAUDE_SKILL_DIR}/references/classroom-distribution.md を読み、その指示（直接ダウンロードできる ZIP、リリースアセット、教室向けチェックリスト）に従います。

README エントリーの草案

対象パッケージの README 形式に合ったテーブル行を作成します。

| **{skill-name}** | {One-sentence description of what the skill does.} |

ユーザーテスト

ユーザーに次の手順を案内します。

1. 整理済みのスキルをテスト用の場所にコピーする：cp -r <cleaned_skill> ~/.claude/skills/<skill-name>
2. Claude Code を再起動する
3. /<skill-name> または関連するトリガーフレーズを入力して、スキルが起動するかテストする
4. サンプル入力を使って、すべてのフェーズが最初から最後まで動作することを確認する

ゲート：ユーザーがテストの完了を確認すること。

---

フェーズ 6：パッケージ化とコミット

対象パッケージへのコピー

cp -r <cleaned_skill_path> <target_package>/skills/<skill-name>/

README の更新

フェーズ 5 で作成した README エントリーを適用します。

• 適切なテーブル（利用可能／近日公開）に行を追加する
• スキルによって新しいステージが追加される場合は、パイプライン図を更新する
• 説明文にスキル数が記載されている場合は、スキル数を更新する

コミットコマンドを生成する

コマンドを正確に提示しますが、push は自動実行しないでください：

cd <target_package>
git add skills/<skill-name>/
git add README.md
git diff --cached   # User reviews
git commit -m "Add <skill-name>: <one-line description>"

ゲート：ユーザーが git diff --cached を確認し、コミットを明示的に承認します。push は常に手動で行います。

公開後

ユーザーに次のことを促してください：

• 該当する場合は、マーケットプレイスの掲載情報にスキルを追加する
• クリーンなクローンからのインストールをテストする：git clone <repo> && cp -r <repo>/skills/<skill-name> ~/.claude/skills/
• 教室で配布する場合は、references/classroom-distribution.md のリリース手順を完了する。