4. Skills と slash commands — どの繰り返しが一行に圧縮する価値があるか

これは Alice Way シリーズの第4回だ。第2回 ペルソナ設計 と第3回 メモリシステム では、意図がどこに刻まれ、どこに保持されるかを扱った。この投稿では次の層 — 意図の繰り返しの動作をどのように一行に圧縮するか — を扱う。

0. Skill は繰り返しの意図操作を一行に凝縮する

運営者の頭の中には二種類のコンテンツがある。一種類は「今何を決めるべきか」。もう一種類は「その決定をどの手順で展開するか」。前者は毎回変わる。後者はしばしば同じだ。

同じ手順が毎日繰り返され、毎日同じ言葉で協働者に説明しているなら、その手順はすでに意図のパターンとして凝固している。凝固した動作には一行の名前がふさわしい。

Skills と slash commands がその名前だ。繰り返しの意図操作を、一単語の呼び出しに凝縮する。 名前があることで、同じ手順を毎回言語で展開しなくてよくなる。

この投稿は、どの繰り返しがその名前にふさわしいか、そしてその名前をどう設計するかの基準のコレクションだ。

「Skill」の仕組み自体は Anthropic Claude Code の Skill システムから借用している。この投稿はその仕組みをどのように活用するかの記録であり、発明ではない。

1. 格上げ基準 — どの繰り返しが Skill になるか

すべての日常手順が Skill になるべきではない。以下の5つすべてをパスしたものだけが一行の名前を得る。

1.1 少なくとも2回繰り返されたか？

1回は偶然。2回はパターン。同じ手順が少なくとも2回実行されていることが条件だ。

この基準は最もシンプルだが最も頻繁に破られる。「きっとよく使うだろう、先に Skill を作っておこう」という衝動を抑える基準だ。将来の繰り返しは推測。過去の繰り返しは事実。事実に基づいて格上げする。

1.2 開始と終了が明確に定義されているか？

Skill には明確な開始条件と終了条件が必要だ。「プロジェクトに入る」「セッションを締める」「リント後にビルド」— これらは明確な境界を持つ。「コードを書く」はどちらの方向にも明確ではなく、Skill にはならない。

境界が明確でなければ、呼び出しの後で協働者はどこで止まるべきかわからない。あいまいな終了を持つ Skill は、運営者が毎回手動で止めることになる。

1.3 呼び出しの瞬間が判断可能か？

呼び出しには二つの形がある。運営者が意識的に呼ぶ（slash command）か、システムが自動発火する（Hook — 次回の投稿）か。どちらにしても、呼び出しの瞬間が明確に判断できなければならない。

「その場の雰囲気による」は Skill にならない。それは毎回協働者に新たな判断を委ねることになり、その判断自体が新たな意図を要求する。

1.4 入力が同じ（またはシンプルな引数のみ）か？

入力はシンプルでなければならない。引数なし、またはひとつかふたつの短い引数。多くの引数は、それらを埋めること自体が新しい手順になって、節約分が消える。

1.5 結果が一貫して検証できるか？

実行後、Skill は協働者が自己検証できるものでなければならない。「成功」「失敗」「前提条件が欠けている」といったシグナルが明確であること。

結果を検証できない Skill は、運営者が毎回手動でチェックすることになる。恩恵の半分がそこで消える。

2. Skill・slash command・関数 — 役割の分担

三つとも繰り返しを減らすが、異なる役割を果たす。

Skill は、slash command と Hook の両方から呼び出せる共有の手順定義だ。同じ /verify の手順が、運営者が直接入力することもあれば、「完了」報告の直前に Hook によって自動発火することもある。どちらのパスも同じ Skill を指す。

この分担が明確でないと、すべての自動化が関数になって協働者のコンテキスト認識が活かされなくなるか、すべてが slash command になって運営者が毎回手動で呼び出す羽目になる。

3. 実際のローテーションの Skill — 積み重なった効果

毎日使う Skill の一部。

3.1 /start <project> — プロジェクトに入る

指定プロジェクトに入り、README.md・CLAUDE.md・HANDOFF.md・PLAN.md を自動ロードし、現在の git 状態と前回セッションの引き継ぎを一画面で報告する。その後停止し、運営者の次の指示を待つ。

この Skill がなければ、毎回入場に「そのフォルダへ移動して、README を読んで、HANDOFF を読んで、git status を確認して、最後のコミットメッセージを表示して」と展開しなければならない。それが一語に圧縮される。

3.2 /session-end — セッションを締める

作業ログを書き、HANDOFF.md（システムが自動ロードする次セッションへの引き継ぎ）を更新し、コミット、プッシュ — すべてを一動作で。「今日の内容を history.md に要約して、次のセッションが必要なことを HANDOFF に書いて、コミットして、プッシュして」と毎回書かなくていい。

3.3 /verify — 検証ループ

コード変更後、リント・ビルド・テスト・セキュリティチェック・差分レビューを自動実行する。これが通るまで「完了」の報告は出せない。詳細はシリーズの後半で扱う。

3.4 /council — 4視点の並列分析

本当に曖昧な判断に対し、アーキテクト・懐疑論者・プラグマティスト・批評家の視点を並列実行し、結果を統合する。このパターンは Andrej Karpathy の LLM 推論に対する多視点批評アプローチを応用したものだ。

3.5 積み重なった効果

これらはどれも単体では大きな発明ではない。しかし約 30 の一行名前が毎日呼び出されるようになると、運営者が手順を言語で展開する時間はほぼ消える。運営者の意図が集中すべきなのは「今何を決めるべきか」だけになり、「その決定をどう展開するか」は名前が担う。

4. 設計原則 — Skill を構築するときに守ること

Skill 設計で収束したもの。

4.1 べき等性

同じ引数で2回呼んでも同じ結果になるか、少なくとも壊れないこと。べき等でない Skill は「今これを呼んで大丈夫か？」と毎回運営者に考えさせる。それが新しい意図の税だ。

4.2 フェイルファスト

前提条件が満たされていなければ、Skill は一行目で明確なメッセージとともに停止する。「このディレクトリは git リポジトリではありません。git init を実行してからやり直してください。」中途半端に実行された Skill が中間状態に残ることが最も危険だ。

4.3 短い出力

Skill が終わったとき、運営者が見るのは短い出力でなければならない。「OK: 3ファイルをプッシュ」、一行。詳細ログはオプションでオンデマンドのみ。長い出力は、協働者が毎回要約しなければならず、運営者も読み直さなければならない。

4.4 副作用を宣言する

Skill が外部の状態を変更する場合 — ファイルを書く、ネットワーク呼び出しをする、プッシュする — その事実を Skill 定義の先頭に宣言する。「この Skill は origin にプッシュする。」運営者は呼び出す前にそれを把握していなければならない。

4.5 単一責任

Skill は一つのことをする。/start に「依存関係もインストールする」を滑り込ませない。それは別の Skill だ。単一責任が壊れると、名前が動作を表さなくなる。

5. Skill が積み重なるとき — ネットワーク効果

単一 Skill の価値は節約時間だ。しかし 30 の Skill が積み重なると、より大きなことが起きる。Skill が互いを呼び出し始める。

例えば：

• /session-end は内部的に /verify を呼ぶ — 未検証の変更はプッシュされない
• /start はメモリインデックスを自動リフレッシュする
• /council は判断後に /btw（判断キュー処理）の呼び出しを提案する

各 Skill が明確に定義されたインターフェースを通じて他を呼べると、運営者の意図はより大きな単位で動けるようになる。「今日の作業を締める」という一つの決定が、内部では7〜8の Skill 呼び出しに展開される。運営者はその7〜8を意識しなくてよい。

それが積み重なった Skill セットの本当の価値だ。節約時間は副作用。意図がより大きな単位で動けることが本質だ。

6. Skill 化しないもの — 落とし穴

格上げ基準の裏面。以下は損をする Skill だ。

6.1 一度しか実行しない手順

「このマイグレーションは一度だけ実行するから、スクリプトを書こう。」それは Skill にしてはいけない。一度限りの手順はただ実行して消える。Skill にするとメンテナンスが必要になり、6か月後に何だったか思い出そうとすることになる。

6.2 コンテキスト依存が重いもの

「このコードをレビューして」は Skill にならない。呼び出しのたびに異なるコンテキストが必要だからだ。コンテキストを引数として取るなら、毎回それを書き出すことになり、恩恵が消える。

6.3 意図そのものを外注する

「何を決めるべきか教えて」は Skill ではない。それは運営者の意図そのものを外注することであり、運営者が決定の主体でなくなる。

Skill は運営者の意図を補助する。置き換えない。

6.4 頻繁に変わる手順

Skill は一度定義したら数日間は安定しているべきだ。週単位で変わる手順は凝固しない。凝固させると来週壊れる。

7. 進化のパターン — Skill が磨かれる流れ

Skill の自然なライフサイクル。

1. 繰り返しを発見: 同じ手順が2回以上書き出される → 候補
2. 手動で書き出す: 手順を README やメモにリストアップ → 手動で実行可能
3. Skill 化: 手順が安定したら、slash command または Skill 定義に凝縮
4. 実地での磨き: 実際の使用で見つかったエッジケースを修正
5. 外部から呼び出し可能に: 他の Skill が呼び出せるようインターフェースを整理
6. 格上げまたは格下げ: 頻繁に使われる → ペルソナに自動発火トリガーを追加（次回 Hook の投稿） / 使われない → 外部化または削除

このサイクルを経ない Skill は長続きしない。作るのは簡単で維持は難しいので、自然選択が必要だ。

ダウンロード — /verify スキル

第7回で紹介した7段階検証ループを一つの slash-command スキルファイルにまとめたもの。繰り返し手順を一行の呼び出しに凝縮する例 — ビルド・テストコマンドを自分のものに差し替える。

shasum -a 256 verify.md
# expected: 8cabf33a2711a0501ee3f65f630bc49868a710cfa973910b7c33e253091dea12

8. 一つの原則に圧縮する

Skill と slash command 設計の核心は一文に圧縮できる。

「繰り返しの意図操作にだけ一行の名前をつける。それ以外はすべて言語で展開する。」

これが成立するとき、Skill セットは運営者の意図のアクセラレーターになる。壊れるとき — 早すぎる Skill 化、または複雑すぎる Skill — それは運営者が毎回考えなければならないオーバーヘッドになる。

次の投稿では、Skill と対をなすもう半分 — Hooks と自動化、すなわち運営者が呼び出さなくてもシステムが自動発火する手順 — を扱う。