shunk031-codex-worker-prompting

メモ

この SKILL.md を読んだ後、次のように言ってください：🤖 I read shunk031-codex-worker-prompting.

Codex ワーカーへのプロンプト作成

ワーカーの判断基準と停止条件を明確にするプロンプトを作成します。

前提。 Codex ファミリーのワーカーは、横断的な編集を、個々の箇所ごとに判断が必要な場合でも、sed、正規表現、スクリプトによる書き換えなどを使った一括の機械的変換にしてしまう傾向があります。判断を伴う横断的な編集を依頼する際は、一括検索置換を明示的に禁止し、コミット前に差分の各ハンクを確認しながら、1 箇所ずつ編集するよう求めてください。

スキルのパス。 依頼がスキルに依存する場合は、必要なスキルをそれぞれ、読みやすいパスとともに明記し、スキルを呼び出すのではなくファイルを読むよう指示する場合は「ファイルを読む」と伝えてください。どのスキルが該当するかをワーカーに推測させず、依頼に関係のないスキルは含めないでください。

前提。 ユーザーからリテラルな成果物（書式の例、正確な文言、表、名前など）が提示された場合は、変更せずにそのまま依頼文に貼り付け、verbatim と明記してください。言い換えると、インラインコードの書式、句読点、大文字小文字の区別といった重要な性質が気付かないうちに失われ、ワーカーが劣化したコピーを忠実に実装してしまいます。ワーカーが原文と照合できるよう、ユーザーの元の言葉とオーケストレーターの解釈が見た目で区別できるようにしてください。

公開用／非公開用 dotfiles、または Codex の設定に関する作業では、shunk031-manage-public-private-dotfiles スキルを使うようワーカーに伝えてください。このスキルでは、読み取り可能な場合は ~/.agents/AGENTS-private.md と、両方の dotfiles リポジトリのルートにある AGENTS.md ファイルを読む必要があります。Codex 固有の非公開 AGENTS.md を勝手に作り出さず、この安定した非公開指示ファイルのパスを参照してください。

8つの原則

1. 曖昧な雰囲気ではなく、契約を書く。 タスクで必要な場合は、機械で検証できる受け入れ条件と停止条件を明記します。状態を伴う作業やリスクの高い作業では、正確な SHA、コマンド、合否ゲートを使い、軽量なタスクは軽量なままにします。作業者にはゲートに照らして自己チェックさせ、ゲートを達成できない場合は停止させます。その違いが判断に影響する場合は、ゲートと併せて、ゲートでは測定できないことも明記します。
2. 記述どおりに実行されることを前提とする。 間違いも含め、すべての記述が書かれたとおりに実行されると想定します。作業者が古い情報や誤った情報で進めないよう、読み戻し、ls-remote との比較、事前条件の確認などの検証条項を加えます。数値、主張の強さ、帰属、ファイルの対象範囲、セクションの順序など、不変条件を明示します。記述を文字どおりに実行する作業者にとって、明示されていない性質はすべて変更可能です。
3. タスク数ではなく、ループに上限を設ける。 ディスパッチにはライフサイクル全体を含めてもかまいませんが、再試行可能な各手順には、明示的な再試行回数、待機時間、最終報告状態を設定します。スクリーニングやレビューなどの判断タスクでは、判断ルール、不確実なケースでの既定の判断、そしてその判断を正当化するコストの非対称性を明記します。ユーザー所有のマージや破壊的操作など、認可の境界をプロンプト内の STOP 条件として記述します。
4. 関連する環境の検証済み事実を列挙する。 プロキシ、プッシュ URL の落とし穴、API フィールド、サンドボックス変数、認証のフォールバックなど、タスクに影響し得る事実のみを列挙します。未検証の見解は検証すべき仮説として記述し、確認用コマンドも含めます。その都度遭遇する可能性のある継続的な認可は、各ディスパッチに繰り返し記載します。
5. 実装方法ではなく、要件と受け入れ基準をディスパッチする。 ツールやアプローチが適切でないと考える場合は、その考えを作業者が検証すべき仮説として提示し、ツールの選定には実装前の調査を必須とします。作業者は解決策の立て方も文字どおりに実行するため、まったく誤ったものを見事に作り上げてしまいます。
6. 成果物の対象読者に合った文体でディスパッチを書く。 作業者はディスパッチの語彙や制約を成果物に反映します。読者向けの成果物では、内部コードネームや監査上の制約をプロンプト本文に含めず、遵守の証拠は文書ではなく PR 本文に記載するよう明示します。 成果物が読者向けレポートの場合、まず shunk031-writing-kosshi スキルを読み、次に shunk031-writing-telegraph スキルを読んで、両方をレポート本文に適用するよう作業者に求めます。この要件はレポートに限定し、ユーザーがその文体を求めない限り、ディスパッチや通常の進捗・最終返信には適用しません。
7. 欠陥のクラスを修正し、網羅的に洗い出したことを証明する。 レビュアーが欠陥の具体例を指摘したら、作業者にはその欠陥クラス全体を取り除くよう指示します。すべての候補を列挙して分類した表、または修正前に既知の不良状態を再現し、修正後に不具合がゼロであることを報告する検出器を、網羅性の証拠として必須にします。
8. 役割と性能低下に応じて、次にコンテキストに応じて交代する。 独立したレビュー判定ごとに新しいセッションを開始し、出力の質が低下しているセッションや、失敗したアプローチに固執しているセッションは終了します。長時間稼働する作業者は、コンテキストが尽きる前に自然な区切りで交代させます。残りコンテキストの一定割合を基準にするのは、信頼できるトリガーではありません。クラッシュや交代後に再ディスパッチする際は、パスと各成果物が最終版かどうかを含め、ディスク上の状態を列挙し、再計算してはならないものを明記します。リポジトリの方針で許可される場合は、引き継ぎ状態を引き継ぎ文書や PR コメントに外部化します。PR 本文は読者向けとし、状態の台帳にはしません。

ディスパッチの送信、報告形式、結果の照合などの伝達手順は shunk031-herdr-orchestrate-workers スキルに属します。このスキルが扱うのは、プロンプト作成のガイダンスのみです。