skillとやらを作成してみた

/write と打つと、AIが記事を書き始めます。

いま読んでいるこの記事も、そうやって書かれています。テーマと箇条書きのメモを渡したら、質問が返ってきて、構成案が出てきて、本文になりました。

その仕組みを「スキル」といいます。初めて自分で作ってみたので、その話を書きます。

指示を書き溜める場所があった

Claude Code には CLAUDE.md というファイルがあります。プロジェクトの一番上に置いておくと、AIが毎回それを読んでから作業を始めてくれます。

私のブログの CLAUDE.md から、冒頭を抜き出すとこうです。

## Development

When starting the dev server, use background mode:

astro dev --background

このあとに、サーバーの停止や状態確認のしかたと、Astroの公式ドキュメントへのリンクが続きます。それで全部です。短い。

このファイルは便利で、「毎回これを守ってほしい」ということを書いておけば、いちいち言わなくてよくなります。だから最初は、思いついたルールをここに足していけばいいと思っていました。

記事を書くときの決まりごとも、ここに書こうとしました。文体はこう、図解はこう、公開前にここを確認して……と。

ただ、CLAUDE.md は毎回読まれている

書き足そうとして、手が止まりました。

CLAUDE.md は毎回読まれます。記事を書くときも、CSSを直すときも、ビルドが通らなくて調べているときも、全部です。

記事の書き方のルールは、たぶん全体の何割かを占めます。でも私がAIに頼むことの大半は、記事を書くこと以外です。使わない場面のほうが多いルールを、毎回読ませることになる。

そこで出てきたのがスキルでした。

スキルは、マークダウンを1枚置くだけ

やることは、拍子抜けするほど簡単でした。

公式が決めた場所に、マークダウンのファイルを1枚置く。それだけです。

.claude/
└── skills/
    └── write/
        └── SKILL.md

write というフォルダを作って、その中に SKILL.md を置く。するとチャットで /write と打てるようになります。

これ、前にも見たやつだ

ここで、バラバラに覚えていたものが少しつながりました。

• CLAUDE.md — プロジェクトの一番上に、この名前で置く
• .github/workflows/deploy.yml — この場所に置くと、GitHub Actionsが読みにくる
• Dockerfile — この名前だから、Dockerが読む

どれも置き場所と名前が、そのまま役割になっています。設定画面のどこかで「このファイルを使ってください」と登録するわけではありません。決まった場所に決まった名前で置いた、という事実だけで役割が決まる。

ファイル名が、ほとんど予約語みたいなものになっているんだなと思いました。

ひとつ覚えるたびに別物として覚え直していたので、同じ仕組みだったと分かったのが素直に嬉しかったです。

中身は、ファイルの先頭に名前と説明を書いて、あとは普通の日本語です。

---
name: write
description: メモをもとに、ブログ記事をMDXで作成する
disable-model-invocation: true
---

# 進め方
1. 入力の内容を確認する
   - テーマだけの場合は、記事に必要なことを1問ずつ質問する
   - メモがある場合は、足りない情報だけを質問する
2. タイトル案・構成案を提示し、OKをもらってから執筆する

プログラムではありません。手順書です。

3行目の disable-model-invocation: true は、「AIが勝手に判断して呼ばない」という指定です。これを入れておくと、/write と打ったときだけ動きます。

入れないと、AIが「いまこの手順が要りそうだ」と自分で判断して呼ぶことがあります。私は呼ぶタイミングを自分で決めたかったので、入れました。

呼びたいときだけ呼べる、という意味では関数に近いのかもしれません。ただ中身は、新しく入った人に仕事を引き継ぐときのメモと、ほとんど同じものでした。

やりたいことを話したら、形になった

では、そのマークダウンをどう書いたか。

書いていません。 話しただけです。

「メモを渡したらブログ記事にしてくれるスキルを作りたい」と伝えました。そこからいくつか質問されて、答えていったら、ファイルができあがっていました。

聞かれたのはこういうことです。

• メモがないときはどうするか（質問してほしい）
• 書く前に確認を取るか（取ってほしい）
• 文体はどうするか（私の言い回しを残してほしい）

自分では意識していなかった手順が、質問されることで言葉になりました。毎回やっていたことを、聞かれて初めて説明したという感覚に近いです。

一発では決まらなかった

ただ、そこで完成とはいきませんでした。

実際に /write を使ってみると、うまくいかないところが出てきます。質問が多すぎたり、図解がほしい場所に入らなかったり。そのたびに「ここをこうして」と伝えて、SKILL.md を直しました。

作って終わりではなく、使いながら育てていく感じです。

いまの SKILL.md は、最初にできたものとはだいぶ違います。直した回数のぶんだけ、自分のやり方が正確に書かれている状態になりました。

自分で作らなくても、最初から使えるものがある

もうひとつ知ったのは、全部を自分で作らなくてもいいということでした。

最初から用意されているものがいくつかあります。私が使ったのは init です。

/init と打つと、プロジェクトの中身を見て回って、CLAUDE.md を書いてくれます。この記事の最初に貼った短いファイルは、私が書いたものではなく init が作ったものです。

ここが自分の中ではつながりました。CLAUDE.md を作る作業自体が、呼んだときだけ動く形で用意されている。常に読ませるファイルを、呼んだときだけ動くもので作る。 やりたいことをそのまま形にすると、こうなるのかと思いました。

コードは1行も書いていない

振り返ると、この一連の作業でコードは1行も書いていません。

書いたのはマークダウンだけです。それも大半は、質問に答えていたら勝手に埋まっていました。普段の仕事はQAで、スマホを手で叩くテストが本業です。そういう立場でも、仕組みのほうは作れました。

そしてもうひとつ。頭の中にあった「記事を書くときの、いつもの手順」が、いまはファイルになっています。

これまでは毎回思い出しながらやっていました。今は /write と打てば、その手順が呼び出されます。自分のやり方を、自分の外に置いておける。スキルの一番大きい効果は、これかもしれません。

次は何をスキルにしようか、を考えているところです。