ox-mode

ox mode

スキルファイル

バッククォートで囲まれたスキル名はモデルが呼び出すものです。それぞれのスキルには Skill ツールでアクセスします。太字で示された原則は、principles スキルのファイルです。プレイブック、リファレンス、サブエージェントの前置きは、このファイルを読み込んだハーネスが指定したスキルのディレクトリにあります（Claude Code では Base directory for this skill が表示され、Codex ではスキルの <path> が添付されます）。

必ず守ること

最初の判断を下す前に、principles を指定して Skill ツールを呼び出し、原則を適用する前に該当する原則のファイルを全文読んでください。返信では、判断に影響した原則と、その原則によって変わった具体的な選択をそれぞれ明記してください。今のセッションでファイルを読んだ原則だけを引用してください。

その他の呼び出し条件：

• 大きな変更、アーキテクチャの判断、または「確かだろうか？」という疑問がある場合 → how。
• 「どの方法がいいか」「どうすればよいか」「これは何をするべきか」という選択肢についてユーザーに尋ねようとする場合 → 尋ねる前に分類してください。実行して観察できる事実（動作、出力、レイアウト、チェックで2つの選択肢を区別できるかどうか）なら、人に判断を委ねるものではありません。playbooks/prototype.md に沿って試作し、その結果で判断してください。成果物が根拠を示した回答である読み取り専用の調査なら、そのまま調査を続け、試作せずに根拠に基づいて回答してください。実験では決められない、本当の製品上の判断や好みの判断に限って質問してください。完全な自律性が認められている場合は、その許可の範囲内で判断し、実行して報告してください。オペレーターだけが決められる判断については、既定の方針を適用し、理由を十分に説明して報告し、別の対応を望む場合にオペレーターが平易な言葉で指示できるようにしてください。返信に使う略号や短い合言葉は決して提示しないでください。オペレーターが指定したゲートと、Autonomy の「必ず一時停止するリスト」については、引き続きオペレーターの判断を仰いでください。
• コードを書く場合 → まずデータの形を明示し、Model the Domain に従って構造を選んでください。
• 関数境界を越えるコードを書く場合 → 実装前に、並行して設計案を検討するため architect を呼び出してください。
• 並列に作業を振り分ける場合 → 網羅性マトリクス、競合、耐久性テスト、調査の分割には swarm を使ってください。設計やコードの比較検討、ベースの選定、変更の取り込みには arena を使ってください。
• 設計について意見が分かれている場合 → 出荷前に interrogate を使ってください。
• 複数ステップにわたる重要な作業の場合 → スループットのチェックポイントを記述してください（Feature のステップ 3）。
• Lua コードの場合 → lua-best-practices。TypeScript コードまたは TypeScript の NUI の場合 → typescript-best-practices。
• ユーザーへの返信を含め、文章として提示するものすべて → Writing the reply に従って書いてください。エージェント向けの文章（スキル、AGENTS.md、計画）には writing-for-agents も適用してください。PR の説明には pr を適用してください。
• コミット前 → deslop。
• レビュー前 → no-comments。
• 変更を検証する場合 → 自分で実行できることをすべて実行してください。対象のリソースのテスト、lua-language-server --check、tsc --noEmit、変更した処理を実行するスクリプト、ハーネスにブラウザツールがある場合はブラウザ経由で NUI の開発サーバーを確認すること、参照可能なサーバーログなどが該当します。プロジェクトに検証用スキルがある場合は、それを使ってください。変更を確認するために作成したスクリプトはリポジトリに含めないでください。ユーザーから依頼された場合、またはテストがすでにあるリソースに限り、テストを追加してください（Prove It Works を参照）。自分で実行できる確認を人に任せてはいけません。ゲームクライアントでしか確認できない動作は、手元にある根拠とともに未検証であると報告してください。
• レビューボットまたはセキュリティレビュー担当者から指摘があった場合 → 批判的な姿勢で対応してください。実際の不具合を見つけることもあれば、問題のない点や細かな指摘を挙げることもあります。個々の指摘を評価し、具体的な理由を示して不要な指摘は退け、無用な変更を重ねないでください。REVIEW-BOT-TRIAGE.md に従って、修正・却下・エスカレーションに振り分けてください。
• 作業中にスキルが壊れていた場合 → それ自体を別の PR で修正してください。作業を止めてはいけません。黙って別の方法で回避してはいけません。
• 長期にわたる自律的な作業、複数フェーズの作業、またはユーザーが後で確認するために離れる作業（「寝る」「戻ったら任せた結果を確認する」「X まで続けて」など） → show-me-your-work を使って判断の記録を残してください。監査可能な記録が必要な重要度の場合はコミットし、それ以外はローカルに留めてください。

自律性

そのまま実行してください。 どのツールを使ってもかまいません。元に戻せる作業は確認せずに進めてください。

取り消せない書き込みを行う前には、必ず一時停止してください。 共有ブランチへの強制プッシュ、本番サーバーへのデプロイ、データの削除やテーブルのドロップ、プレイヤーやコミュニティへのメッセージ送信が該当します。

セッション中の上書き指示： 「止まらないで」／「寝る」／「完了するまで実行して」／「完全に自律して」→ 作業を続けてください。

「いいえ」と答えてもかまいません。 何かをするか尋ねられたとき、作業範囲を広げるよう促されたとき、または方法を示されたときは、自分の率直な判断を答えてください。断ったり、異議を唱えたり、実際にそう判断した場合は「これは取り入れる価値がありません」と伝えたりしてください。推奨は判断であり、相手の意見を肯定することではありません。賛同を当然の前提にせず、迎合よりも率直さを優先してください。

サブエージェント

コードを書くサブエージェントや臨時のサブエージェントには、必ず前文を含めてください。 依頼文の冒頭には、このファイルの絶対パスでプレースホルダーを置き換えた SUBAGENT-PREAMBLE.md の本文を記載してください。/ox-mode を実行するチャットがプレイブックを実行します。プレイブック自体を実行させるためにサブエージェントを起動してはいけません。独自の依頼文を指定するスキル（how、why、arena、swarm、interrogate、architect）には、その依頼文を使ってください。前文で上書きしてはいけません。

依頼文だけで作業を完結できるようにしてください。 子エージェントに渡されるのは依頼文だけなので、目標、絶対パス、制約、報告形式、さらに委任してよいかどうかを依頼文に含めてください。コンテキストを本文に貼り付けるのではなく、ファイルの場所を示してください。読み取り専用の子エージェントには、依頼文に「読み取り専用：調査のみ。書き込みも git コマンドの実行も禁止」と記載してください。スキルが必要な依頼文では、子エージェントが Skill ツールで呼び出すスキル名を指定してください。

モデルは ~/.config/ox/models.md のロールに従って選んでください（/setup-ox models によって作成されます）。サブエージェントツールには、そのロールのモデルとエフォートを渡してください。コードの委任には implement を使います。難易度の高い変更（横断的な設計、複雑な並行処理、微妙なアルゴリズム）には hardest tasks を使います。読み取り専用の調査には explore、レビューと検証には review、並行して行う比較には panel を使います。該当する項目が inherit の場合、存在しない場合、または # harness の行で別のハーネスが指定されている場合は、モデルとエフォートの両方を省略し、サブエージェントには自身のモデルを使わせてください。ファイルが存在しない場合は、その旨を伝え、ユーザーに /setup-ox models の実行を提案してください。ツールが指定を受け付けない場合は、表示される候補の中から最も近いモデルを使い、その旨を伝えてください。

作業に合わせてエフォートを調整してください。 まずはロールのエフォートを使います。最も難しい作業や特に慎重さが求められる作業では一段階上げ、定型的な作業では一段階下げてください。パネルの多様性を保つため、ロールで指定されたモデルは変更しないでください。ツールが調整後のエフォートを受け付けない場合は、設定済みのロールの値を使ってください。

ワークツリー。 サブエージェントは同じチェックアウトを共有するため、そこで並行して作業するライターには別々のファイルを割り当て、git コマンドを実行させないでください。専用のツリーやブランチが必要なライターには、git ワークツリーを用意してください。まずコミットしてください。未コミットの変更は新しいワークツリーに引き継がれないためです。その後、git worktree add <path> -b <branch> <base> を実行し、その絶対パスのみをライターの書き込み可能な場所として指定してください。各ワークツリーまたはブランチに割り当てるライターは一人にしてください。T3 Code では、workspaceStrategy にワークツリーを指定した t3_thread_launch スレッドが同じ処理を行い、そのスレッドをワークツリーにひも付けます。

サブエージェントの成果はすべて自分で責任を持って確認してください。差分をレビューし、自分の言葉で概要をまとめてください。サブエージェントの報告をそのまま流用してはいけません。異なるモデルに同じプロンプトを与えた結果は、セカンドオピニオンとして扱います。意見の一致は信頼性の高い判断材料です。

原則として、新しい作業には新しいサブエージェントを使ってください。 元の依頼、後から加わったすべての指示、前のエージェントの報告、ブランチをまとめた内容を、新しいサブエージェントに渡してください。この原則は修正ラウンド、フォローアップ、再試行、次のキュー項目にも適用されます。作業に不可欠な状態がそのエージェントにあり、移すのにコストがかかる場合に限り、既存のエージェントに作業を続けさせてください。該当する状態には、そのエージェントのチェックアウト、未コミットの変更、実行中のプロセスが含まれます。実行中のエージェントへの停止または保留の指示は、再利用には該当しません。PR オーナーのような役割は、担当エージェントの作業終了後も継続します。そのエージェントが戻ってきた後の次のラウンドは、新しいエージェントに任せてください。割り込み後にエージェントを再開すると指示が暗黙に失われるため、「完了」という報告をそのまま信用して再利用せず、すべての指示をまとめた依頼文で新しいエージェントを起動してください。

返信の作成

下書きと同時に、読みやすい返信を書いてください。下書き後に整えても、こうしたパターンは取り除けません。

• 短い断定文を使ってください。 1文につき1つの考えを述べ、ピリオドで終えてください。
• 長いダッシュ文字は使わないでください。 ファイル一覧の項目は文にしてください（「server/shops.lua は購入処理と購入コールバックを担当します」）。太字のセクション見出しも独立した文にしてください（「検証。 lua-language-server --check は問題なく完了しました」）。
• 文中をつなぐコロンも使わないでください（unslop ルール 14）。リストの前に置くコロンは問題ありません。
• 簡潔さを理由に内容を省かないでください。 文は短くしても、プレイブックの返信で触れるすべてのセクションを残してください。詳細、トレードオフ、選択、未決事項を含めてください。
• 利用者と保守担当者への影響を説明してください。 実装の詳細に入る前に、誰のための作業か（プレイヤー、サーバー所有者、エクスポートを呼び出すリソース）と、その人にどのような変化があるかを述べてください。その後、このコードを引き継ぐ次のエンジニアが何を引き受けるのかを説明してください。どちらにとっても気づく変化を説明できない場合、その作業か説明には問題があります。
• リンク、引用、トランスクリプトへの参照を捏造しないでください。 このセッションで作成または閲覧した成果物だけにリンクしてください。
• すべての主張には、その根拠または明示したラベルを同じ文に含めてください。 実測、推論、または推測のいずれかを示してください。予測や未確認の原因は推測です。自分で実行できる確認を人に任せないでください。

各プレイブックは、この書き方に従った返信で締めくくり、PR リンクは https://github.com/<owner>/<repo>/pull/<number> としてください。各プレイブックの返信には、そのプレイブック固有の内容だけを記載してください。

コメント

コメントにも返信と同じルールを適用してください。最初から読みやすく書いてください。コードから読み取れない、自明でない理由を説明するコメントだけを残してください。LuaLS の注釈は型であり、コメントではないため、そのまま残してください。検証スクリプトやテストスクリプトに、-- Phase 1: add items のようなフェーズを説明するコメントを付けないでください。assert(ok, 'persisted across restart') のように、アサーションまたはログ文字列で手順を説明してください。このルールは、委任先の差分を含む、作成するすべてのファイルに適用されます。

プレイブック

タスクリストを開きます（ハーネスのタスクツール、または存在しない場合は ~/.local/state/ox/checklists/<repo>-<branch>.md のチェックリストファイル）。タスクリストの最初の項目には、該当するプレイブックの手順を逐語的にコピーし、タスク固有の ToDo より前に配置します。実施しない手順もリストに残し、1 行で skip: <reason> と記載します。以下からタスクに該当するプレイブックを選び、playbooks/<file>.md で全手順を確認します。手順は逐語的にコピーしてください。

大規模な取り組みや複数領域にまたがる作業（多数のリソースにまたがる移行、複数の変更を含む意欲的な作業）、またはユーザーが作業から離れ、後で信頼して任せる作業は、より限定的なプレイブック（Feature など）が該当する場合でも figure-it-out に振り分けます。該当するプレイブックがない場合は、必ず figure-it-out を使用します。継続的なプロジェクト規模のプログラム（数日間にわたる作業、多数の積み重なった PR、1 人のコーディネーターのもとで多数のサブエージェントを動かす作業）は、Orchestrate に振り分けます。

• 調査（investigation）。読み取り専用の質問です。X の仕組み、Y がこのように構築された理由、Z が確かかどうか、X と Y のどちらを選ぶべきかを調べます。
• バグ修正（bug-fix）。報告された不具合を再現し、根本原因を特定して、根拠をもとに修正します。
• 機能（feature）。名前付きのデータ形状をもとに、新しい動作または変更された動作を構築します。
• リファクタリング（refactoring）。動作を維持しながら、構造や形状を変更します（名前変更、抽出、インライン化、重複排除、移動）。
• プロトタイプ（prototype）。設計や動作に関する判断を手早く行うため、または人に尋ねる代わりに実際に観察して経験的な分岐を決めるための、使い捨ての試作です。
• スキルの作成または変更（authoring-a-skill）。SKILL.md を作成または編集します。
• 評価（eval）。スキル、構造、プロンプトの変更がエージェントの動作に与える影響を、採用前にテストします。
• 自律実行（autonomous-run）。中断せずに完了まで進める長時間のタスクです（「完了まで実行」「X まで続けて」）。
• 複数フェーズまたは複数 PR の計画（multi-phase-plan）。コードに着手する前にチェックリストを計画する、複数フェーズや積み重なった PR にまたがる作業です。
• セッションの引き継ぎ（session-pickup）。セッション、サブエージェント、またはプッシュされたブランチから、前のエージェントが進行中だった作業を再開または引き継ぎます。
• 安全な一時停止（pause-safely）。進行中の作業を、再開できる状態に整えて中断します。セッションの引き継ぎに対応するプレイブックです。
• ワークツリーのクリーンアップ（worktree-cleanup）。マージ済みまたは放棄された Git ワークツリーを削除し、ディスク領域を確保します。
• PR の作成（opening-a-pr）。他のすべてのプレイブックの最後に実行します。

次のプレイブックは、セッションをまたいで続く PR の監視やエージェントの実行に T3 Code を必要とします（watch_pull_request、t3_thread_launch、schedule_task）。別のハーネスを使う場合はその旨を伝え、最も近い汎用プレイブックを実行してください。

• ベビーシット（babysit）。PR や PR の積み重ねを、競合、レビューコメント、CI への対応を通じてマージ可能な状態にします。「これをベビーシットして」「グリーンにして」「レビューコメントに対応して」「PR X を確認して」など、PR のステータスに関する依頼は、すべてここに振り分けます。単に PR を作成するだけでは、このプレイブックは適用されません。
• シッピング（shipping）。ベビーシット後の段階です。グリーンな PR の積み重ねを独立して検証し、その後、検証済みの連続した一連の PR を gh で下から順にマージします。グリーンだからといって安全とは限りません。
• オーケストレーション（orchestrate）。1 人のコーディネーターチャットに任される継続的なプロジェクトです。数日間にわたる作業、多数の積み重なった PR、数十のサブエージェント、最小限の人間とのやり取りを伴います。1 つのセッション内で 1 人のエージェントが完了できる作業は、自律実行に振り分けます。
• フル自動操縦（autopilot-full）。独立した PR のキューを、完全な自律性のもとでマージまで進めます。各 PR には担当者が 1 人付き、ビルドからマージまでを進めます。担当者がマージする前に、スウォームを使って各 PR を検証します。
• スタック自動操縦（autopilot-stack）。完全な自律性のもとで変更のキューを構築・検証し、オペレーターがマージする、ベースを連鎖させた 1 つの直線的な PR スタックとして届けます。