仕事はすべてSkillに書け - それ、Skill にしない？

「それ、Skill にしない？」

最近、自分の口癖がこれになった。誰かがSlackで手順を聞いてきたとき。自分が同じ作業を3回目にやったとき。同僚にレビューの観点を説明しているとき。

タイトルは盛ってる自覚はある。でも実際に50個以上作ってみて、割と本気でそう思っている。

仕事のやり方が驚くほど変わった。仕事を「やる」のではなく「書く」ようになった。

「ドキュメント書きましょう、なんて話は100回聞いたよ」と思うかもしれない。ただ、Agent Skill をきっかけに「仕事をドキュメント化する」ことの重要性が爆発的に高まった。

ConfluenceやWikiに書いた手順書は、大抵は書かれて終わり。SKILL.md に書いた手順は、AIが読んで、そのまま実行する。

これからは 「ドキュメントにしましょう」ではなく「Skillにしましょう」が合言葉になる

言葉にすれば、誰でも使える指南書になる

Agent Skill の正体は、ただのMarkdownファイルだ。SKILL.md に自然言語で手順を書く。

# daily-standup

1. GitHub API で昨日のPR・Issue・レビューを取得する
2. Slack の #eng-standup の直近の投稿を読む
3. これらを「スタンドアップの形式」に従い、チームに伝わるように要約する
4. Slack に投稿する

人間が読めば「スタンドアップってこういう情報がシェアされてるのね」と分かる。新メンバーへの引き継ぎ資料にもなる。AIが読めば、そのまま実行する。API を叩いて、要約して、投稿する。

同じファイルが、人間にとっての手順書であり、AIにとっての実行指示でもある。この二重性が、従来のドキュメントにはなかった性質だと思う。

従来のドキュメントは「読まれること」がゴールだった。読まれなければ価値ゼロで、現実には大抵読まれない。書いた本人すら半年後に存在を忘れる。SKILL.md はAIが毎回読んで、毎回実行する。結果的にメンテされる。

Skill に書こうとすると、曖昧さを潰さざるを得ない。料理で「塩を適量」と言われても初心者には作れないのと同じで、「PRを確認してスタンドアップを書く」では足りない。どのリポジトリの、いつからいつまでの、何を見て、どういう粒度でまとめるのか。書こうとした瞬間に「適量」の言語化を迫られる。

この「適量を言語化する」プロセスが、仕事の質を上げる。なぜなら、言葉にできないことは、他人にもAIにも伝わらないからだ。 逆に、言葉にできたことは、誰でも同じようにできるようになる。

AIに「Skillにできそうなのある？」と聞く

とはいえ、何から手をつければいいか分からないこともある。自分の仕事を棚卸しするのは意外と難しい。毎日やっていることほど意識に上らない。

そういうときは逆方向から攻める。普段からAIを使ってるならAIに聞けばいい。

Claude Code なら、過去のセッション履歴が残っている。こう聞くだけ。

最近のセッション履歴を見て、繰り返しやっている作業パターンがあれば教えて。
Skillにできそうなものをリストアップして。

AIは自分より自分の作業を覚えている。「毎朝 GitHub の通知を確認して Slack にまとめてますよね」「PR のレビュー依頼を出すとき、毎回同じ観点をチェックしてますよね」— 自分では当たり前すぎて気づかなかったパターンが出てくる。

これは振り返りとしても面白い。自分が何に時間を使っているのか、客観的に見える。「俺こんなに dependency update の対応してたの？」と気づいたら、そこが Skill 化の一丁目一番地だったりする。

流れとしてはこんな感じ。

1. AIに聞く — 繰り返しパターンを洗い出してもらう
2. 選ぶ — 「確かにこれ毎回やってるな」と思うものをピックアップ
3. 書く — SKILL.md に手順を言語化する。最初は雑でいい
4. 使う — 実際にSkillとして呼び出す。動かしてみると足りない部分が見える
5. 直す — 使いながら磨いていく

最初から完璧なものを書こうとしなくていい。とりあえず書いて「Skill化する」を徹底してほしい。

Skills リポジトリという「場所」を作る

Skillを書く気になった。AIに聞いて候補も見つかった。じゃあどこに置く？
まずオススメは Private リポジトリだ。

なにも考えずリポジトリを1個作ればいい。

gh repo create skills --private

組織なら Private Repo。社内の手順やワークフローが入るから。個人なら機密情報がないか確認の上 Public でもいい。自分のSkillが誰かの役に立つかもしれない。

大事なのは構成じゃなくて、場所があるという事実のほう。「あ、これSkillにできそう」と思ったとき、置く場所が決まっていれば書くハードルが下がる。場所がないと「まあ後でいいか」で終わってしまう。

ディレクトリにフラットに置けばいい

skills/
├── daily-standup/
│   └── SKILL.md
├── pr-review/
│   └── SKILL.md
├── release-notes/
│   └── SKILL.md
└── README.md

最初は3個くらいで十分。フォルダを作って、SKILL.md を1枚置く。まず箱を作る。中身は後からついてくる。

実際に私のSkill群を置いておく。どんな内容なのか、イメージが湧くと思う。

https://github.com/jackchuka/skills

よくある失敗

Skill を書き始めると、いくつかのパターンでつまずく。自分がやってきた失敗を共有しておく。

「正しい書き方」を調べる沼にハマる。 frontmatter のフィールド、ディレクトリ構成、命名規則 — 書く前に調べ物で力尽きる。正解はない。動かしてから直せばいい。

個人情報が気になって書けない。 Slack の channel ID、社内のリポジトリ名、自分のユーザー名。Private Repo なら気にしなくていい。公開したくなったら、そのとき値を外出しすればいい。

大きく作りすぎる。 「デプロイ全自動化Skill」みたいなのを最初に作ろうとして、10ステップ、分岐あり、エラーハンドリングあり。途中で飽きて放置される。最初は「1つのことだけやる」くらいがちょうどいい。

「これはSkillにするほどでもない」と思ってしまう。 一番もったいない失敗。5分の作業でも、週3回やってるなら書く価値がある。Skillの価値は1回の重さじゃなく、頻度で決まる。

まず1個、書いてみる

やってる仕事はとりあえずSkillに書こう。

書いたものは、人間が読めば手順書になる。AIが読めば実行される。自分の仕事にインターフェイスを切ることで、頭の中にしかなかったものが、誰でも使える形になる。

何から書けばいいか分からなければAIに聞けばいい。置く場所はリポジトリを1個作るだけ。

まず1個。今日やった仕事を、SKILL.md に書いてみてほしい。