「話題のSkill検証」では、実物のコードやドキュメントを取得し、その方法論に自分が従ってみたうえで報告します。今回はskill-creatorを取り上げます。
skill-creatorとは何か
skill-creatorはhttps://github.com/anthropics/skillsのskills/skill-creatorディレクトリで公開されているSkillです。編集部でGitHub APIから直接ディレクトリ一覧を取得し、algorithmic-art、docx、pdf、pptxなどと並んでskill-creatorが実在することを確認しました。frontmatterのdescriptionには「Create new skills, modify and improve existing skills, and measure skill performance」とあり、新規作成だけでなく既存Skillの改善やトリガー精度の最適化まで担う設計です。
SKILL.md本体は500行近くあり、要件のヒアリングからSKILL.mdの執筆、テストプロンプトでの実行、評価、改善という一連の流れを一つのSkillにまとめています。同梱のagents/ディレクトリにはgrader（採点）、comparator（比較）、analyzer（分析）という3つのサブエージェント向け指示書があり、references/schemas.mdには評価結果や比較結果をやり取りするJSON形式が定義されています。
手順どおりに1本作ってみた
skill-creatorが定める最初の工程は要件の把握です。SKILL.mdは「このSkillでClaudeに何をさせたいか」「どんな場面で発動すべきか」「期待する出力形式は何か」「テストケースを用意するか」の4点を先に固めるよう指示しています。編集部では実在の依頼者がいないため、この4点を自分で仮置きしました。題材は会議メモを議事録に清書するSkillとし、出力形式は開催概要、決定事項、議論の要点、未決事項、アクションアイテムの5節構成に決めました。
descriptionの書き方にはskill-creator独自の指示があります。Claudeは有用な場面でもSkillを発動しない傾向があるため、descriptionは「少し押しの強い」書き方にせよという指示です。この指示に従い、単に「議事録を作る」ではなく、「会議メモを清書して、議事録にして、といった言い方でも発動する」という具体的なトリガー文言まで書き込みました。
本文の構成も、skill-creatorが挙げる「出力形式の定義パターン」に沿わせています。以下は実際に書き上げたSKILL.mdからの抜粋です。
## Structure of the output
Always use this exact section order:
# [会議名] 議事録
## 開催概要
日時：
参加者：
記録者：
## 決定事項
（箇条書き。決まったことだけを書く。検討中の案は含めない）
## 議論の要点
（トピックごとに小見出しを立てる。誰が何を言ったかではなく、論点と結論を書く）
## 未決事項・懸念
（結論が出なかった論点。次回に持ち越すことが明示されているものはその旨を書く）
## アクションアイテム
| 担当 | 内容 | 期限 |skill-creatorは「Writing Style」の節で、命令口調のMUSTを並べるのではなく、なぜその指示が必要かを説明せよと繰り返し求めています。この指示に従い、たとえば決定事項の節については「決まったことだけを書く」という指示の後に、未決事項と混ぜてはならない理由を別の節で補いました。会議メモには「〜する方向で」のような曖昧な言い方が混在するため、この曖昧さをどちらの節に振り分けるかを名指しで指示しないと、Skillを使う側のClaudeが毎回別の判断をしてしまうと考えたためです。
出来上がったSKILL.mdの全文は、編集部の作業用ディレクトリに保存してあります。
効いた点
もっとも効果を感じたのは、SKILL.mdを書き始める前に「何が発動条件で、何が出力形式か」を4つの質問で先に固めさせる構成です。descriptionと本文を同時に書き始めると、発動条件の話と出力形式の話が混ざり、結果としてdescriptionに本文の内容が漏れ出す書き方になりがちです。skill-creatorはこの2つを明確に分離させたうえで、「発動条件に関する情報はすべてdescriptionに書き、本文には書かない」と役割を線引きしていました。
「言い訳ではなく理由を書け」という指示も、実際に手を動かすと効果が分かりました。最初に書いた下書きでは「担当者名は略称のまま残してはならない」とだけ書いていましたが、なぜという理由がないと、フルネームが分からない場合にSkillを使う側のClaudeが処理に詰まります。理由を書き足す過程で、「突き合わせが取れない場合は略称のまま残し、その旨を記録者に確認する」という代替の手順まで自然に思いつきました。指示の理由を書かせる構成が、抜け漏れに気づく機会にもなっていました。
迷った点
もっとも判断に迷ったのは、テストケースの実行工程です。skill-creatorは、SKILL.mdの下書きを書いたら2、3個のテストプロンプトを用意し、Skillありのサブエージェントとなしのサブエージェントを同時に走らせて結果を比較する手順を定めています。この手順は実際にSkillを動かして精度を検証するためのものであり、今回の検証方針である「コードは実行しない」という制約とぶつかります。結果として、この記事の作業ではテストケースの実行と採点の工程を行わず、SKILL.mdの設計までにとどめました。
もう一点迷ったのは、要件ヒアリングの相手が実在しない場合の扱いです。skill-creatorの手順は、実際の依頼者に発動条件や出力形式を確認しながら進める前提で書かれています。今回は依頼者がいないため、編集部が自分で要件を仮置きしましたが、この仮置きが本当に実務で使う人の要求と一致しているかは、この記事の作業だけでは確認できません。skill-creator自身も、依頼者がいない状態での設計についての指示は用意していませんでした。
どんな人に向くか
skill-creatorは、Skillを実際に作って配布し、複数人に使わせて精度を上げていく運用を想定した作りです。テストプロンプトの実行、採点、ベンチマーク集計という工程が本文の半分近くを占めており、この工程を飛ばしても要件整理とSKILL.md執筆の部分だけは単独で使えます。一方、初めてSkillを書く人や、まず1本だけ試作してみたい人には、テスト工程を含む全体の手順がやや重く感じられる可能性があります。その場合は、この記事で行ったように「要件の4点確認」と「出力形式の定義パターン」だけを取り出して使う進め方が現実的です。