$ man context-wiki/skills

スキルは、あることの「やり方」を記録した Markdown ファイルだ。平易な言葉で一度書く。Claude が毎回それに従う。/deploy スキルは、3 つのウェブサイトでのステージング、コミット、プッシュ、デプロイ検証の方法を知っている。/finalcopy スキルは、ボイスガイド、プラットフォームルール、アンチスロップフィルターを知っている。/tracker スキルは、Git コミットのスキャン、コンテンツ数のカウント、アウトプットスコアの計算、ダッシュボード画像の生成方法を知っている。スキルはポータブルなナレッジだ。部族的な暗黙知を実行可能な自動化に変える。

パターン

Joe Rhew がこのアナロジーをぴたりと決めた。スキルは鋳鉄フライパンのようなものだ。特別なことはしていない。ただ料理しているだけだ。しかしフライパンを使うたびに、油がなじんでいく。20 回磨き上げたスキルは、初日に書いたものとは比べ物にならないほど良い。そして改善のために時間を取ったことはない。使って、エッジケースに気づいて、そのエッジケースを直す。するとスキルが良くなる。 私の /deploy スキルは 10 行から始まった：ステージ、コミット、プッシュ。今ではコミットメッセージの生成、3 サイトにまたがるビルド検証、エラーリカバリー、デプロイ後の確認を処理する。改善のために時間を取ったことは一度もない。50 回デプロイして、壊れたところを直しただけだ。

プロのコツ

標準業務手順書（SOP）は、人間がステップバイステップで従うために書かれたものだ。陳腐化する。人はステップを飛ばす。誰も更新しない。スキルが SOP を完全に置き換える。人間が読んで（エラー付きで）従うドキュメントを書く代わりに、エージェントが（エラーなしで）実行するスキルを書く。スキルは SOP、実行者、品質チェックのすべてを一つのファイルに凝縮したものだ。 私のリポジトリには 40 以上のスキルがある。/deploy、/tracker、/finalcopy、/substackpost、/partneronboard、/webreveal、/heyreach-export、/linkedin-recon、/daily-tracker。2 回以上繰り返すワークフローはすべてスキルになる。5 回以上使うスキルはすべて磨き上げられる。その結果が、GTM オペレーション全体を動かす自動化ライブラリだ。

パターン

SKILL.md ファイルには 5 つの要素が必要だ： 1. トリガーの説明。このスキルを起動するものは何か？ スラッシュコマンド、キーワード、フレーズ。 2. コンテキスト要件。実行前にエージェントが必要とするファイル、データ、状態は何か？ 明示的にリストする。 3. ステップバイステップの指示。平易な言葉で書く。番号付きのステップ。事前の会話コンテキストがない新しいエージェントでも従えるほど明確にする。 4. アウトプットの期待値。成功とはどんな状態か？ デプロイされたサイト？ 生成されたファイル？ 投稿されたドラフト？ 5. エッジケースの処理。何がうまくいかない可能性があるか？ ポートの競合、ビルドの失敗、データの欠落。エージェントはどうリカバリーすべきか？ スキルファイルにこれらのいずれかが欠けていれば、エージェントは即興で動く。即興こそが物事が壊れる場所だ。

アンチパターン

「ウェブサイトをデプロイする」と書いてあるスキルファイルはスキルではない。それは願望だ。本当のスキルはこう書く：未ステージの変更を確認し、すべての変更済みファイルをステージし、diff からコミットメッセージを生成し、そのメッセージでコミットし、origin main にプッシュし、Vercel のビルド完了を待ち、3 つのデプロイ URL をすべてチェックし、200 ステータスコードを確認し、結果を報告する。曖昧なスキルは一貫性のない結果を生む。具体的なスキルは信頼性の高い結果を生む。スキルは、コードベースを一度も見たことがないコントラクターをオンボーディングするつもりで書く。なぜなら、新しいエージェントセッションのそれぞれがまさにそれだからだ。