三回目のチャットも、また同じ説明から始まります。ブリーフィングにはどの項目が含まれるのか、チームではどんな用語を使うのか、何かが欠けていたらどうするのか。繰り返しが起きているのは、その作業のやり方を書き出せるという良いサインです。スキルはそれを再利用可能な指示に変え、あなたはそれを意図して適用し、保守し続けます。
Claude Codeについては、 公式のスキルドキュメント が、メタデータと指示を含むSKILL.mdについて説明しています。これは、タスクが合致したとき、または明示的に呼び出されたときに使用できます。これによって変わるのは作業のための指示であり、学習済みのモデルの重みではありません。以下のファイルは私たち独自の説明用の下書きであり、実際に行った実行の報告ではありません。
まず決定、それからファイル
例として取り上げるのは、毎月開かれる修理の夕べです。運営メモから社内向けのブリーフィングを作成します。そこでは、手伝う人たちが確定した取り決め、タスク、未決の決定事項を必要としています。これはイベント全体を計画するよりも小さな依頼です。
事前に入力の取り決めを書き出しておきましょう。すべての項目には値とステータスが必要です。「開始 18:00、確定」と「開始 18:00、提案」は別物です。AIはその違いを保たなければなりません。会場が欠けていれば、それは未解決の問いです。もっともらしい代わりの住所を入れてしまえば、依頼の趣旨が崩れてしまいます。
SKILL.mdは短く、明確に
プロジェクト単位で置ける場所の一例は .claude/skills/reparaturbrief/です。ここには、次のような独自の作業指示を記述できます。メタデータは、それがいつ必要になるかを説明し、その下の本文は何を出力すべきかを記述します。
---
name: reparaturbrief
description: Creates internal briefings for repair evenings from organisational notes.
---
Record confirmed details and suggestions separately.
Do not invent venues, dates, names or commitments.
If there are contradictions: state both details and phrase a follow-up question.
Output:
1. Confirmed arrangements
2. Tasks with confirmed responsibility
3. Open decisions with a reference to the input
4. Next coordination step「運営に関することなら何でも手伝う」といった説明では、伝わる情報が少なくなります。スキルがどこに適合し、どんなときに別の作業のやり方がふさわしいのかがわかりにくくなるからです。明確な境界があれば、後の保守も楽になります。
本物の抜けを含むサンプルの引き継ぎ
架空のメモを使います。会場は確定、開始時刻はまだ提案にすぎず、資材は予算が承認されてから初めて発注されます。これらの条件をそのまま明記してください。期待される出力には「予算を確認する」というタスクが含まれていてもかまいません。一方、「資材を発注済み」は、根拠のない新たな主張になってしまいます。
役に立つ追加の指示としては、「未決の決定事項ごとに、入力のどの部分がそれを生じさせたのかを示すこと」があります。これにより、抜けとその出どころが結び付きます。スキルは元の文章全体を繰り返す必要はありません。問題となっている項目を見つけやすくすればよいのです。
文体の好みは、内容に関するルールとは分けておきましょう。短いタスク説明の例は、補助ファイルとして役立ちます。一方、頻繁に変わるイベントの詳細は、個々の依頼に含めるべきです。そうすれば、一般的な指示が次の日程が来るたびに古くなることはありません。
三つのケースで、異なる弱点が見えてきます
一つ目のケースでは、完全で矛盾のない情報を渡します。二つ目では、日付が欠けていて、予算に関する二つのメモが互いに矛盾しています。三つ目では、旅行の計画など、スキルの守備範囲外のことを頼みます。これにより、構成、不確かさの扱い、利用の限界をそれぞれ分けて確認できます。
各ケースについて、絶対に保たなければならないことをメモしておきます。回答はまずそれで評価し、文体はその後で評価します。洗練された言い回しも、でっち上げられた日付の埋め合わせにはなりません。同様に、まさにその決定が入力に欠けているのであれば、確認の質問はエラーではありません。
小さな作業指示を保守する
問題が繰り返し起きたら、特定のルールを一つ変更し、既存のケースをもう一度試します。変更を書いた時点ではまだ知られていなかった新しいケースも追加してください。そうすることで、そのルールが単に一つの例をなぞっているだけなのかどうかが見えやすくなります。
変更の理由とそのステータスを記録しておきましょう。最初のうちは、大がかりな仕組みは必要ありません。「予算の条件はタスクリストの中でも保持すること」といった短いメモのほうが、理由のない全面的な書き直しよりも追いやすいものです。スキルに価値があるのは、そのルールによって次の実際の引き継ぎがわかりやすくなるときです。
出典および資料の確認時点：2026年十月25日。
