エージェント向け文章作成 は何をしますか？
このスキルを使ってあなたが書くものの読み手は、テキストしか持っていないエージェントです。そのエージェントは会話の経緯を見ておらず、あなたの意図を尋ねることもできず、書かれた言葉を文字通り、そして全力で実行します。失敗のほとんどは、あなたが知っていることと、ページ上に書かれたこととの間のギャップから生じます。そのため、読み手の立場から作業を進めてください。書き始める前に、作業の終了点、読み手が置かれている状況、そして読み手が必要とする材料を決定し、その後、あなたなしで読み手が使用できる言葉でそれを書きます。
2種類の入力
大まかなリクエスト (「ログインテストが不安定なので、それを修正するエージェント用の指示書を書いて」): 会話とワークスペースから事実を収集し、ゼロからドラフトを作成します。
既存のプロンプト: それを保持します。実際に問題となっている箇所を修正するための最小限の編集を行い、構造や表現が機能している部分は維持し、作成者が述べていない要件は追加しません。完全な書き換えは、どの変更が重要だったかを隠し、作成者が意図していた意図を静かに無視することになります。以下のデフォルトは依然として適用されます。プロンプトに役割の一文、例、または最後のチェックが不足している場合は、それらを追加します。これら、または実際のギャップを埋めるルールのいずれかを追加する場合は、納品時にその旨をリストアップしてください。
ユーザーだけが知っている事実が、読み手が提供する成果物やその行動を変える可能性がある場合は、書く前に質問してください。せいぜい数問で、各質問にはあなたの推奨する回答を添えてください。そうでない場合は、適切なデフォルトを選択し、それを前提条件としてリストアップします。
書く前に
作業の終了点
目標、それが重要である理由（誰が結果を何のために使うのか）、完了の定義、そして何を成果として返すべきかを明記します。ルートではなく、目的地を説明します。成果、成功基準、制約を与え、読み手に経路を選択させます。現在のモデルは、あなたが指示する順序よりも優れた計画を立てます。あなたが誤って推測したステップも実行されてしまいます。ステップをリストアップするのは、移行のようにデプロイの前に実行しなければならないなど、順序自体が要件である場合のみにしてください。
Before: 1. refresh.tsを開く。2. refresh()をtry/catchでラップする。3. 3回リトライする。4. テストを実行する。
After: セッションがタイムアウトした場合、クライアントはユーザーがログイン状態を維持できるように、サイレントにトークンを更新する必要があります。完了条件は、tests/auth/refresh.test.tsの新しいタイムアウトケースがパスし、既存のテストがすべて失敗しないことです。AuthClientの公開APIは変更しないでください。3つの他のパッケージがそれを呼び出しているためです。
品質を示す形容詞を、読み手が適用できる基準に変えてください。「徹底的な」「簡潔な」「重要なものだけ」は文字通り、かつ予測不可能に適用されます。「重要な問題だけを報告する」ように指示されたレビュアーは、些細な問題を見つけてもそれについて黙っているでしょう。閾値を指定するか、何を保持し、何を削除するかを指定します。後のステップで結果をフィルタリングする場合は、すべてを要求します。
Before: 注意深くレビューし、重要な問題のみ報告してください。
After: 確信が持てないものも含め、見つけたすべての問題を報告し、それぞれに「動作を壊す」または「スタイルのみ」のタグを付けてください。フィルタリングは後のステップで行います。
読み手が置かれている状況
テキストがタスクを割り当てる場合（指示書、システムプロンプト、Issue、計画、または引き継ぎ文書）、最初に役割を定義する一文を置きます。読み手は誰か、このタスクにおける機能、そして置かれている状況は何か。「あなたはこのプルリクエストのコードレビュアーです。このPRはあなたが書いたものではなく、チームは本日中にマージする予定です。」役割は、読み手の視点と責任を設定します。ツールやスキルの説明には役割はありません。それらは、その機能となにをいつ使うかを述べます。
次に、読み手がその立場から見えないものを伝えます。タスクの途中で質問に答えられる人がいるか、無人で実行されるか、同じファイルやシステムで作業している他の人は誰か、変更はレビューされるか元に戻せるか、評価すべきか変更すべきか、そして委任を含め、尋ねずに行ってよいことは何か。報告のために停止すべき特定の状況を挙げます。「不明な点は質問してください」では読み手に推測を強いることになり、結局すべてについて尋ねるか、何も尋ねないかのどちらかになります。
あなたは無人で実行されます。終了するまで誰も質問に答えられません。修正がデータを削除したり、src/auth/ の外のコードに影響を与える場合のみ停止して報告してください。別のエージェントが同時に docs/ を編集しています。そのため、そのディレクトリには触れず、あなたが行っていない変更を元に戻さないでください。
読み手が必要とする材料
各ソースについて、その場所とそこから何を取得すべきかを示します。言い換えるのではなく、読み手が自分で開けるもの（ファイルパス、コマンド、到達可能なURL）を指し示し、実際のものを読ませます。あなたのコンテキストにのみ存在するもの（会話で決定されたこと、要件に関するユーザーの言葉、あなたが実行したコマンドの結果、すでに却下されたアプローチとその理由）は、完全に書き出します。
Before: docs/ と以前の議論を参照してください。
After: 丸めルールについては docs/billing.md の「返金」セクションを読んでください。ファイルにない要件が1つあります。ユーザーの言葉は次のとおりです。「部分返金は、通貨換算後であっても、元の請求額を決して超えてはなりません。」
ログ、ユーザーテキスト、または別のエージェントの出力を含める場合は、明確にマークされたブロックに入れ、それが指示ではなく、作業のための材料であることを述べます。自分の指示はそのようなブロックの外側に保ちます。引用符やデータブロック内のテキストは、権限のないコンテンツとして扱われることが一般的だからです。
書き方
読み手の言葉を使い、あなたの言葉は使いません。作業中にあなたはラベル（「オプションB」「楽な方法」「P2の問題」）や略語（「→ ロック競合」）を作り出しましたが、これらは読み手にとって何の意味もありません。それぞれをそれが表すものに置き換え、専門用語は一度定義し、初めて説明するかのように書きます。以前に行われた作業を説明するときは、誰が行ったかを述べ、読み手が自分自身でその行動を起こしたと誤解しないようにします。
Before: オプションBは却下（→ ロック競合）; 遅延初期化を継続、P2の落とし穴に注意。
After: 以前のセッションでは、リクエストごとにコネクションプールを再構築することを却下しました。負荷がかかると、ロック競合のためにp95レイテンシが80msから400msに上昇したためです。現在のアプローチは、初回使用時にプールを作成します。1つの既知の問題が残っています: ...
各ルールには、その理由を節として付け加えます（「…なぜならスクリプトがこのフィールドをパースするから」）。理由により、読み手はあなたが列挙しなかったケースも処理でき、ルールの及ぶ範囲が示されます。有能なモデルがすでに理由を知っている場合、または文脈から明らかな場合にのみ、理由を省略します。
各ルールは、それが属する場所に一度だけ記述します。繰り返しは重みを加えず、ルールの過剰適用を招きます（「まず質問せよ」の繰り返しは、安全なステップでの停止につながります）。また、コピーは編集のたびに乖離していきます。同じ理由で、プレーンな表現を使用し、大文字やIMPORTANT、あるいは「これは極めて重要です」「怠けてはいけません」のようなプレッシャーを与える言葉は使いません。安全リミットや不可逆的な操作など、真の不変条件には「決して」「常に」のような絶対的な言葉を取っておきます。
考え方を指示しないでください。「ステップバイステップで考えてください」や、回答やタグに推論を書き込むよう要求するのは避けてください。現在のモデルは自ら推論し、推論の書き起こしを要求するリクエストを断るものもあります。理由を確認する必要がある場合は、簡単な説明や、ファイル:行参照やコマンド出力などの裏付けとなる証拠を求めてください。
既知の障害を修正する場合は、その背後にある原則と理由を書き、あなたが見た唯一のインスタンスの禁止事項を書かないでください。禁止事項のリストは、リストされているものだけをカバーします。原則は、周辺のケースもカバーします。
Before: Object.create() を使用しないでください。proto を使用しないでください。
After: プロトタイプ操作よりも明示的な合成を優先してください。ここのレビュアーは上から下に読めるコードを好むためです。
段落で書きましょう。リストは、真に並列的または順序的な項目（フィールド、順序付きステップ、独立したチェック）にのみ使用します。箇条書きは、指示を結び付ける「なぜなら」「～でない限り」を取り除き、読み手は与えられたフォーマットを反映する傾向があります。
読み手が生成すべきものの短い例を1つ含め、それが例であることを明示します。例は、段落による説明よりも、形式、トーン、詳細レベルをうまく伝えます。期待される出力が言葉だけで明白な場合（実行する単一のコマンドなど）にのみ、例を省略します。
タスクを割り当てるテキストは、読み手が完了を報告する前に実行するチェックで終了します。存在する場合は、結果を証明するコマンドまたはテスト、そうでない場合は、見直すための完了基準です。検証できなかったことを明確に述べるように要求します。
納品
完成したテキストを、既存のプロンプトの言語またはユーザーが要求した言語で、貼り付けるか、すでにファイルに書き込める状態で引き渡します。その外側に、ユーザーが変更したいと思うかもしれない、あなたが行った前提を数行でリストアップします。設計上のメモはテキスト自体に含めないでください。
納品する前に、読み手としてドラフトを読んでください。読み手は有能ですが、このページだけを手にしています。あなたの意図を推測しなければならない箇所があれば、ページを修正してください。