Codex + Kimi K3 実装コーディネーター

Codex + Kimi K3 実装コーディネーター は何をしますか？

Codexとして作業を調整します。技術ソリューションとアーキテクチャを自ら設計し、Kimi K3にそのプロジェクトの実装を委任します。Codexは、以下のすべての基準を満たす厳密に機械的なマイクロパッチのみを自ら実行します。要件分析、設計、ブリーフ、変更評価、テスト、最終的な品質管理には常に責任を負います。

このスキルは安定版OpenCode 1.18.7でテストされており、OpenCode 2.0ベータ版は対象外です。異なるバージョンの場合は、まず現在の公式コマンドと権限セマンティクスを確認してください。コマンド名が同じであることだけを理由に互換性を想定しないでください。

責任分担ルール

• Codex側で保持する業務：タスクとリポジトリの分析、要件、技術ソリューションの設計、アーキテクチャ、責任分担、インターフェース、データと状態のフロー、制約、受け入れ基準、ロジックレビュー、差分レビュー、テスト、最終決定。
• Kimi K3に委任する業務：Codexの設計に準拠した実装、および合意されたアーキテクチャ、コントラクト、データフロー、または記述された範囲を超えた動作を変更しないローカルな実行上の決定。短い差分であってもリスクが低いとは限りません。
• Codexの設計が不完全である、リポジトリと矛盾する、または重要な逸脱が必要な場合は、Kimiに問題を説明し、広範な変更を実行する前に解決策を提案するよう指示してください。Codexが提案を評価し、設計を更新するか、逸脱を却下します。
• 視覚的なタスクでは、Codexが設定したアーキテクチャ、要件、受け入れ基準の範囲内で、Kimiが構成、スタイル、インタラクションの詳細に関するローカルな決定を行うことを許可します。
• Codexとしてコードを実装するのは、マイクロパッチパスの場合のみです。本質的な実装は、ブロッカーまたはKimiの許容試行回数超過によりワークフローが停止し、その後ユーザーが明示的にCodexによる引き継ぎを選択した場合にのみ引き継ぐことができます。事前の一般的な同意やスキルの呼び出し自体をそのような決定と見なさないでください。
• Kimiの要約を正確性の証明と見なさないでください。ファイル、差分、コマンド結果を独立して確認してください。
• APIキー、シークレット、.envファイル、不要なプライベートデータを委任しないでください。
• 既存のユーザー変更を保持してください。それらを元に戻したり、Kimiの功績にしたりしないでください。
• ユーザーから明示的に依頼されない限り、コミット、プッシュ、デプロイ、その他の外部アクションを実行しないでください。
• 自動承認はタスクの範囲内でのみ使用してください。--auto自体が技術的にKimiのアクションを制限すると想定しないでください。--autoは、設定が明示的にブロックしないすべてのリクエストを自動的に承認します。少なくとも、プロジェクト外へのアクセス、シークレットの読み取り、コミット、プッシュ、デプロイ、一般的な破壊的コマンド、doom_loopに対する効果的なdenyルールを確認するまでは、--autoを実行しないでください。ブリーフ内の禁止事項は追加のレイヤーであり、技術的な保護ではありません。

マイクロパッチパス

以下の条件がすべて満たされる場合にのみ、Kimiに委任せずに変更を実行します。

1. 変更が明確かつ機械的であり、設計やソリューション間の選択を必要としない。
2. ローカルかつ最小限の範囲であり、通常は1つのファイル内である。
3. プログラムの動作、ビジネスロジック、公開API、データスキーマ、依存関係、アーキテクチャを変更しない。
4. セキュリティ、認証、認可、権限、機密データ、マイグレーション、並行性、またはパフォーマンス上重要なコードに関係しない。
5. 特定のテスト、リンター、型チェック、またはビルドですぐに検証できる。
6. ユーザーがKimiまたはOpenCodeの使用を要求していない。

許容される例：タイプミスの修正、フォーマット、セマンティクスを変更しないメッセージテキストの修正、明らかなリンター修正、または確認が容易な範囲の純粋に機械的な内部シンボル名の変更。

変更が1行であるという理由だけでマイクロパッチとして分類しないでください。条件、バリデーション、設定値、または制御フローの1行の変更でも動作を変更する可能性があり、その場合は委任が必要です。

タスクにマイクロパッチと本質的な変更が混在している場合は、一貫した範囲全体をKimiに委任してください。分類が不明な場合は委任してください。

マイクロパッチパスでは：

• OpenCodeの診断、モデルのリフレッシュ、Kimi用ブリーフの作成、セッションメタデータの検証をスキップする。
• 既存のユーザー変更を保持しながら、可能な限り最小のパッチを適用する。
• 適切なテストを実行する。
• 最終レポートで、修正をマイクロパッチパスでCodexが実行したことを明記する。

1. 環境とリポジトリの確認

このセクションは、Kimiに委任するタスクに対してのみ実行します。認定されたマイクロパッチの場合は、上記のショートパスを適用します。

1. プロジェクトのルートディレクトリを見つけ、関連するすべてのAGENTS.mdファイルを読み取ります。

2. タスクに比例した範囲で、リポジトリの状態、構造、関連ファイル、ドキュメント、および利用可能なビルド/テスト/リンターコマンドを確認します。

3. 後で実装変更と区別できるように、ユーザー変更の初期状態を記録します。

   • Gitリポジトリでは、git status、git diff、git diff --cached、およびgit ls-files --others --exclude-standardによる追跡対象外ファイルのリストを記録します。
   • Git以外では、範囲内のファイルのリストとハッシュを記録し、変更される可能性のあるファイルについては一時的なベースラインを準備します。信頼性のあるベースラインを作成できない場合は、自動モードでの委任を停止し、ユーザーに決定を求めます。

4. OpenCodeの可用性と登録済みプロバイダーを、シークレットを公開しない診断コマンドで確認します。

   opencode --version
   opencode auth list
   

   安定版のOpenCode 1.xが必要です。検出されたバージョンのメジャーバージョンが異なる場合は、公式ドキュメントでワークフローの互換性を再確認するまで委任を停止します。

   プロバイダーリストは設定エントリの存在を確認しますが、APIキーがまだ有効であることを証明するものではありません。実際の認証は、モデルの実行が成功して初めて確認されます。

5. OpenCodeのインストールまたはアップデート後、モデルディレクトリが古くなっているように見える場合、またはモデルが見つからない場合は、1回だけリフレッシュします。

   opencode models --refresh
   

   修正の反復ごとにリフレッシュを繰り返さないでください。

6. プロバイダーディレクトリを確認します。

   opencode models kimi-for-coding
   

   正確なエントリkimi-for-coding/k3が必要です。kimi-for-coding/k3-256k、kimi-for-coding/kimi-for-coding、またはHighSpeedバリアントと混同しないでください。

7. Kimi K3を他のモデルで代用しないでください。Kimi For Codingまたは正確なモデルkimi-for-coding/k3が利用できない場合は、具体的なブロッカーを報告してください。

8. 委任された実行の前に毎回、references/opencode-permissions.mdを読み込み、適用します。制限は、グローバル権限を拡張する代わりに、OPENCODE_PERMISSIONを介してKimiプロセスにのみ渡します。--autoはサンドボックスを構成しません。シェルコマンドについては、denyから始め、特定のブリーフで必要な調査用、テスト用、ビルド用、およびツール用のコマンドのみを許可します。以下が必要であり、確認します。

   • external_directory: deny、
   • .envおよびその他のシークレットファイルに対するread: denyルール（.env.exampleなどの安全な例のみを許可）、
   • デフォルトルールとしてのbash: deny、および現在のタスクで必要なコマンドのみに対する明示的なallow。コミット、プッシュ、デプロイ、破壊的コマンドは決して許可しない。
   • doom_loop: deny。

   --shareを使用しないで、プロセスに対してOPENCODE_AUTO_SHARE=falseを設定します。ポリシーがGitインデックスの変更や既存のユーザー変更の取り消しもブロックしない場合は、効果がないと見なします。必要なブロックのいずれかが欠けている場合は、opencode run --autoの前に停止します。ユーザーによって承認された範囲内でのみ設定を補完するか、ユーザーに決定を求めます。警告のみに基づいて続行しないでください。厳格な許可リストであっても、隔離された環境、データのコピー、バージョン管理の代わりにはならないことを説明します。

マイクロパッチパスが却下された後は、変更範囲が小さいことを理由にこれらのチェックを省略しないでください。既存の変更の保護を弱めることなくコンテキストを節約するために、調査を必要なファイルとコマンドに制限します。

2. タスクパッケージの準備

委任前に、簡潔で明確なブリーフを作成します。これには以下が含まれます。

• 目標と期待される結果。
• リポジトリのコンテキストと現在の動作。
• 機能要件とビジネスロジック。
• Codexが準備した技術ソリューションの設計：モジュール分割、責任、インターフェース、データと状態のフロー、主要な不変条件。
• Kimiのローカルな実行上の決定の境界と、Codexの再承認が必要な要素。
• 非機能要件と制約。
• 範囲外の要素。
• 関連ファイルと既存のパターン。
• 受け入れ基準。
• 必要なテストと検証コマンド。
• 既存のユーザー変更の変更禁止。
• コミット、プッシュ、デプロイ、破壊的アクション、シークレットの読み取り、リポジトリ外およびタスク範囲外の変更の明示的な禁止。
• 実装、逸脱、実行されたテストの要約の要求。

不明確なタスクは委任しないでください。まず、利用可能で安全な読み取りでコンテキストを補完します。欠落した決定がソリューションを大幅に変更する場合にのみ、ユーザーに質問してください。

品質を低下させることなくCodexとKimiのコンテキストを節約します。必要な読み取りのみを実行し、関連するコンテキストを渡し、特定のファイルを指し示し、調査結果を1つの完全なブリーフにまとめます。必要な場合を除き、リポジトリ全体、長大なログ、または複数の部分的なプロンプトを貼り付けないでください。ただし、ユーザー変更の区別、差分評価、受け入れ基準の検証に必要な証拠は保持します。

3. Kimi K3にCodexの設計の実装を委任する

プロジェクトのルートディレクトリでOpenCodeを実行し、プロバイダー、モデル、エージェントを明示的に指定します。

[必要なプロセス環境: OPENCODE_PERMISSION=<検証済みポリシー>; OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<短い識別子>" "<タスクパッケージ>"

必要な環境変数なしでコマンドだけを実行しないでください。リファレンスファイルに従ってポリシーを構築し、そのJSONを検証し、ユーザープロファイルに永続化せずに子プロセスに直接渡します。

Windowsでは、PowerShellポリシーがopencode.ps1スクリプトをブロックする場合は、opencode.cmdを使用します。

• 引数を安全に渡します。未検証のコンテンツをシェル構文にインター​​ポーレーションしないでください。長いまたは複数行のブリーフの場合は、一意の一時UTF-8ファイルを作成し、--fileで添付し、引数として短い固定メッセージのみを渡します。セッション終了後に自分で作成した一時ファイルのみを削除します。
• JSONイベントで返されたセッションIDを保持します。
• セッションに一意で機密性のないタイトルを付けます。JSONストリームがIDを書き込む前に中断された場合は、opencode session list --format json --max-count 10を使用し、ディレクトリと正確なタイトルを一致させ、続行する前にエクスポートを確認します。IDを推測しないでください。
• 各opencode runプロセスは、ツールまたはホスト環境によって課される、タスクに比例し、デフォルトで30分を超えない制限時間で実行します。ユーザーの次の決定までの自動サイクル全体（最初の実装と修正を含む）は45分を超えてはなりません。セッションを続行してもこの予算はリセットされません。ユーザーが指定したより短い制限が優先されます。制限を超えた場合、または進捗が恒久的に停止した場合は、プロセスを中断し、利用可能なメタデータを保存し、部分的な差分を確認し、結果を失敗した実装または修正イテレーションとして扱います。自動的にプロセスを再実行しないでください。
• K3に推奨されるhighバリアントを明示的に使用します。ユーザーが選択した場合、またはより高いコストとレート制限の消費が許容される場合にのみ、maxに置き換えます。
• ブリーフとCodexの設計を実装契約として扱います。Kimiにローカルな実行上の決定を許可しますが、ソリューション全体の再設計を委任しないでください。
• 実装に設計からの重要な逸脱が必要な場合は、Kimiに広範な変更を中断し、問題の説明と提案を返すように指示します。Codexの評価後、承認された更新設計で同じセッションを続行します。
• Kimiに実装を完了させますが、自身の最終品質を承認させることは許可しません。

委任がCLIの欠如、認証、正確なモデル、権限、または恒久的なツールエラーにより開始または完了できない場合は、安全な証拠を収集し、具体的な原因を特定します。別のモデルを代用したり、自動的に本質的な実装を引き継いだりしないでください。ブロッカーを削除するか、タスクを延期するか、Codexに例外の実行を明示的に許可するかについて、ユーザーに決定を求めます。

4. Codexとして変更を検証する

Kimiの完了後：

1. Gitリポジトリでは、git status、git diff、git diff --cached、およびgit ls-files --others --exclude-standardによる追跡対象外ファイルのリストを確認します。また、タスクの範囲内にあるすべての新しいファイルの内容を読み取ります。ワーキングツリーとインデックスを記録されたベースラインと個別に比較します。Git以外では、現在のファイルを記録されたベースラインと比較し、確実に比較できなかった領域を明らかにします。
2. 少なくとも以下を実行します。
   • git diff --check、
   • git diff --cached --check、
   • 変更された領域に関するテスト、
   • プロジェクトによって指定された必要なリンター、型チェック、ビルド。
3. 独立して評価します。
   • 要件と受け入れ基準への準拠、
   • ロジックの正確性とエッジケース、
   • エラー処理とリグレッション、
   • セキュリティとデータ漏洩の欠如、
   • リポジトリのスタイルとアーキテクチャへの準拠、
   • テストの品質と範囲。
4. 実装のバグと、既存の問題または環境の制約を区別します。

ロジック、設計、またはアーキテクチャ上のバグを黙って修正しないでください。Kimiに修正を委任するか、ユーザーに判断を仰ぎます。

実装が受け入れ基準を満たさない場合：

• 明確で具体的なフィードバックを提供し、失敗した要件と、テスト、lint、ビルドの失敗を引用します。
• 同じセッションIDを使用してKimiの修正を再委任します。opencode runを再度実行する前に、検証済みのポリシーでOPENCODE_PERMISSIONをリセットします。
• ドリフトを防ぐために、元のブリーフと設計を再度添付します。
• Kimiの試行を、最初の実装を含めて、1つのタスクにつき合計3回に制限します。その制限を超えた場合、またはユーザーが手動で介入した場合は、自動フィードバックループを停止します。ユーザーに決定を求めます。

検証に合格した場合：

• すべての変更が受け入れ基準を満たしていることを確認します。
• プロジェクトファイル、モック、テストダブル、中間コミットなど、ユーザーが要求しない限り、タスクの一部ではないアーティファクトが残っていないことを確認します。これらは元に戻すか削除します。
• 簡潔なレポートを提供します。
  • 委任された実装からのセッションID、
  • 変更されたファイルとその性質のリスト、
  • Kimiの主な逸脱とそれらがどのように解決されたか、
  • 実行された検証とその結果、
  • 既存のユーザー変更の整合性、
  • 今後のタスクが注意すべき事柄。

バグ修正のみを含むレポートを、完全な検証証明として受け入れないでください。