execute

実行

実装方法。ドメインスキル（例：「noodle」）とともに読み込みます。このガイドではプロセスを、ドメインスキルではコードベースについて学びます。完全に自律して作業してください。ユーザーに質問してはいけません。作業が完全に終わるまで中断しないでください。

Tasks ですべての作業を追跡してください（TaskCreate、TaskUpdate、TaskList）。分解した変更ごとに 1 つのタスクを作成し、着手時に in_progress、完了時に completed に設定します。

1. 範囲

必要な作業を明確にします。

• 計画フェーズ：brain/plans/ から割り当てられたフェーズを読みます。範囲の境界を把握するため、概要を読みます。プロジェクト固有のコンテキストを確認するため、Skill(backlog) を呼び出します。「Applicable skills」に記載されたドメインスキルを読み込みます。
• バックログ項目：brain/todos.md から todo を読みます。関連する計画があれば、それも読みます。なければ、説明から範囲を定めます。
• 臨時の依頼：ユーザープロンプトを範囲とします。着手前に、影響を受けるファイルとパッケージを特定します。

出力：変更する内容と変更しない内容を明確に区切った説明。

2. 分解

範囲を個別の変更に分けます。各変更は次のとおりです。

• 1 つの関数／型とそのテスト、または 1 つのバグ修正
• 個別にコンパイル可能
• 慣例に沿った 1 つのコミット

変更が 1 つだけの範囲では、分解を省略します。

3. 実装

まずワークツリー — 必須

main 上のファイルを編集してはいけません。 複数のセッションが並行して実行されるため、main の編集はマージの競合や作業の消失につながります。

現在の作業ディレクトリがすでに .worktrees/ 内にある場合は、そこで作業します。それ以外の場合は、noodle worktree create <descriptive-name> を実行します。

絶対パス、または noodle worktree exec <name> <cmd> を使用してください。ワークツリーに cd してはいけません。シェルがその中にいる間にワークツリーが削除されると、セッションが永久に終了します。

ワークツリー内でコミットします。完了したら、noodle worktree merge <name> を実行します。

ユーザーが単一エージェントのセッションを対話的に進め、main の使用を明示的に選んだ場合に限り、省略できます。

委任

• 自分で実行：変更が 1 つだけの場合、または密接に結びついた変更（共有型、逐次的な依存関係）の場合。
• サブエージェント：異なるファイルに触れる、独立した変更が 2 つ以上ある場合。コンテキスト（範囲、関連コード、ドメインスキル名）を事前に伝えます。
• チーム実行：計画に並列化可能なフェーズが 2 つ以上ある場合。references/team-execution.md を参照してください。
• Codex：判断を必要としない機械的な作業（名前変更、定型コード、反復的な編集）。アーキテクチャ上の判断には使ってはいけません。

フェーズが密接に関連している場合は、逐次実行で問題ありません。並列化する前に、次の点を確認します。「あるフェーズの出力が、別のフェーズの入力になるか？」型レベルの契約を共有するフェーズは、逐次実行する必要があります。

4. 検証

コミットする前に、検証スイート全体を実行します。完全なチェックリストは references/verification.md を参照してください。失敗するコードをコミットしてはいけません。失敗した場合は修正し、再検証します。

5. コミット

<type>(<scope>): <description>。必要に応じて、フッターに Refs: #<issue-ID> を追加します。タイプ：feat、fix、refactor、test、docs、chore。論理的な変更ごとに 1 つのコミットを作成します。

6. 引き渡し

すべての変更をコミットし、検証した後、stage_yield を出力します。

noodle event emit --session $NOODLE_SESSION_ID stage_yield --payload '{"message": "Implemented: <brief summary>"}'

これを行わない場合、プロセスが正常終了したときにのみステージが完了します。中断された作業はパイプラインで失われます。

範囲の厳守

• 範囲内の内容だけを変更します。防御的なコード、後方互換性のための回避策、推測に基づく機能を追加してはいけません。
• 範囲外で見つけた問題は品質レビューのメモに記録し、変更しないでください。
• 計画や要件に誤りや不足がある場合は、出力で指摘し、黙って逸脱してはいけません。

原則

実行時に brain/principles/ から読み込みます。

• [[prove-it-works]]
• [[subtract-before-you-add]]
• [[cost-aware-delegation]]
• [[guard-the-context-window]]
• [[boundary-discipline]]
• [[outcome-oriented-execution]]