「言わなくても分かる」をやめて、skill と hook に書くことにした

⚠️この記事はClaude Codeに清書してもらいました。

TL;DR

• 同じプロンプトを何回も Claude に入力するのは、めんどくさい。それは「言わなくても分かるでしょ」を Claude に期待しているからしんどい、というのが最近の気づき。
• やわらかいルール（好み・文脈依存）は、私は skill に置いている。書いて、使って、気に食わなければ即座に直す。完成形を目指さずラフに書き殴る、くらいの気持ちでちょうどいい。
• かたいルール（明確に違反/合格を判定できる）は、私は hooks に任せている。注意力で守ろうとしないほうが、結果的に長持ちする。
• 「プロンプトに暗黙知を毎回全部入力しない」というのが、自分の中で個人的な指針になりつつある。

---

はじめに：「言わなくても分かる」を期待するのは、もう疲れた

Claude Code に同じプロンプトを何度入力しただろう。

「テスト先に書いてから実装して」
「コミットメッセージはこのフォーマットで」
「ここのディレクトリには書き込まないで」
「マイグレーションは Expand & Contract で段階的にやって」

毎回プロンプトに同じことを書き直すのは、正直めんどくさい。そして、めんどくさいのに同じ指示を出し続けないと直らない、という状況がじわっとしんどくなってくる。

ここで気づいたのは、自分はずっと「言わなくても分かるでしょ」を Claude に期待していた、ということだ。でも Claude は分からない。当たり前で、それは自分の中で暗黙知になっているルールが、Claude と共有されていないからだ。

ルールは存在しても、共有されていなければ意味がない、と思う。「言ったのに直らない」というフラストレーションが積もると、付き合うのが少しずつしんどくなっていく気もする。

ここで反射的にやりがちなのは「ルールをもっと厳密に書く」「プロンプトを長くする」「CLAUDE.md に追記する」だ。間違ってはいないと思う。でも、それだけでは足りない場面が多い、というのが私の実感だ。

問題はルールの書き方ではなく、ルールの「置き場所」を間違えていることが多いんじゃないか、と最近よく考える。やわらかいルールを CLAUDE.md の底に沈めて期待しているか、かたいルールを毎回プロンプトに書き続けて疲弊しているか、そのどちらかになりがちな気がする。

ルールには「硬さの濃淡」があると思う

すべてのルールを一様に扱うと苦しくなるので、私はルールを 「かたさ」 で整理することにしている。

• やわらかいルール：文脈依存で、判定が人によって割れる。例：「日本語で答えてほしい」「報告は3行以内が嬉しい」「マイグレーションは Expand & Contract で段階的に」など。
• かたいルール：機械的に違反/合格が判定できる。例：「main ブランチで直接 Edit しない」「重いファイルをコミットしない」「特定ディレクトリに書き込まない」など。

かたさ	置き場所
やわらかい	skill（ラフに書き殴る）
かたい	hooks（仕組みで止める）

この2つで、ルールの置き場所はだいたい決まる、というのが私の整理だ。

① やわらかい：skill はラフに書き殴っていいと思ってる

skill は、私にとって「個人の認知負荷の地図」のようなものだ。同じ指示を何度も出したら、それはたぶん skill にすべきサインだと思っている。

たとえば、データベースのマイグレーションをするとき、「Expand & Contract で段階的にやって」と Claude に指示していた。「ALTER で一発で書き換えない」「カラム追加 → 二重書き込み → 読み出し切替 → 旧カラム削除の順で進める」みたいな手順は、自分の中では当然だけど、Claude にとっては毎回ゼロから言われる指示でしかない。これは、自分の暗黙知が相手と共有されていないだけだ。

ここで「プロンプトに毎回全部書く」を選ぶと、いつまでも同じことを書き続けることになる。なので私は、こういうものは プロンプトではなく skill に置く ようにしたい。プロンプトに暗黙知を毎回全部入力しない、というのが個人的な指針になりつつある。

ここで大事にしているのは 完璧を目指さない こと。私の skill の作り方は、

• 思いついた瞬間に skill-creator に投げて雑に作らせる（ゼロから書こうとしない。雛形を出させて、それを直す方が圧倒的に速い）
• 一度使ってみる
• 気に食わなければ直す。あるいは捨てる
• 育つものは育つ、死ぬものは死ぬ、くらいに思っておく

このサイクルが命だと感じる。要は 「完成形を設計してから書くのではなく、書きながら形を見つけていく」 やり方で、スケッチに近い感覚かもしれない。skill との相性はかなりいい、というのが今のところの実感だ。

なぜかというと、skill が対象にしているのは「自分の認知負荷の輪郭」であって、それは事前に綺麗に言語化できるものではない気がするからだ。書いて、使って、違和感を感じて、初めて「あ、自分はここがイヤだったのか」と気づく、ということが多い。

あくまで対象は 自分のための skill で、「自分が楽になればいい」と割り切っている。だから汚くていいし、再利用性がなくていいし、明日捨ててもいい、と思って書いている。

一応、他の人が参考にできるように↓ココに入れて管理はしています。
https://github.com/FScoward/senju

② かたい：自分のクセは hooks に任せると楽

私にも「自分が繰り返してしまう、くだらないミス」がある。

• ブランチを切らずに main で作業を始めてしまう
• ふとした瞬間に console.log を残してコミットしてしまう
• 重いファイルを誤ってコミットしてしまう

これらは「気をつける」だけでは解決しない気がしている。注意力には限りがあるし、AI に作業を任せた瞬間にもっと忘れそうだ。

こういう「かたい」領域は、私は hooks に任せる のが一番楽だと感じている。

#!/bin/bash
# 例：mainブランチでのEditを止める PreToolUse hook
# .claude/hooks/pre-tool-use.sh

# hooks の入力は stdin から JSON で渡ってくる
INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name')

if [ "$(git branch --show-current)" = "main" ] && [ "$TOOL_NAME" = "Edit" ]; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "mainブランチでの直接編集はブロック。worktreeを切ってください"
    }
  }'
fi
exit 0

ただ、hooks は「うるさい姑」になりやすいとも思う。何にでも口を挟むと、本当に止めてほしいときの警告がノイズに埋もれてしまう。なので、何を hooks にするかの線引きは、できるだけ慎重にしたい。明確な運用ルールを決めているわけではないけれど、「自分にとって本当に痛かったミス」だけに絞っておきたい、というくらいの温度感でいる。

おわりに：考えなくていいことは、考えなくていい状態にしたい

skill も hooks も、目的は同じだと思っている。「考えなくていいことを考えなくていい状態にする」 ことで、本当に考えるべきことに集中できるようにする、というやつだ。

skill をラフに書き殴っているのは、毎回プロンプトに暗黙知を入力する手間から解放されるため。
hooks にくだらないミスを任せているのは、自分の注意力を本当に必要な場所に向けるため。

「言わなくても分かるでしょ」を期待してプロンプトに書き続けるのは、たぶんもう疲れる。書く場所さえ変えれば、もう言わなくていい、というだけの話なんじゃないかと思っている。