目的
シンプルなスキルの設計図を、ユーザーと協力して作成すること。このスキルはClaude、ChatGPT、Copilotで構築可能であること。すべての質問、ドラフト行、修正を、次の問いに対してチェックすること：「これは、ユーザーが目的を達成するための最もシンプルなスキルを作成するのに役立っているか？」
手順
新しいスキルの作成と監査は、同じ手順に従います。質問は最大でも2ラウンド（ステップ1と4）のみ行います。ステップ2と5での確認は、「はい」または「変更」のみを求めます。すべての質問や確認の際には、あなたの推奨事項とその理由を提示し、ユーザーが単純に同意するか変更できるようにします。早い段階でドラフトを作成し、ユーザーが抽象的な質問に答える代わりに、具体的なものに反応できるようにします。
- タスクを理解する。 ユーザーが何を達成しようとしているのか、彼らにとって良い結果とは何か、そしてどのAIツールを使用しているのかを明らかにするための、自由形式の質問を1つ行います。監査の場合は、スキルを尋ねます。会話ですでに回答済みのことはスキップします。
- 形を決める。 1つのスキルか複数のスキルか、そして手順、標準、またはその両方か（「2種類のスキル」を参照）を決定します。目的に基づいて決定し、入力に基づいて決定しないでください。1つの目的は1つのスキルであり、入力がどれほど多様であっても変わりません。2つの目的は2つのスキルを意味します。ほとんどの入力で手順が変わる場合は、隠れた2つ目の目的がないか確認します。形を推奨し、確認をとってから次に進みます。
- 設計図をドラフトする。 持っている情報から7つのパーツすべてをドラフトし、それぞれの推測を前提としてマークします。監査の場合は、各パーツが存在するか欠落しているかをマークします。その分野で認知されたベストプラクティス（ストーリーラインのためのミントのピラミッド原則、プレーンなテクニカルライティングのためのASD-STE100）やペルソナ（コピーを引き締めるスキルには経験豊富な新聞校閲者）を考慮すると、スキルに焦点が当たるかどうかを検討します。なぜなら、それらを指定することで、LLMがすでに知っている実践の体系を指し示し、いくつかのルールの代わりとなるからです。LLMの行動を変える場合にのみ追加し、ペルソナとその人が何を異なる方法で行うかをペアにします。ロールだけでは主にトーンが変わるからです。それを理由とともに前提としてリストアップし、ユーザーが同意、交換、または破棄できるようにします。
- ギャップを埋める。 1つのメッセージで、スキルを最も変える可能性のある前提について、最大3つの質問をします。これが最後のラウンドです。それでも不明な点は、リストされた前提として残ります。
- チェックし、承認を求める。 まず、設計図をユーザーが達成しようとしていること（ステップ1から）に対してチェックし、次に「良いスキルとは」に対してチェックし、不合格の部分を修正します。設計図を表示し、「現状のまま承認、変更、または破棄しますか？」と尋ねます（監査の場合：「どの修正案を採用しますか？」）。ユーザーが承認した後にのみ、スキルを作成または変更します。
良いスキルとは
2種類のスキル
- 手順（Steps）: 順序のあるプロセス。例：すべての文字起こしを同じ要約に変換する。
- 標準（Standard）: 結果が満たさなければならないルール。順序は任意。例：誰かの口調で書く。標準のスキルでは、標準が「方法」になります。手順のスキルでは、良い結果のための標準は「コンテキスト」に入ります。
- 多くのスキルは両方を使用します。例：標準に対するチェックで終わる手順。
7つのパーツ
「LLM」とは、スキルを実行するAIモデルを意味します。3列目は、各パーツの背後にある第一の原則、すなわちLLMの限界を示しています。7つすべてをカバーします。デフォルトでは、各パーツに独自の小見出しを付けます。ユーザーが特定の事項を最も重要だと言った場合は、あなたの判断で（独自の小見出し、またはパーツの統合）、以下のすべての質問に回答されている限り、柔軟に対応します。
| パーツ | 問うべき質問 | 理由（LLMが...だから） |
|---|---|---|
| 目的 | スキルが何を解決するのかを1〜2文で述べ、各ステップと結果をそれに対してチェックするようLLMに指示しているか？ | カバーされていないケースが発生したときに目標に立ち返るため、目標はすべてのステップで想起できるほど短くなければならない |
| トリガー | 説明文が、スキルが何をし、いつ使用するかを、簡潔な一文で述べているか？ | スキルが開始されるまではこれだけを見ており、すべてのチャットで各スキルの説明を読む |
| 入力 | ユーザーが何を提供しなければならないか、いつ開始するのに十分な情報があるか、入力の種類によって何が変わるかを述べているか？作業方法の変更は「方法」に「もし〜なら、こうする」として記載する。 | ギャップがあるところは推測する |
| 方法 | LLMが何をするかを述べているか：順序のある手順、元に戻すのが難しいことの前とユーザーの判断が必要なところで「停止して質問」を含む手順、標準、またはその両方？ | 行動して完了することに傾くため、停止する場所を指示されなければ停止しない |
| コンテキスト | LLMがまだ知らないであろう背景情報（定義、情報源、準拠すべきベストプラクティスやペルソナ、結果の受け手など）を提供しているか？ | 目の前にある情報しか知らない |
| ガイドラインと検証 | 結果を壊すであろういくつかの間違いを、それぞれの代わりに何をすべきかとともに挙げ、LLM自身の方法で結論を何か（情報源、引用、ユーザーの言葉）と照合するように促しているか？ | 禁止されたことを思い浮かべ、推測しながらも確信を持って発言することができる |
| 出力 | 結果とその出力先を説明し、使用する人々に適した例を1つ挙げ、完了とは何かを述べているか？ | 例を厳密にコピーし、自分が完了したと思った時点で停止する |
従うことができるか？
すべての行について問いかけること：
- そのタスクに不慣れな人が、意味を尋ねることなく従うことができるか？
- スキル内の他の行（追加または変更された行を含む）を繰り返したり、矛盾したりしていないか？
記述ルール
ASD-STE100（簡易化テクニカルイングリッシュ）をガイドとして言語を簡素化し、各行がLLMに誤読されない一つの意味を持つようにします。
- ブリーフィング形式: 有能な同僚にブリーフィングするように書く：なぜ重要な事項が重要なのか、彼らが必要とする背景、そして目的を達成するために問うべき質問。推論するのに十分な量だけ、それ以上は不要。なぜなら、LLMは裸のルールを硬直的に適用する一方で、理由があればスキルにリストアップされていないケースを処理できるからです。
- 簡潔: より少なく、より豊かに。最も効果的な行（80/20）を残し、残りを削除します。たとえ真実で有用な行であっても、余分な行はLLMの注意を競合させるためです。前置きは削除します。約1000語が目安であり、制限ではありません。主要なルールは最初と最後に配置します。なぜなら、LLMは長いテキストの中盤に最も注意を払わないからです。背景情報が指示を上回り始めたら、それをリファレンスファイルに移動することを提案し、ユーザーに決定させます。
- 正確: 目的が必要とする結果を最もよく得られる一つの単語を使用します。正確とは、適切な単語であり、通常はより少ない単語を意味します。
- 検証可能: 各指示を動詞で始め、指示と完了ラインをLLMがチェックできるものにします（「短い」は「100語未満」になります）。判断の余地は目的に委ねます。
- タグ付け: 小見出しを使用して指示を整理し、指示ではない素材（例、テンプレート、ユーザーが貼り付けるテキストなど）のみを、その内容を示す名前のXMLタグ（
<example>）で囲みます。タグは、LLMにそのブロックの開始と終了、およびそれがサンプルであり命令ではないことを示します。ボディ部にタグを保持します。なぜなら、名前と説明にはタグを保持できないからです。追加する各タグを理由とともに前提としてリストアップし、ユーザーが保持または破棄できるようにします。
ガイドラインと検証
- スキルを変更するとき、LLMは各行のギャップに行を追加してパッチを当てる傾向があり、また短い方が良く見えるため必要な行を削除する傾向があります。変更が必要な行は、その後に行を追加する代わりに行自体を書き換え、目的は簡潔に保ちます。削除する前に、ユーザーが達成しようとしていること（ステップ1から）を明確にし、削除後のバージョンでもそれが達成できることを確認します。
- 監査では、各指摘の背後にある行を引用し、ユーザーが自分で確認できるようにします。
出力
- 新しいスキル: チャット内の設計図。各パーツにつき1〜2行。最後に、ステップ1でユーザーが指定したツールにインストールする方法を記載します。そのツールの現在の手順が不明な場合は調査します。なぜなら、各ツールがスキルをインストールする方法は頻繁に変更されるからです。その下に、あなたの前提と、2〜3のテストリクエストをリストアップし、それぞれに良い結果とは何かを記載します。
- 監査: スキルが何をしようとしているかを述べ、5行の要約（何が機能しているか、何が機能していないか、次に何をすべきか、そしてその理由）を提供し、次に欠落している各パーツと、チェックに不合格となった各行をリストアップします。
設計図の例（LLMがこの形に一致するように）：
目的: すべてのミーティングの文字起こしを同じ1ページの要約に変換し、決定事項とアクション項目を見つけやすくする。各項目を含める前に、その目的に照らしてチェックする。 トリガー: 誰かがミーティングの文字起こしを共有し、要約を依頼したときに使用する。 入力: 文字起こしと、要約の受け手。話者が特定されていない場合は、誰であるかを尋ねる。 方法: 誰のためのものかを尋ね、議論を決定事項、アクション項目、未解決の質問に分類し、最終化する前に停止して「不足している点や聞き間違いはありますか？」と尋ねる。 コンテキスト: 1ページのフォーマット、および読者がそれに何を求めているか。 ガイドラインと検証: 所有者を推測する代わりに、[owner?]とマークする。各アクションをリストする前に、文字起こしと照合する。 出力: チャット内の1ページの要約。すべてのアクションに所有者または[owner?]マークが付いた時点で完了。
完了条件
ユーザーが形に同意し、ステップ1で説明されたジョブを実行する設計図を承認し、7つのパーツすべてがカバーされ、すべての行が従うことができる状態になった時点で完了です。