Skill を作っていくと、自然と数が増えてきます。そのとき全部を同じ引き出しに入れておくと、どれをどう直せばいいのかだんだん分かりにくくなります。私の場合は、Skill を性質で 2 種類に分けています。
ひとつは「作業 Skill」。文章のチェック、データの整形、命名規則の確認といった、単純で繰り返す作業を型にしたものです。いろいろなプロジェクトで使い回したいので、これはグローバル(全プロジェクト共通)のスキルにすることが多いです。
もうひとつは「オーケストレーション Skill」。あるプロジェクトの一連の流れ ── たとえば企画から下書き、チェック、公開準備まで ── をまとめて段取りする、司令塔のような役割です。プロジェクト固有の事情を含むので、こちらはそのプロジェクトの中に置くローカルなスキルにします。流れの途中で必要になったら、オーケストレーション Skill から作業 Skill を呼び出す、という関係です。
分けておくと、何が嬉しいのか。
ひとつは、改善ループを別々に回せることです。作業 Skill は「様々なプロジェクトで使われるので完成度が高まる速度が速い」。オーケストレーション Skill は「手順を柔軟に変更できることで作業全体の完成度を高めることに集中しやすい」。直したい方向がそもそも違います。ひとつに混ぜていると、片方を良くしたつもりが別の用途を壊してしまう、ということが起きがちです。役割で分けておけば、それぞれの改善がお互いに波及しません。
もうひとつは、コンテキストの節約です。Skill の本文は、その Skill が呼ばれたときに読み込まれます。だから、ひとつの巨大な Skill にあらゆる条件分岐を詰め込むと、どの分岐に進むときも結局は全文を抱えることになりがちです。役割ごとに切り出しておけば、その場面で必要な分だけを読み込めばよく、AI が抱える文脈が軽くなります。軽いほど、AI は目の前の作業に集中できます。
道具は、増えるほど「どこに何があるか」が効いてきます。作業 Skill とオーケストレーション Skill ── この 2 つの引き出しを分けておくだけで、数が増えても散らからず、改善も回しやすくなります。