ce-work

作業実行コマンド

成果

• 結果： 計画、仕様、または具体的な作業指示に基づき、実装が完了し、ローカルで検証済みの変更一式です。
• 次の利用者： 単独で使用する場合、リリースワークフローが検証済みの変更をレビューとリリースに進めます。呼び出し元への返却モードでは、呼び出し元のワークフローが構造化された実装と検証結果を受け取り、残りのゲートを担当します。
• 完了条件： 対象範囲内のすべてのタスクが完了し、必要な検証の証跡が記録され、関連するチェックに合格していること。また、実行が、担当するリリースへの引き継ぎ（コードレビューの受領記録または明示的なスキップフレーズを含む。Phase 3-4 を参照）、完全な返却結果、または明示的なブロッカーのいずれかに到達していること。
• 目的： 計画の再交渉や、正式な統合権限の移譲を行わずに、依頼された機能を仕上げます。ワーカーには範囲を限定した作業単位を割り当て、ホストオーケストレーターが実際の変更を確認し、正式な検証と正式なコミットを担当します。

実行ワークフロー

バンドルされた参照ファイルは、推測で補わず、必ず読むこと。 以下で指定されている各参照ファイルまたはスクリプトのパスは、このスキルの読み込み済み SKILL.md ディレクトリを起点に解決してください。その際、ハーネスから渡されたスキルの完全パスを使用し、バンドルファイルを探すために対象リポジトリを glob してはいけません。各参照ファイルは、その参照が適用されるフェーズに入るときに読んでください。それより前に読んでいても、要件を満たしたことにはなりません。このファイルで再読するよう指定されている参照ファイルは、すでにコンテキストに含まれていても、該当する手順で再度読んでください。ハーネスがスキルディレクトリを公開していない場合、または必要なファイルを読めない場合は、そのファイルが適用される操作を行う前に停止し、見つからないファイルを報告してください。記憶からルールを再構成してはいけません。ネイティブに処理を続けず、参照ファイルが見つからないことを報告してください。

Phase 0：入力のトリアージ

まず、再開要求の有無を確認してください。 入力を計画、パス、空白、または単独の指示として分類する前に、既存の実行の再開、調査、回収、またはクリーンアップの要求を認識してください。再開処理では、新しいワーカーの起動、新しいルートの選択、別の計画の探索、完了済み検証の再実行、いずれかのリリースパスへの移行を行ってはいけません。実行 ID がない場合はユーザーに尋ねてください。推測してはいけません。

ほかの入力を判断する前に、references/input-triage.md を読んでください。このファイルでは、ソースの解決、制御トークン、再開処理、読み取り専用の探索、計画の準備状況、コード以外へのルーティング、空白入力、単独の指示の規模判定を定めています。ここでは、次の 3 つのルールが適用されます。

• 単独の指示が「軽微」に該当する場合（ファイルが 1～2 個で、動作変更がない場合）、タスクリストは省略しますが、書き込みの前に実行エンジンを解決する必要があります。完全に機械的な差分も、PR 後の監視なしでリリースします。いずれかが不確かな場合は、より詳細な手順を選んでください。
• このセッションですでに ce-plan が規模を判定した単独の指示は、再度計画せずに実行してください。ユーザーの判断が必要な事項は、ce-plan や ce-brainstorm に戻るルートとしてではなく、質問として尋ねてください。
• この参照ファイルを読めない場合は停止してください。制御トークンや実行可能でない成果物を、コード作業として扱ってはいけません。

トリアージで呼び出し元への返却モードが選ばれた場合は、直ちに references/return-to-caller.md を読み、この実行の終了方法を定めるファイルとして記録してください。読めない場合は、変更を加える前に停止してください。単独実行時の動作に切り替えてはいけません。

フェーズ 1：クイックスタート

1. ワークスペースを確立します。 ブランチの切り替え、編集、作業の割り当て、コミットを行う前に、references/workspace-setup.md を読みます。書き込み可能なチェックアウト、計画の明確化、ブランチの配置、作業前のインベントリ、すでに変更されているファイル、タスクのセットアップを決定します。書き込み可能な正規のチェックアウトがない状態では決して書き込みを行わず、このセッションでユーザーが明示的に指示した場合を除き、実際のデフォルトブランチには決して書き込まないでください。

   ユーザーが提供していないものをコミットしたり公開したりしないでください。 ある単位で、すでに変更されているファイルが必要な場合、スタンドアロンモードでは、そのファイルを含めるか除外するかを一度だけ尋ねます。Return-to-Caller Mode では質問も編集も行わず、競合の内容と解消方法を示してブロック状態を返します。

2. エンジンを解決してから、戦略を決定します。 計画の取り込みを限定的に行い、タスクを導出した後、実行する単位の選択、書き込み、作業の割り当て、コミットを行う前に、references/execution-engines.md を読み、そのルート選択を完了します。型付きバインディングの有無にかかわらず適用され、ネイティブ実行が適格となるのは、このリファレンスがそれを選択するか、許可されたフォールバックをすべて使い切った場合だけです。エンジンの選択によって、実行の終了方法を定めるリファレンスが変わることはありません。

   クロスモデル実行が選択された場合は、他のモデルにコンテンツや権限を渡す前に、references/cross-model-execution.md を読みます。コントローラーの初期化、初期化後のエンジンロック、制限された外部送信、トランザクション、復旧、受領記録について定めています。

   インライン、逐次、並列のいずれかの実行方法を選ぶ前に、またワーカーを割り当てる前に、references/execution-strategy.md を読みます。スケジューリング、分離、各ワーカーに渡すパケット、ワーカーのライフサイクル、統合を決定します。ホストオーケストレーターは、権威ある検証を維持し、正規のコミットを行います。

フェーズ 2：実行

最初の実装書き込みの前に、Trivial ルートであっても、references/implementation-loop.md を読みます。証拠の選定、検証、単位を終了するタイミング、段階的なコミット、既存のパターンに従うこと、継続的なテスト、簡略化を止める地点、UI 作業、進捗管理、確定した決定について定めています。

このファイルに記載されたコミット規則は、作業全体を通じて適用されます。実装の各コミットでは、その単位が所有するファイルのみを指定してください。単独の git commit はユーザーが事前にステージした内容を取り込む可能性があるため、禁止されています。

フェーズ 3～4：品質チェックと仕上げ作業

タスクとローカル検証が完了した後、スタンドアロンモードでは、品質チェックまたは納品の前に references/shipping-workflow.md を読みます。簡略化、コードレビューの受領記録とフォールバック、未解決の指摘、最終検証、納品について定めています。

コードレビュー完了ゲート（スタンドアロンモードのみ）。 納品前にコードレビューを実際に行う必要があります。納品用リファレンスに、完了した ce-code-review の受領記録、またはそのリファレンスで正確に許可されたスキップ状態のいずれかが記録されるまで、実行は完了しておらず、コミットまたは納品スキルを呼び出してはならず、納品が完了したと報告してはなりません。頭の中で行う自己レビューや、以前に適用済みの指摘で代用してはなりません。この規則は Return-to-Caller Mode には適用されません。

呼び出し元へ返すモード

呼び出し元へ返すモードでは、実装とローカルでの検証のみを行います。Phase 3-4 に進んだり、最終的な簡素化、コードレビュー、PR の作成、CI の監視、ベビーシッティング、その他の単独でのリリース作業を実行したりしてはいけません。これらの手順は呼び出し元が担当します。

結果を出力する直前に、references/return-to-caller.md をもう一度読みます。完全な返却結果、証拠がそろっているかの確認、ルートとモデルの記録、復旧の意味、および standalone_shipping_skipped: true を定義するのは、このファイルだけです。このファイルから完全な結果を組み立ててはいけません。

計画または実装によって状態が作成された後に、必須の読み込みに失敗した場合は、変更されたファイル、コミット、ワークスペース、コントローラーレコードをすべて保持します。このファイルに基づく最小限のブロック結果を返します。内容は status: blocked、plan_path、判明している場合は run_id、changed_state、欠落している参照先を示す blockers、および recovery_path です。部分的な状態を消去したり、成功を報告したり、単独でのリリース手順に移行したりしてはいけません。