ce:work

作業実行コマンド

品質を維持しながら、効率よく作業を進め、機能を完成させます。

はじめに

このコマンドは、作業ドキュメント（計画、仕様書、TODO ファイル）または作業内容を記述した簡単なプロンプトを受け取り、体系的に実行します。要件をすばやく理解し、既存のパターンに従い、品質を維持しながら、機能を完成させてリリースすることを重視します。

入力ドキュメント

<input_document> #$ARGUMENTS </input_document>

実行ワークフロー

フェーズ 0：入力のトリアージ

<input_document> の内容に応じて、進め方を判断します。

計画ドキュメント（既存の計画書、仕様書、またはTODOファイルへのファイルパスが入力された場合）→ フェーズ 1 に進みます。

簡単なプロンプト（作業内容の説明であり、ファイルパスではない入力）：

1. 作業領域を調査する

   • プロンプトに基づいて、変更する可能性の高いファイルを特定します
   • 該当領域の既存のテストファイルを見つけます（実装ファイルをインポート、参照している、または名前を共有するテスト／仕様ファイルを検索します）
   • 影響を受ける領域の既存のパターンや規約を確認します

2. 複雑さを評価し、進め方を決める

   複雑さ	判断の目安	対応
   簡単	1～2 ファイルで、動作の変更がない（誤字、設定、名前の変更）	フェーズ 1 のステップ 2（環境設定）に進み、タスクリストや実行ループを設けず、直接実装します。動作に関わるコードに変更を加える場合は、テストの確認を行います
   小～中規模	範囲が明確で、ファイル数が約 10 未満	調査結果をもとにタスクリストを作成し、フェーズ 1 のステップ 2 に進みます
   大規模	複数領域にまたがる、アーキテクチャ上の判断が必要、ファイル数が 10 以上、認証／決済／マイグレーションに関わる	エッジケースや範囲の境界を明確にするため、/ce:brainstorm または /ce:plan の利用が有効であることをユーザーに伝え、希望に従います。続行する場合はタスクリストを作成し、フェーズ 1 のステップ 2 に進みます

---

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

1. 計画を読み、明確にする (フェーズ 0 から簡単なプロンプトで進んだ場合はスキップ)

   • 作業ドキュメントを最後まで読みます
   • 計画は実行手順書ではなく、意思決定の記録として扱います
   • 計画に Implementation Units、Work Breakdown、Requirements Trace、Files、Test Scenarios、Verification などのセクションがあれば、実行の主要な情報源として利用します
   • 各実装単位の Execution note を確認します。これらには、その単位をどのように実行するか（たとえば、テストファーストまたは特性評価ファースト）が記されています。タスクを作成する際に留意してください
   • Deferred to Implementation または Implementation-Time Unknowns セクションがあるか確認します。これらは、実行時に解決するよう計画者が意図的に残した疑問です。作業を始める前に把握し、途中で不意に直面することがないようにしてください
   • Scope Boundaries セクションがあるか確認します。ここには明示的な対象外事項が記されています。実装中に隣接する作業へ範囲が広がりそうになったら、参照してください
   • 計画内で提示されている参考資料やリンクを確認します
   • このセッションでユーザーから TDD、テストファースト、または特性評価ファーストでの実行を明示的に求められた場合は、計画に Execution note がなくてもその要望に従います
   • 不明瞭な点や曖昧な点があれば、ここで確認の質問をします
   • 続行する前に、ユーザーの承認を得ます
   • この手順を省略しないでください。誤ったものを作るより、今の段階で質問するほうがよいでしょう

2. 環境を設定する

   まず、現在のブランチを確認します。

   current_branch=$(git branch --show-current)
   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
   
   # Fallback if remote HEAD isn't set
   if [ -z "$default_branch" ]; then
     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
   fi
   

   すでにフィーチャーブランチにいる場合（デフォルトブランチ以外）：

   まず、ブランチ名に意味があるかを確認します。feat/crowd-sniff や fix/email-validation のような名前は、作業内容を後から読む人に伝えられます。自動生成されたワークツリー名（例：worktree-jolly-beaming-raven）など、内容が不明瞭な名前は該当しません。

   ブランチ名に意味がない場合、または自動生成された名前の場合は、続行する前に名前を変更するよう提案します。

   git branch -m <meaningful-name>
   

   計画のタイトルまたは作業の説明から新しい名前を考えます（例：feat/crowd-sniff）。そのまま続行する方法とあわせて、ブランチ名の変更を推奨案として提示します。 次に、次のように尋ねます：「[current_branch] で作業を続けますか、それとも新しいブランチを作成しますか？」

   • 続ける場合（名前を変更する場合も含む）は、手順 3 に進みます
   • 新規作成する場合は、以下のオプション A または B に従います

   デフォルトブランチ上にいる場合は、進め方を選択します。

   オプション A：新しいブランチを作成する

   git pull origin [default_branch]
   git checkout -b feature-branch-name
   

   作業内容に基づいた適切な名前を使用します（例：feat/user-authentication、fix/email-validation）。

   オプション B：ワークツリーを使用する（並行開発におすすめ）

   skill: git-worktree
   # The skill will create a new branch from the default branch in an isolated worktree
   

   オプション C：デフォルトブランチで続ける

   • ユーザーによる明示的な確認が必要です
   • ユーザーが「はい、[default_branch] にコミットしてください」と明示的に伝えた後にのみ進めます
   • 明示的な許可なしにデフォルトブランチへ直接コミットしてはいけません

   おすすめ：次の場合はワークツリーを使用します。

   • 複数の機能を同時に開発したい場合
   • 試行錯誤の間、デフォルトブランチをクリーンな状態に保ちたい場合
   • ブランチを頻繁に切り替える予定がある場合

3. Todo リストを作成する (Phase 0 ですでに作成済みの場合、または Phase 0 で Trivial に振り分けられた場合はスキップします)

   • 利用可能なタスク追跡ツール（TodoWrite、タスクリストなど）を使用して、計画を実行可能なタスクに分割します
   • 計画の実装単位、依存関係、ファイル、テスト対象、検証基準からタスクを導き出します
   • Execution note がある場合は、各単位の内容をタスクに引き継ぎます
   • 実装前に各単位の Patterns to follow フィールドを確認します。ここには、参考にする具体的なファイルや規約が示されています
   • 各タスクの完了を判断する主な基準として、その単位の Verification フィールドを使用します
   • 計画に実装コード、細かな手順の TDD 指示、正確なシェルコマンドが含まれているとは限りません
   • タスク間の依存関係を記載します
   • 先に必要な作業を優先します
   • テストと品質チェックのタスクを含めます
   • タスクは具体的で、完了可能なものにします

4. 実行戦略を選択する

   タスクリストを作成した後、計画の規模と依存関係の構造に基づいて実行方法を決定します。

   戦略	使用する状況
   インライン	小規模なタスクが 1～2 件ある場合、または作業中にユーザーとのやり取りが必要なタスクがある場合。指示のみの作業ではデフォルトです。指示のみでは、サブエージェントへの振り分けを正当化できるほど構造化されたコンテキストが得られることはほとんどありません
   直列サブエージェント	相互に依存するタスクが 3 件以上ある場合。各サブエージェントに、1 つの単位に絞った新しいコンテキストウィンドウを割り当てることで、多数のタスクによるコンテキストの劣化を防ぎます。計画単位のメタデータ（Goal、Files、Approach、Test scenarios）が必要です
   並列サブエージェント	以下の並列安全性チェックに合格するタスクが 3 件以上ある場合。独立した単位を同時に実行し、依存する単位は前提条件の完了後に実行します。計画単位のメタデータが必要です

   並列安全性チェック — 並列実行を選択する前に必ず行います。

   1. 候補となる各単位の Files: セクション（作成、変更、テストのパス）から、ファイルと単位の対応表を作成します
   2. 重複がないか確認します。2 つ以上の単位に同じファイルパスが含まれている場合は、重複とみなします
   3. 重複が見つかった場合は、直列サブエージェントに切り替えます。その理由を記録します（例：「単位 2 と 4 で config/routes.rb が重複するため、直列実行を使用」）。直列サブエージェントでもコンテキストウィンドウを分離でき、共有ディレクトリに関するリスクを避けられます

   ファイルの重複がなくても、同じ作業ディレクトリを共有する並列サブエージェントには、git インデックスの競合（同時のステージングやコミットによるインデックスの破損）やテストの干渉（同時実行されたテストが、互いの作業途中の変更を取り込む）が発生する可能性があります。以下の並列サブエージェントに関する制約は、これらのリスクを軽減します。 サブエージェントへの割り当てでは、利用可能なサブエージェントまたはタスクの起動手段を使用します。各ユニットについて、サブエージェントに次の情報を渡します。

   • 全体のコンテキストを把握できる、計画ファイルのフルパス
   • 対象ユニットの Goal、Files、Approach、Execution note、Patterns、Test scenarios、Verification
   • 対象ユニットに関連する、解決済みの保留中の質問
   • テストを作成する前に、対象ユニットのテストシナリオが該当するすべてのカテゴリ（正常系、エッジケース、エラー系、統合）を網羅しているか確認し、不足があれば補足するよう指示

   サブエージェントを並列実行する際の制約 — ユニットを並列で割り当てる場合（直列またはインラインではない場合）：

   • 各サブエージェントに次のように指示します。「ファイルのステージング（git add）、コミットの作成、プロジェクトのテストスイートの実行はしないでください。すべての並列ユニットが完了した後、オーケストレーターがテスト、ステージング、コミットを行います。」
   • これらの制約により、並行するサブエージェント間での Git インデックスの競合やテストの干渉を防ぎます

   **権限モード：**サブエージェントを割り当てる際は、ユーザーが設定した権限が適用されるよう、mode パラメーターを省略します。mode: "auto" は渡さないでください。bypassPermissions などのユーザーレベルの設定が上書きされます。

   直列モードで各サブエージェントの作業完了後：

   1. サブエージェントの差分を確認し、変更がユニットの範囲と Files: の一覧に合致していることを確認します
   2. 関連するテストスイートを実行し、作業ツリーに問題がないことを確認します
   3. テストに失敗した場合は、次に進む前に原因を特定して修正します。問題が残った状態で依存するユニットを割り当てないでください
   4. 計画のチェックボックスとタスクリストを更新します
   5. 次のユニットを割り当てます

   並列サブエージェントのバッチがすべて完了した後：

   1. 現在の並列バッチ内のすべてのサブエージェントが完了するまで待ってから、その結果に対応します
   2. 見つかったファイルの競合を相互確認します。宣言された Files: の一覧だけでなく、バッチ内のすべてのサブエージェントが実際に変更したファイルを比較します。計画時に想定していなかったファイルが作成または変更されることがあります。計画は「何をするか」を記述するものであり、「どのようにするか」を示すものではないため、これは想定内です。同じバッチ内で2つ以上のサブエージェントが同じファイルを変更した場合に限り、競合とみなします。共有作業ディレクトリでは、最後に書き込んだ内容だけが残り、他のユニットによるそのファイルへの変更は失われます。競合が見つかった場合は、まず全ユニットのうち競合していないファイルをすべてコミットし、その後、競合したファイルについて該当ユニットを直列で再実行し、各ユニットがコミット済みの変更を引き継ぐようにします
   3. 完了したユニットごとに、依存関係の順序に従って、差分を確認し、関連するテストスイートを実行し、そのユニットのファイルだけをステージングして、ユニットの Goal に基づく Conventional Commit メッセージでコミットします
   4. ユニットの変更をコミットした後にテストが失敗した場合は、次のユニットをコミットする前に原因を特定して修正します
   5. 計画のチェックボックスとタスクリストを更新します
   6. 次の独立したユニットのバッチ、または次の依存ユニットを割り当てます

フェーズ 2：実行

1. タスク実行ループ

   優先順位に従って各タスクを進めます。

   while (tasks remain):
     - Mark task as in-progress
     - Read any referenced files from the plan or discovered during Phase 0
     - Look for similar patterns in codebase
     - Find existing test files for implementation files being changed (Test Discovery — see below)
     - Implement following existing conventions
     - Add, update, or remove tests to match implementation changes (see Test Discovery below)
     - Run System-Wide Test Check (see below)
     - Run tests after changes
     - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
     - Mark task as completed
     - Evaluate for incremental commit (see below)
   

   ユニットに Execution note がある場合は、その指示に従います。テスト先行のユニットでは、そのユニットの実装に着手する前に失敗するテストを書きます。特性把握先行のユニットでは、変更前に既存の動作を記録します。Execution note のないユニットは、状況に応じて進めます。

   実行時のガードレール：

   • テスト先行で作業する場合、同じステップでテストと実装の両方を書かないでください
   • 修正や機能の実装前に、新しいテストが失敗することを確認する手順を省略しないでください
   • テスト先行で作業する場合、現在の動作範囲を超えて実装しすぎないでください
   • 単純な名前変更、純粋な設定変更、純粋なスタイル変更では、テスト先行の手順は省略してください テストの検出 — ファイルを変更する前に、既存のテストファイルを見つけてください（実装ファイルをインポート、参照しているテスト／スペックファイルや、命名パターンを共有しているファイルを検索します）。計画でテストシナリオやテストファイルが指定されている場合は、まずそれらを確認し、次に計画で挙げられていない追加のテストカバレッジも確認してください。実装ファイルを変更する場合は、対応するテストも更新してください。新しい振る舞いには新しいテストを、変更された振る舞いにはテストの変更を、削除された振る舞いにはテストの削除または更新を行います。

   テストシナリオの網羅性 — 機能を持つユニットのテストを書く前に、計画の Test scenarios がそのユニットに当てはまるすべてのカテゴリを網羅しているか確認してください。カテゴリが欠けている場合や、シナリオが曖昧な場合（入力と期待される結果を示さずに「正しく検証する」など）は、テストを書く前にユニット自体のコンテキストをもとに補足してください。

   カテゴリ	該当する条件	不足している場合の導き方
   正常系	機能を持つユニットでは常に該当します	ユニットの Goal と Approach を読み、主要な入出力の組み合わせを確認します
   エッジケース	ユニットに意味のある境界（入力、状態、並行性）がある場合	境界値、空／nil の入力、並行アクセスのパターンを特定します
   エラー／失敗経路	ユニットに失敗モード（検証、外部呼び出し、権限）がある場合	ユニットが拒否すべき無効な入力、適用すべき権限／認証の拒否、処理すべき下流の失敗を列挙します
   統合	ユニットがレイヤーをまたぐ場合（コールバック、ミドルウェア、複数サービス）	レイヤー間の連鎖を特定し、モックを使わずにそれを実行するシナリオを作成します

   システム全体のテスト確認 — タスクを完了とする前に、立ち止まって次を確認してください。

   質問	対応
   これが実行されると、何が起動しますか？ コールバック、ミドルウェア、オブザーバー、イベントハンドラーなど、変更箇所から2段階先まで追跡します。	実際のコード（ドキュメントではなく）を読み、変更対象のモデルのコールバック、リクエストチェーン内のミドルウェア、after_* フックを確認します。
   テストで実際の連鎖を実行していますか？ すべての依存関係がモックされている場合、テストが証明するのはロジックが 単独で 動作することだけであり、相互作用については何も示しません。	実際のオブジェクトを使い、コールバック／ミドルウェアのチェーン全体を通す統合テストを少なくとも1つ作成します。相互作用するレイヤーにはモックを使いません。
   失敗によって孤立した状態が残る可能性はありますか？ コードが外部サービスを呼び出す前に状態（DB 行、キャッシュ、ファイル）を永続化する場合、サービスが失敗するとどうなりますか？再試行で重複が作られますか？	実際のオブジェクトを使って失敗経路を追跡します。リスクのある呼び出しより先に状態が作られる場合は、失敗時にクリーンアップされること、または再試行が冪等であることをテストします。
   この機能を公開しているほかのインターフェースはありますか？ ミックスイン、DSL、代替のエントリーポイント（Agent、Chat、ChatMethods など）。	関連クラスでメソッド／振る舞いを grep します。同等の対応が必要なら、後回しにせず今追加します。
   エラー処理の方針はレイヤー間で整合していますか？ 再試行ミドルウェア、アプリケーションのフォールバック、フレームワークのエラー処理が競合したり、二重実行を引き起こしたりしていませんか？	各レイヤーの具体的なエラークラスを列挙します。rescue の対象リストが、下位レイヤーで実際に送出されるものと一致していることを確認します。

   省略できる場合： コールバックも状態の永続化も代替インターフェースもない、リーフノードの変更。純粋な追加変更（新しいヘルパーメソッド、新しいビュー部分テンプレートなど）であれば、確認にかかる時間は10秒で、答えが「何も起動しないので省略」になる場合もあります。

   特に重要な場合： コールバックのあるモデル、フォールバック／再試行を伴うエラー処理、または複数のインターフェースから公開される機能に関わる変更。

2. 段階的なコミット

   各タスクの完了後、段階的なコミットを作成するかどうかを検討します。

   コミットするタイミング...	コミットしないタイミング...
   論理的な単位が完了したとき（モデル、サービス、コンポーネント）	より大きな単位の一部にすぎないとき
   テストが成功し、有意な進捗があるとき	テストが失敗しているとき
   コンテキストを切り替える直前（バックエンド → フロントエンド）	振る舞いを伴わない、純粋な足場作りのとき
   リスクが高い、または不確実な変更を試みる直前	「WIP」というコミットメッセージが必要になるとき

   判断の目安：「完全で価値のある変更を説明するコミットメッセージを書けるか？ 書けるならコミットする。メッセージが「WIP」や「Xの一部」になるなら、待つ。」

   計画に実装単位が含まれている場合は、それらをコミットの区切りを決める際の手がかりにします。ただし、実装中に分かったことに応じて調整してください。想定より大きい単位は複数のコミットに分ける必要があるかもしれません。また、関連する小さな単位をまとめてコミットできる場合もあります。各単位の目標を参考にして、コミットメッセージを作成してください。

   コミットのワークフロー：

   # 1. Verify tests pass (use project's test command)
   # Examples: bin/rails test, npm test, pytest, go test, etc.
   
   # 2. Stage only files related to this logical unit (not `git add .`)
   git add <files related to this logical unit>
   
   # 3. Commit with conventional message
   git commit -m "feat(scope): description of this unit"
   

   マージコンフリクトへの対処： リベースやマージ中にコンフリクトが発生した場合は、すぐに解決してください。小さく焦点を絞った段階的なコミットにより、コンフリクトの解決が容易になります。

   注： 段階的なコミットには、帰属情報のフッターを含めない、簡潔な慣例に沿ったメッセージを使用します。最終的な Phase 4 のコミット／PR には、完全な帰属情報を含めます。

   並列サブエージェントモード： 単位を並列サブエージェントで実行する場合、サブエージェントはコミットせず、並列バッチ全体の完了後にオーケストレーターがステージングとコミットを行います（Phase 1 Step 4 の「並列サブエージェントの制約」を参照）。このセクションのコミットに関するガイダンスは、インライン実行と逐次実行、および並列バッチ完了後にオーケストレーターが行うコミットの判断に適用されます。

3. 既存のパターンに従う

   • 計画では類似のコードを参照し、まずそのファイルを読んでください
   • 命名規則に正確に合わせてください
   • 可能な限り既存のコンポーネントを再利用してください
   • プロジェクトのコーディング規約に従ってください（AGENTS.md を参照してください。リポジトリに互換性用の shim が残っている場合に限り、CLAUDE.md を使用してください）
   • 判断に迷った場合は、類似の実装を grep で検索してください

4. 継続的にテストする

   • 重要な変更を加えるたびに、関連するテストを実行してください
   • 最後までテストを待たないでください
   • 失敗はすぐに修正してください
   • 新しい振る舞いにはテストを追加し、変更した振る舞いのテストを更新し、削除した振る舞いのテストを削除してください
   • モックを使ったユニットテストでは、ロジックを分離して検証できます。実オブジェクトを使った統合テストでは、各レイヤーが連携して動作することを検証できます。 コールバック、ミドルウェア、エラー処理に変更を加える場合は、両方が必要です。

5. 作業を進めながらシンプルにする

   関連する実装単位のまとまりを完了した後（または 2～3 単位ごと）に、最近変更したファイルを見直して簡素化できる箇所を探してください。重複するパターンを統合し、共有ヘルパーを抽出して、コードの再利用性と効率を高めます。これは、各エージェントが分離されたコンテキストで作業し、単位をまたいで現れるパターンを見つけられないサブエージェントを使う場合に特に有効です。

   単位ごとに簡素化する必要はありません。初期には重複に見えるパターンが、後の単位では意図的に異なる場合があります。自然なフェーズの区切りを待つか、複雑さが積み重なってきたと感じたときに見直してください。

   /simplify スキルまたは同等のものが利用できる場合は、それを使ってください。そうでない場合は、変更したファイルを自分で見直し、再利用や統合の機会を探してください。

6. Figma デザインとの同期（該当する場合）

   Figma のデザインを伴う UI 作業では：

   • デザイン仕様に従ってコンポーネントを実装してください
   • figma-design-sync エージェントを反復的に使って比較してください
   • 特定された視覚的な差異を修正してください
   • 実装がデザインと一致するまで繰り返してください

7. 進捗を追跡する

   • タスクを完了したら、タスクリストを更新してください
   • 阻害要因や予期しない発見を記録してください
   • 作業範囲が広がった場合は、新しいタスクを作成してください
   • 重要なマイルストーンをユーザーに知らせてください

Phase 3-4: 品質チェックとリリース

Phase 2 のすべてのタスクが完了し、実行が品質チェックに移行したら、リリースのワークフロー全体を確認するために references/shipping-workflow.md を読んでください。内容は品質チェック、コードレビュー、最終検証、PR の作成、通知です。

重要な原則

すばやく開始し、さらにすばやく実行する

• 最初に一度だけ確認を行い、その後は実行に移ります
• 完璧に理解できるまで待たず、質問して先に進みます
• 目標は機能を完成させることであり、完璧なプロセスを作ることではありません

計画を道しるべにする

• 作業ドキュメントでは、類似するコードやパターンを参照します
• 参照先を読み込み、それに従います
• 一から作り直さず、既存のものに合わせます

作業しながらテストする

• 最後ではなく、変更のたびにテストを実行します
• 失敗はすぐに修正します
• 継続的なテストによって、大きな問題を未然に防げます

品質は組み込むもの

• 既存のパターンに従います
• 新しいコードにはテストを書きます
• プッシュする前にリンティングを実行します
• すべての変更をレビューします。単純な追加作業はインラインで、それ以外はすべて完全なレビューを行います

機能を完成させてリリースする

• 次に進む前に、すべてのタスクを完了済みにします
• 機能を80％の状態で放置しません
• リリースできる完成した機能は、完璧でもリリースされない機能に勝ります

避けるべきよくある落とし穴

• 分析のしすぎ — 考えすぎず、計画を読んで実行します
• 確認質問の省略 — 間違ったものを作った後ではなく、今すぐ質問します
• 計画の参照先を無視する — 計画にリンクがあるのには理由があります
• 最後にテストする — 継続的にテストしないと、後で苦労します
• 進捗の記録忘れ — 作業しながらタスクの状況を更新しないと、何が終わったか分からなくなります
• 80％で完了した気になる — 早々に次へ進まず、機能を完成させます
• レビューの省略 — すべての変更をレビューします。変わるのはレビューの深さだけです