ここでは少し長めのまとまった何かを行う Skill をオーケストレーション Skill と呼んでいる。 最近それっぽいものを何度か作る機会があり、それに伴って skill-creator や公式の記事を読んだりしていたので、作って思ったこととか読んで思ったことがごちゃまぜに書いてある。 基本的には skill-creator を使って作り、中身を読んで調整するような形で作っていた。普段から skill をたくさん作っている人には当たり前の内容だとは思う。
どこからなにをするかをルーティングする
決定的なワークフローや script ではなく、Skill として実装することのメリットは柔軟性にあるはず。特定のワークフローを完遂することにこだわるよりも、ユーザーがなにをしたいかを汲み取るのが良さそう。
必要なコンテキストを先に集める
基本的に長めのタスクを任せることになるので、ユーザーの求めていることや疑問点を先に解消してからあとの処理続くような構成にする。こうしておくと途中で止まることが少なくなるので、ユーザーの入力以外のコンテキスト(他のコードの参照とか)も含めて頭の方に持ってくるようにしている。
なぜ必要かを書く
これは言わずもがななのだが、ついつい処理の手順を書いてしまうので戒めとして。
考えが広がるようなプロンプトを書く
Lessons from building Claude Code: How we use skills | Claude by Anthropic を読んでいると次のようなことが書いてある
Claude already knows how to code and can read your codebase. A skill that restates what Claude would do by default adds context without adding value. If you’re publishing a skill that is primarily about knowledge, focus on information that pushes Claude out of its normal way of thinking. The frontend design skill is a great example; it was built by an engineer at Anthropic by iterating with customers on improving Claude’s design taste, avoiding classic patterns like the Inter font and purple gradients.
言いたいことはわかるが言ってることはわからないなとずっと思っていたのだけど、skill-creator を読むと次のようなプロンプトがあってなるほどなぁとなった。
This task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over.
Skill のコアとなるような場所にはこの手のこと書いておくとよいのかなと思い実践している。その都度それっぽいことを考えるのだが難しい。
HTML で成果物を提示する
最近流行りのやつ。skill-creator だと eval 的な評価をするときに主に使われるが、自分は設計を HTML として吐き出したり、コードレビューの助けになりそうな解説を作って出したりしている事が多い。
決定論的な処理は script にする
これも言わずもがなだが、決定論的なことは skill の中に手順を書くのでなく script にしたほうがいい。トークンの無駄だし、それが原因で安定しなくなってもしょうもないので。