TL;DR
- ClaudeCodeでよく利用する自作スキルを3つ紹介
- それぞれ「コミット」「調査」「最新情報取得」
- 「人間にしか出来ない判断だけを残す」こと以外は改善ループ含めてAIに任せる
対象読者
- ClaudeCodeのスキル機能を使い始めて何を作るか迷っている方
- カスタムコマンドを作ってはみたものの結局使わなくなって埋もれている方
- AIに作業を任せたいがどこまで任せていいか線引きを探している方
はじめに
今回説明する3つのスキルイメージです。
ClaudeCodeにはSkillという、/commandで呼び出せる手順書のような仕組みがあります。しばらく運用して気づいたのは「結局ほとんど使われないスキルが大半」ということです。
その中でも特に使用頻度が高い3つを今回は紹介します。
3つのスキルの位置づけ
ざっくり、こんな関係になっています。
1. /done
解決したかったこと
コミット作業は毎日のようにあるので自動化する価値があります。
自動化すると下記のようなことを考えなくて済みます。
- 変更ファイルを眺めて、どう分割するか考える
- それぞれにコミットメッセージを考える
- push 先ブランチを確認する
- 順番に
git add→git commit→git pushを打つ
スキルの動き
/done と打つと、こうなります。
設計のポイント
コミット粒度の判断だけ自分に残し、残りは全部Claudeに任せるというのがちょうど良いバランスです。承認ステップは必ず含めましょう。
2. /survey
解決したかったこと
障害や問い合わせの調査
- Backlog の課題を開いて内容を読み解く
- 該当ソースを探す
- DB を覗いて状態を確認する
- AWS のリソース状態を見る
- 仮説を立てる
このルーチンを自動化したいと考えていました。
スキルの動き
/survey <BacklogのURL> と渡すと、Backlog MCP / DB MCP / AWS CLI MCP を叩いて調査レポートを返してくれます。
このスキルの詳細とハマりどころは別記事に書いています。
DB・AWSは徹底してReadOnlyに固定しましょう。調査で本番環境に害を与えては元も子もないので。
3. /advise
解決したかったこと
技術判断の場面で、たとえばAIに「AとBどっち?」と聞くと、それっぽい答えが返ってきます。ただこれが曲者で、
- 学習時点で古い
- 出典が曖昧で検証できない
- そのまま採用すると後で後悔する
という状態になりがちでした。
スキルの動き
/advise ○○と××のメリットデメリットを整理して と打つと、3層構造で情報源を辿ります。
ポイントは「層を下るほど情報の信頼度が落ちる」ことを構造で表現していて、回答時に「どの層から取ってきたかを明示」してくれる点です。
設計のポイント
llms.txt を最初に見るのが一番効きます。最近の主要ライブラリは公式に llms.txt
を置いていることが多く、ここを抑えるだけで一次情報のヒット率が大きく変わります。
個人記事は「個人記事です」とラベルが付いて返ってきます。完全に排除はしませんが、判断材料として位置づけています。
3つに共通する設計思想
| フェーズ | 人間の役割 | AIの役割 |
|---|---|---|
| 入力 | 短い指示を1行だけ打つ | URLや差分から文脈を読み取る |
| 中間処理 | (関与しない) | MCPや外部ツールを束ねて実行する |
| 承認 | 「この粒度・この方向でいいか」を即断する | 判断材料を整理して提示する |
| 改善ループ | (関与しない) | 失敗時にリトライ・再調査して結果を出し直す |
「人間にしか出来ない判断だけを残す」という設計が、使い続けられるスキルの条件だったということになります。
おわりに
毎日使うスキルになるかどうかは「自分の作業導線の中に含まれているか」で決まります。
もし自作スキルが埋もれて使われていないなら、機能を足すより一度導線を見直すほうが早いかもしれません。
あわせて読みたい
/survey の運用詳細