Matt の skill 源码を読んだ:良い skill には四つの鉄則がある(ついでに caveman を削った跡も見つけた)

30 秒で要点

良い skill のゴールは一つだけ――予測可能性(predictability)。同じ状況で、AI が毎回同じ流れを踏む。四つの鉄則はすべてこれに奉仕し、それぞれに反例が一つ付く:

どう起動するか:モデルが自分で判断して使う(そのために常時コンテキストを占める)か、あなたが名指しで呼んだときだけ起動するか。選択を誤る=コンテキストの無駄占有。

どれだけ載せるか:SKILL.md にはどの経路でも使うものだけ残し、残りは外部リンクへ沈める。反例:sprawl(肥大)、sediment(堆積)。

どんな語を使うか:AI の頭にすでにある既製の概念を leading word(主導語)として借り、一語で一群の挙動を引き出す。反例:no-op(無駄語)、duplication(重複)。

どう締めるか:各ステップに検証可能な completion criterion(完了基準)を置く。反例:やり切らずに先へ抜ける。

四つはすべて Matt Pocock の writing-great-skills 由来。四つの反例はすべて彼自身の改版記録から掘り出した実例だ。

Matt の skill 源码を一通り読んだ

同じ / 一発でも、毎回仕事を終える skill もあれば、当たり外れのある skill もある。差は運ではなく書き方だ。

skill の源码を読む暇は誰にもない――代わりに読んだ。対象は Matt Pocock、AI 協働 skill を一式作った人物だ。彼には妙なものがある:良い skill の書き方そのものを説く skill(writing-great-skills)だ。これに加えて、彼の数十個の skill の源码とコミット履歴を一緒にさらい、四つの鉄則を抜き出した。

たった四つだが、各条に反例を一つずつ付けた。反例は一つも捏造していない。すべて Matt 自身のコミット記録から掘り出した、彼が自分の手で犯し、自分の手で直したものだ。彼ですら戻って直したのだから、その地雷は本物だ。

この四つを覚えれば、自分で skill を書くとき地雷を踏みにくくなる。書かなくても、彼の「ランダムな AI から確定性を絞り出す」考え方を盗める。

良い skill の基準は一つ:予測可能であること

モデルは確率的だ――同じ一文を二度問えば、答えは揃わない。skill の存在意義は、この確率機械から確定性を絞り出すこと、つまり毎回同じ**流れ(流程)**を踏ませることにある。

「A skill exists to wrangle determinism out of a stochastic system.」 ―― Matt、writing-great-skills

ここで言うのは流れであって、出力ではない。ブレインストーミングなら毎回違うアイデアが弾けてよい。ただし展開のやり方は安定していなければならない。

skill の良し悪しを判じる基準はこれ一つ、予測可能性(predictability)。以下の四つはすべてこれに奉仕する。

第一条 · どう起動するか:あなたが名指しで呼ぶか、モデルが自分で判断するか

skill を書くとき最初に決める板はこれだ。この skill は、モデルが自分でいつ使うか判断すべきか、それともあなたが名指しで呼んだときだけ起動すべきか? 技術的にはスイッチ一つ――description を書くか書かないか:

モデル自動起動(model-invoked、description あり):AI が自分でそれを読め、いつ使うか自分で決める。代償は、その description が毎ターン会話のコンテキストに居座ること。token を食い、注意を食う――これがコンテキスト負荷だ。
ユーザー手動起動(user-invoked、disable-model-invocation を設定):description が外され、モデルからは見えなくなり、あなたが名前を打ったときだけ起動する。AI のコンテキストは一切使わない。代償はあなたに移る――それが存在することを自分で覚えておかねばならない。これが認知負荷だ。

原則:モデル(または別の skill)が自分で手を伸ばさねばならないときだけ自動起動にする。それ以外は手動にして、コンテキスト負荷ゼロを丸ごと得る。

反例:本当は自分で名指しするだけの skill なのに、description を残し、毎ターンあなたのコンテキストを無駄に占めさせる。

実例:この取捨は Matt 自身が何度も量り直している。grill-with-docs の disable-model-invocation スイッチを、彼はまず削った――モデルの自動起動に任せた。そして最新版でまた足し戻し、純手動に戻した。同じスイッチを、削っては足す。「自動か手動か」は本当に天秤にかける決定であって、片手間に設定するものではない、という証拠だ。

自分で使う:既定は手動、まずコンテキストを節約する。モデルに「今これを使うべきだ」と自分で判断させる必要が確かにあるときだけ、description を与える。一文の自己点検――「この skill、誰が手を伸ばす必要がある?」答えが「自分だけ」なら手動。

手動 skill が溜まると自分で覚え切れなくなる。それは認知負荷の破裂だ。解は、もう一つルーティング skill を書くこと:手動 skill 一つで、他の skill を一覧にし、いつどれを使うか教える。Matt の ask-matt がまさにこれをやる。

第二条 · どれだけ載せるか:SKILL.md には「どの経路でも使うもの」だけ

情報の階段:どの利用経路でも使うものは SKILL.md 本文に置く。一部の状況でしか使わないものは、独立した外部リンクのファイルへ沈め、本文には「必要ならそれを見ろ」という一行のポインタだけ残す。狙いはトップを常にすっきり保つことだ――物を積み過ぎると、AI が本当にやるべき動作が埋もれる。

反例は二種、どちらも名前がある:

sprawl(肥大):何でも一つのファイルに詰め込み、書くほど長くなる。たとえ各行が正しく重複もなくても、ただ「長い」こと自体が病だ――AI はやるべき仕事に手を伸ばす前に、大量の字をかき分けねばならない。
sediment(堆積):古い内容を足すだけで削らず、層が重なっていく。後から来る者は考古学のように下へ掘らないと、まだ有効な部分にたどり着けない。

実例:grill-with-docs は初期、太った一枚岩だった――問い詰めのロジック、ドキュメントの書式、ADR テンプレート、全部一つのファイルに詰めていた。Matt はこれを一つから三つへ割った:問い詰める半分を grilling に、ドキュメントを書く半分を domain-modeling に独立させ、ADR や用語集の書式ファイルも domain-modeling へ沈めた。grill-with-docs には両者をつなぐ一行の薄い殻だけが残った。これが情報の階段で肥大した skill を減量する、ということだ。

自分で使う:書き終えたら戻って削る。一行ごとに「これはどの経路でも要るか?」と問う。違うなら、外部リンクへ沈めるか、そのまま切る。粗いがよく効く直感――SKILL.md は短いほど、幹だけ残っているほど、たいてい信頼できる。

第三条 · どんな語を使うか:AI の頭にすでにある概念を借りる

これが一番直感に反する。私自身、しばらく考えてようやく腑に落ちた。

leading word(主導語):AI が訓練時にとっくに学んでいて、一身の連想を背負った既製の概念だ。専門用語に限らない――ゲーム、軍事、医学、日常の成語も全部含む。AI が一見して分かりさえすればいい。skill に書けば、あなたが説明せずとも、それが一連の挙動をまるごと呼び出す。

例(全部借り物で、Matt の発明は一つもない):

fog of war(戦場の霧、ゲーム/軍事由来)→ AI は即座に「前方は見えない、手元の局所情報で動け」と理解する。
tracer bullets(曳光弾、『達人プログラマー』由来)→「まず一番薄い end-to-end を一本通し、方向を見定めてから肉付けする」。
triage(トリアージ、病院の救急由来)、caveman(原始人=言葉を削る)、grilling(問い詰め)――既製の概念をそのまま借りて使う。

どこで探すか:まず欲しい挙動を言葉にし、逆向きに「どの既製の語、典故が、それ自体すでにこの意味なのか?」と問う。成語、名著、方法論、ゲームや軍事、医学やスポーツから拾え。AI が読んだものが、あなたの語彙庫だ。

どう検証するか――no-op テスト:その語だけを書き、説明を足さずに、AI は意図どおり動いたか? 動いた=本物の leading word で、AI の事前知識をタダで借りている。長々説明してようやく通じる=その語は働いておらず、反例に落ちている:

no-op(無駄語):書いたが、AI がもともと従う言葉。たとえば「be thorough(丁寧に)」――AI は既定でいくらか丁寧で、この行はほぼ書いていないのと同じだ。直し方は説明を足すことではなく、もっと強い語に替えること:「be thorough」→「relentless(執拗に)」。
duplication(重複):同じ意味を何度も書く。保守の手間が増える(一箇所直すと全部直す羽目になる)うえ、その意味の重みを AI の目から見て過大にする。

実例:この二つに Matt は本当に刃を入れている。彼は review skill を引き締め、コミット説明に黒々と「single-sourced rules, no-op cuts」と書いた――重複ルールを統合し、無駄行を切った。さらに彼は writing-great-skills という記事そのものにも戻って手を入れ、わざわざ「no-op を文単位で狩る」ことまでやった。

自分で使う:欲しい挙動を一文で描写しようとせず、それを引っかける既製の語を一つ探す。そして形容詞・副詞を一つずつ取り出して no-op テストにかける――それを削ったら AI の挙動は変わるか? 変わらないなら水だ、削れ。

第四条 · どう締めるか:各ステップに検証可能な完了基準を

skill はしばしば一連のステップだ。各ステップが本当に終わったかどうかは、**completion criterion(完了基準)**で判定する。

良い完了基準には二つのこだわりがある。一つは検証可能(verifiable)であること――AI が「終わった」か「終わっていない」かを、感覚で決めるのではなく客観的に判定できる。もう一つは尽くすべきは尽くすこと――たとえば「変更したモデルは一つ残らず説明する」のように。曖昧な「変更一覧を出す」ではなく。

反例 · premature completion(早期完了):完了基準をぼかすと(「合意に達する」「理解が行き届く」)、AI は明確な境界線に手が届かず、注意が「仕事をやり切る」から「さっさと終わらせる」へ滑り、やり切らないまま次のステップへ抜ける。

連動するからくりもある:AI が後ろに並ぶステップを見えていると、「早く終わらせて先へ進みたい」という引っ張りが強まる。対処の一つは、後続ステップを別の skill に隠し、今のこのステップが先を急がないようにすることだ。

実例:grilling(grill-with-docs から割り出した問い詰めの半分)の看板動作は、一題ずつ問い、あなたが一題答えてから次を問うことだ――その leading word はまさに「relentless(執拗に)」。当初、問い詰めとドキュメント書きを二つの skill に割ったのも同じ理屈だ:AI があなたを問い詰める最中に「問い終わったら早くドキュメントを書きに行こう」と気を取られないようにする。割れば、問い詰めのこのステップには問い詰めだけが残る。

自分で使う:各ステップの締め条件を、検証可能、できれば網羅可能に書く(「X は一つ残らず……」であって「だいたい済んだ」ではない)。AI がどこかのステップでフライングを繰り返すなら、後続のステップを別の skill へ移せ。

この四つで、奇妙な一件を見る:なぜ caveman を削ったのか

この四つを持って、本物の現場を見に行く。

第一篇で扱った caveman(AI を黙らせ、要点だけ言わせる)は、いま Matt の元リポジトリから見つからない――削られた。削除記録は素朴だ:

5 月末、彼はcaveman SKILL.md を丸ごと削った。コミット説明はただ一言「streamline(生産系 skill を整理)」。
半月後、README やプラグイン一覧に残った参照を掃除した。
後を継ぐ新 skill はない。 そのまま削除。

なぜか? 四つで測れば分かる:caveman は手動 skill で、占めるのはあなたの認知負荷だ――それが在ることを覚えておかねばならない。だが caveman がやる程度のこと(言葉を削る、客套を抜く)は、一言の指示、あるいは全体の出力スタイル一つで頼める。単独で「覚えておくべき枠」を一つ占めるほどの価値はない。削除は、skill 集合の層で枝を刈り、割に合わない負荷を切ったということだ。

一つ断っておく:Matt のコミット説明には「streamline」としか書かれておらず、展開はない。これは私がこの枠組みで行った解釈だ。だが枠組みは筋の通った説明を一つ出せる――それこそがこの枠組みの使いどころだ。

四つは skill を書くチェックリストにとどまらない。現実世界で、ある skill がなぜ生き、なぜ死ぬのかも説明できる。

チートシート

鉄則	やること	反例	一文の自己点検
どう起動するか	モデルに自動で手を伸ばされる必要があるときだけ description を付け、それ以外は手動	コンテキスト負荷の無駄占有	「この skill、誰が手を伸ばす必要がある?」
どれだけ載せるか	SKILL.md にはどの経路でも要るものだけ残し、残りは外部リンクへ沈める	sprawl / sediment	「この行はどの経路でも要るか?」
どんな語を使うか	AI の既製の概念を leading word として借り、一語で一群の挙動を錨打つ	no-op / duplication	「この行を削ったら、AI の挙動は変わるか?」
どう締めるか	各ステップに検証可能・網羅可能な完了基準を置く	premature completion(早期完了)	「このステップが終わったか、AI は客観的に判定できるか?」

唯一の基準は予測可能性(predictability)――同じ状況で、AI が毎回同じ流れを踏む。四つはすべてこれに奉仕する。

最後に

四つは skill を書くならそのまま使えばいい。一生 skill を書く気がなくても、その背後にある「ランダムな AI からどう確定性を絞り出すか」の考え方は、普段 AI を扱うのを安定させてくれる。結局のところ、これが高手から盗む本当の得だ:あなたが手にするのは数条のルールではなく、彼の頭の中の判断そのものだ。

出典:本記事は Matt Pocock の writing-great-skills(およびその GLOSSARY.md)を分解したもの。リポジトリは mattpocock/skills、MIT ライセンス、バージョン 6eeb81b。本文中の「実例」はすべて当該リポジトリのコミット履歴で確認できる(コミットリンクを付した)。

同シリーズ:第一篇 · caveman · 第二篇 · grill-with-docs