lite-execute

1 つの計画の実行をオーケストレーションします。アーティファクトを解決または書き込む前に、各取り組みのアーティファクトを .crank/<slug>/ に保管する ARTIFACT-HOME.md を読んでください。

手順

1. 計画を解決します。
2. 完了した各タスクを確認します（計画の状態）。
3. サブエージェントのティアを解決します。
4. Bound を設定し、形状を選びます（Shape）。
5. Pre-flight の行を書き込みます。
6. Bound までタスクループを実行します（Implement）。
7. 次の条件のいずれかに最初に該当した時点で実行を終了します。
   • 未チェックのボックスが残っている：短い実行として終了します。
   • .crank/<slug>/retro.md がすでに存在する：計画が完了したことを報告し、停止します。
   • すべてのボックスにチェックが入っている：Review、Close the loop、Retro を実行します。

計画を解決する

最初に該当する条件を選びます。

1. 明示的なパス：slug は計画の親ディレクトリ名です。タスクリストのないファイル（仕様書、PRD、ブレインストーミングなど）は計画ではありません。その旨を伝え、計画フェーズ（/crank-lite plan …）を推奨して停止します。
2. slug のみ：.crank/<slug>/plan.md に解決します。
3. 引数なし、会話内に計画がある：計画のタイトルから slug を導出し、計画を .crank/<slug>/plan.md に書き込みます。
4. 引数なし、ディスク上に計画が 1 つだけある：確認せずにそれを使います。
5. 引数なし、複数の計画がある：各計画の状態（計画の状態）を示した構造化された質問をして確認します。plan.md のない取り組みのディレクトリは「計画なし」と表示され、実行対象にはなりません。
6. 引数なし、計画がどこにもない：その旨を伝え、計画フェーズを推奨します。

計画の状態

最初に計画の ## Progress ブロックを読みます。[x] の行は完了済みです。その SHA を git log で確認するか、squash または rebase でマージされている場合はコミットの件名を使って（git log --grep）、完了済みタスクをやり直さないでください。どちらの検索でも見つからない完了済みタスクがあれば、実行を停止し、その旨をユーザーに伝えます。

このブロックは計画のタイトルの直下にあります。

## Progress

Base: 9f8e7d6
- [x] Task 1: Add the parser — a1b2c3d
- [ ] Task 2: Wire the CLI flag

• Status はブロックから判定します。not started（ブロックなし）、in progress（未チェックのボックスが残っている）、done（すべて [x]）。
• Grounding は、計画の Grounding: ヘッダーで指定されたファイル、または ## Grounding セクションです。事実ごとに - <claim> | <evidence> | <phase>, <date> の行を 1 つ記載します（ARTIFACT-HOME.md → Grounding）。

計画に Stages テーブルがある場合、ユーザーへのメッセージ内では、すべてのタスク番号にステージを付けます。例：Task 14 (stage 2 of 3)。ステージを完了するタスクには、そのゲートと該当ステージ行の終了状態も記載します。例：Task 18 (stage 2 of 3, gate): <exit state>。進捗行、コミットメッセージ、Pre-flight の行では、タスク番号はそのままにします。

タスクのチェックには、次のうち最初に該当するものを使います。

1. 計画でそのタスクに指定されたチェック。
2. 計画で指定されたゲートコマンド：検証チェック、Gates: ヘッダー、または Grounding に記載されているもの。
3. リポジトリの型チェックと、変更した動作をカバーするテストファイル。そのようなテストがない場合は、変更箇所の境界にテストを追加します。ドキュメントなど、テスト可能な動作がないタスクでは、リポジトリの型チェックまたは lint を使います。

チェックを実行した同じターン内に、その出力を読みます。テスト境界のない変更にはプローブを用意し、その成功出力をチェックとします。

サブエージェントのティア

実行ごとにティアを一度解決します。

1. このセッションですでに読み込まれているユーザー指示（ユーザーレベルおよびプロジェクトレベルの CLAUDE.md / AGENTS.md）でサブエージェントモデルの希望が示されている場合は、それが優先です。以下のフォールバックより弱いモデルが指定されていても、その希望に合わせてティアを割り当てます。すべてのサブエージェント作業を対象とする希望は、実装担当にも適用されます。
2. それ以外の場合は、次のフォールバックを使います。

- **standard** フォールバック（実装担当およびレビュー観点）：Claude Code `model: sonnet` · Codex Luna、高い effort · Cursor Composer - **heavy** フォールバック（敵対的レビューおよびそのマージ）：Claude Code `model: opus` · Codex Sol、高い effort · Cursor Sol、高い effort ## 形状

• 範囲：実行が終了するタスクです。計画の最後のタスク、またはユーザーの依頼で指定されたそれ以前のタスクです（stop at the stage 1 gate は、計画の「Stages」表にあるステージ 1 の最後のタスクを意味します）。「Stages」表だけの場合、範囲は最後のタスクまでです。
• 実行のタスク：範囲までの、未完了の「Progress」行です。

実行のタスクに最初に当てはまる形状を選びます。

1. 単独：実行のタスクが 3 つ以下です。そのため、タスク 10 から再開する 12 タスクの計画や、タスク 1 が完了済みでタスク 2 までを範囲とする計画は、単独です。
2. 並列：タスクが互いに異なるファイルセットを対象とし、チェックを同時に実行できます。
3. 逐次：それ以外のすべての実行です。先行タスクの出力を基にするタスクも含みます。

宣言した形状は実行全体に適用されます。逐次または並列の場合、各タスクの最初のアクションはディスパッチであり、インライン編集ではありません。

ディスパッチと待機

実装担当またはレビュー担当へのディスパッチはすべて、ブロッキング呼び出しです。

• ハーネスがサブエージェントのブロッキング待機を提供する場合は、完了するまで待ちます。
• ハーネスから完了通知を受けて再開する場合は、起動した時点でターンを終了し、通知によって再開されるのを待ちます。
• 結果が同じ呼び出し内で返される場合は、その場で読みます。

完了通知がある場合に限り、ディスパッチが進行中のままターンを終了しても安全です。それ以外のハーネスでは、ターンを終了すると実行が終了します。タイムアウトなど、サブエージェントが戻る前に返される待機結果は、完了を意味しません。その場合は再び待ちます。返答を読むまでは、他の作業を進めず、ディスパッチした作業は担当に任せます。待機中にスリープやポーリングをしたり、自分で同じ作業を行ったりしてはいけません。

停滞時のループ

• 開始条件：ディスパッチが進行中の状態でユーザーメッセージ、またはサブエージェントが返答せずに終了したという通知を受けて再開した場合、そのディスパッチは停滞中です。
• 各回の手順：
  1. そのタスクのファイルについて、git status と git diff を 1 回ずつ実行します。
  2. ハーネスからそのサブエージェントに再接続できる場合は再開します。できない場合は、すでに変更したファイルを Settled: 行に記載して、そのタスクを再度ディスパッチします。
• **終了条件：**ディスパッチから返答があったときです。
• **エスカレーション条件：**同じタスクが 2 度目に停滞した場合は、「寄り道と停止」の規定に従って判断します。

事前確認

再開した実行も含め、呼び出しのたびに以下の行をすべて埋めて記載します。この編集を実行で最初のファイル変更とし、長い実行に入る前に、モデル、形状、範囲をユーザーが確認できるよう、差分を 1 回提示します。

1. 計画の ## Progress ブロックで、見出しと Base: の間に行を記載します。以前の実行で残された行がある場合は置き換えます。
2. まだ Progress ブロックがない場合は、Base: とタスクごとに 1 つの未チェック行を含めて、この編集でブロックを追加します。
3. その後、同じターン内に作業を続けます。

## Progress

Pre-flight: branch <current branch>
Shape: <sequential | parallel | solo>
Subagents: standard = <model> (implementers, review lenses) · heavy = <model> (adversarial review) · resolved from <user CLAUDE.md | project CLAUDE.md/AGENTS.md | harness fallback>
Tasks: <N> (<M> remaining, <R> this run)
Bound: <Task <N>, the plan's last | Task <N>, the user's stop | Task <N>, the stage <S> gate the user named>
Base: <HEAD before the first task>

Subagents 行には、階層ラベルだけではなく、解決後のモデル名を記載します。resolved from には、階層を割り当てた指示ファイル名、または harness fallback を記載します。単独実行の場合、この行は Subagents: heavy = <model> (adversarial review) — implementation inline · resolved from <source> とします。2 つ以上のステージからなる計画をレビューする場合は、先頭に standard = <model> (review lenses) · を付けます。

完了条件：計画の Progress ブロックが、この実行用に値を埋めた事前確認の行で始まり、他の編集、コミット、ディスパッチより先に記載されていること。

実装

最初のタスクの前に：

• VOCABULARY.md の ## Verification language セクションと、その直前にある seam の項目、さらに計画に Global Constraints セクションがある場合はそのセクションを読みます。Global Constraints は、各タスク固有の行とともに、すべてのタスクに適用されます。
• IMPLEMENTER-BRIEF.md の While implementing と Detours and stops の各セクションを読みます。単独実行では、インライン作業をこれらに従って進め、実装者に返すよう指示されている各所見を、以下の「Detours and stops」で扱います。どの実行形態でも、自分自身の修正はこれらに従って進めます。
• 計画内、およびその Spec: ヘッダーが指定する仕様内で、勝者を示す各 Prototype: 行を見つけ、指定されたパスにある勝者のバリアント、またはその下にコピーされたブロックを読みます。行の表面を構築または変更する各タスクでは、その行をディスパッチの Prototype: スロットに指定します。単独実行では、自分でそのバリアントを基に表面を構築します。
• git status --porcelain を実行し、ファイル一覧を保持します。それらのファイルには、ユーザーの未コミットの作業が含まれています。

タスクのループ

• 開始条件： 上記の手順が完了していること。

• 各パスでは、実行対象のタスクを計画順に、以下の手順で進めます。逐次実行では、前のタスクのチェックに合格し、コミットが完了した後にのみ、次のタスクをディスパッチします。並列実行では、すべてのディスパッチを1つのメッセージで送り、返答を受け取り次第それぞれ読みます。すべてのディスパッチが返答したら、各タスクについて、計画順に手順2から5を実行します。

  1. 実装。 単独実行：タスクをインラインで実装します。逐次実行と並列実行：DISPATCH.md に従って標準ティアのサブエージェント1つにディスパッチし、返答を待ちます（ディスパッチして待機）。
  2. チェック。 タスクのチェックを自分で実行し、出力を読みます。チェックに失敗した場合は、その出力を添えて実装者に差し戻すか、単独実行では自分で修正します。再試行は最大2回です。それでもチェックに失敗する場合、または返答でルート変更や Stop if: の該当が報告された場合は、以下の「Detours and stops」に進みます。
  3. コミット。 git status を実行します。このタスクで変更したファイルだけをパス指定でステージし、そのパスだけをコミットします（git commit -- <paths>）。このタスクで変更したファイルが実行前の一覧に含まれている場合、そのファイルにはユーザーの編集が含まれています。コミットする前にユーザーに確認します。
  4. 記録。 タスクのチェックボックスを切り替え、コミット SHA を件名の直後、— open: または — note: より前に記入します。タスクで迂回が発生した場合は、同じ手順で、その修正済みの事実を計画の根拠に追加するか、矛盾する項目をその場で書き換えます。これにより、実行再開後に同じ古い情報で再び行き詰まることを防ぎます。
  5. ステージゲート。 このタスクで計画の Stages テーブルにあるステージが完了する場合、計画に記載されたゲートコマンドをすべて実行します。ゲートが失敗した場合は、次のタスクに進む前に修正します。ただし、同じコマンドが Base（Review のステップ1）でも失敗する場合は、事後記録とします。

• ループがユーザーにターンを返すのは、次の2つの場合です。

  1. ステップ3で実行前のファイルについて質問した場合。ユーザーの回答を受けた後、ステップ3からループを再開します。
  2. 「Detours and stops」で、ユーザーが決定する必要のある事項が発生し、実行が終了した場合。

  それ以外は、サブエージェントの返答、チェックの出力、コミット、ステージゲート、迂回を含め、すべて同じターン内で直ちに次のステップに進みます。タスク間の進捗報告は停止点ではありません。

• 終了条件： Bound までのすべてのタスクがチェック済みになるか、ユーザーの決定が必要となり実行が終了した場合です。その後、Steps のステップ7に進みます。

脇道と停止条件

計画の目的地は変わりませんが、そこへ至る道筋は変わることがあります。成果物を変えずに済む想定外の事態はすべて解決し、それぞれが成果物に与える影響によって分類してください。

• 脇道：バグ、古くなった情報（名前が変更されたシンボル、移動したファイルなど）、または誤った前提がタスクを妨げているものの、最小限の修正で計画どおりの成果物をそのまま出せる場合です。修正し、レトロスペクティブ用の逸脱事項として記録してください。Task loop のステップ 4 では、修正した事実を計画に反映します。
• レトロスペクティブ用メモ：計画の経路から外れた箇所に、もともと存在していたバグです。レトロスペクティブ用に記録し、修正はしないでください。
• 別経路：成果物を変えることになる修正です。これは意思決定事項です。
• 停止：タスクに記載された Stop if: 条件に該当することが確認された状態です。作業を停止する前に、次のとおり解決してください。
  1. 条件が示すコードを読み、既存のパラメーター、ヘルパー、またはほかの呼び出し元と同じ使い方をするパターンなど、そのコードがすでに提供している方法のうち、タスクで約束した成果物をそのまま出せて、タスクで追加する部分以外のコードを編集せずに済む方法がないか確認します。
  2. そのような方法があれば、その停止条件は脇道です。単独実行ではその場で対応してください。そうでなければ、Settled: 行にその方法を記載してタスクを再ディスパッチし（DISPATCH.md）、Task loop のステップ 2 に戻します。
  3. そのような方法がない停止条件は、意思決定事項です。
• 停滞チェック：2 回修正しても失敗するチェックです。自分で原因を診断してください。
  1. 出力と、そこで示されたコードを読み、出力だけでは原因を特定できない場合は プローブ を実行します。原因を特定し、それを示す出力行またはプローブの読み取り結果を引用できた時点で診断は完了です。
  2. プローブを実行しても原因が特定できない場合は、意思決定事項です。
  3. その原因を修正しても計画どおりの成果物を出せる場合は、診断内容を反映した修正をもう 1 回行います。単独実行ではその場で対応し、そうでなければ、診断内容を Settled: 行に記載してタスクを再ディスパッチし、Task loop のステップ 2 に戻します。
  4. その修正後も失敗するチェックは、意思決定事項です。
• 意思決定事項：実行を停止し、タスクのチェックを未完了のままにして、編集したファイルをコミットせずに残し、報告書にそのファイル名を記載します。並列実行の場合は、戻ってきたほかのすべてのタスクについて、まず Task loop のステップ 2 から 5 までを完了します。その後、短縮実行として終了します。

短縮実行

短縮実行では、Review、Close the loop、Retro を省略します。レビューでは差分全体を計画全体と照合するためです。代わりに、後任者が計画を引き継げる状態にしてください。

1. 未完了の各タスクの記述を、この実行での差分と照合して読みます。その行に、該当するものをすべて — open: <この実行で生じた、そのタスクに関する質問> または — note: <タスクの記述と一致しなくなったインターフェース、パス、または契約> の形式で追記します。この実行の影響を受けていないタスクには、すでに記載がある場合を除き — note: unaffected を追記します。
2. この実行で完了した各タスクには、レトロスペクティブに記録するはずだった所見ごとに — note: <1 行の所見> を追記します。
3. 修正したリポジトリの事実は、脇道に該当するかどうかにかかわらず、根拠とともに計画の grounding に追加します。事実ごとに 1 行で追加するか、矛盾する項目を書き換えてください。
4. Progress ブロックの Base: 行の下に、Stopped: <理由> — resume at Task <N> と記載します。再開する実行でこの記載を上書きします。

Base: 9f8e7d6
Stopped: Task 2's Stop if observed, every route sets JSON — resume at Task 2
- [x] Task 1: Add the parser — a1b2c3d
- [ ] Task 2: Wire the CLI flag — open: may the export route bypass the middleware?
- [ ] Task 3: Document the flag — note: unaffected

5. 次の内容を報告します。
   • この実行で完了したタスクとそのコミット SHA。完了したタスクがない場合は、その旨。
   • 残っているタスクと、再開に使用する /lite-execute <plan path>。
   • 意思決定によって実行を終了した場合は、その意思決定をユーザーに提示します。判明した内容、該当する場合はチェックの出力、番号付きの選択肢を示し、推奨案には印を付けてください。

完了条件：未完了のすべてのタスクをこの実行での差分と照合して読み、その行に — open: または — note: が記載されていること、Stopped: 行に再開地点が記載されていること、意思決定によって終了した実行の報告書に番号付きの選択肢が記載されていること。

レビュー

すべての項目にチェックが付いたら、次の手順を実行します。

1. テストスイート全体を一度実行します。この実行で壊れた箇所を修正し、Task loop のステップ 3 と同じ方法でステージングして、修正ごとにコミットします。失敗を既存の問題として扱えるのは、Base でも同じテストが同じように失敗する場合に限ります。リポジトリの依存関係をインストールした状態で、Base の一時的な git worktree で確認してから、worktree を削除してください。既存の問題による失敗は retro の注記に記録します。
2. プランに Coverage テーブルがある場合は、各行を順番に確認します。その行の検証ステップが、今回のセッションで、その行が対象とするファイルに最後に変更を加えたコミット以降に成功していない場合は、再実行してください。人による作業のみと記された行は、Close the loop に、人だけが実行できるアクションとして記載します。
3. レビューを依頼します。各依頼には、記入済みのメッセージだけを含めます。

   • ステージが 1 つのプラン、または Stages テーブルがないプラン：次のメッセージを使い、heavy-tier レビュアー 1 名に依頼します。

     このスキルの REVIEW-BRIEF.md の絶対パスを読み、その指示に従ってください。
     Plan: <プランのパス>
     Spec: <プランの Spec: ヘッダーに記載されたパス、または none>
     Base: <Progress ブロックの Base SHA>
     Diff: git diff <Base>..HEAD
     Vocabulary: <このスキルの VOCABULARY.md の絶対パス>
     

   • ステージが 2 つ以上のプラン：standard-tier の観点別レビュアー 3 名に、1 回の波で依頼します。各レビュアーへのメッセージには、上記の内容に加えて、次の 2 行を含めます。Lens: <Contract | Coherence | Tests> および Findings: <.crank/<slug>/review-<contract | coherence | tests>.md の絶対パス>。3 名全員から回答が戻ったら、heavy-tier のマージ担当者 1 名に依頼します。メッセージは、単独レビュアー向けメッセージの 1 行目を このスキルの MERGE-BRIEF.md の絶対パスを読み、その指示に従ってください。 に置き換え、さらに次の 2 行を追加します。Review brief: <このスキルの REVIEW-BRIEF.md の絶対パス> および Findings: <3 つの Findings パス>

4. レビュアーまたはマージ担当者から返された CONFIRMED の指摘をすべて修正し、その指摘を対象とするチェックを再実行します。または、その指摘が妥当なままである理由を retro の逸脱事項に記録します。Plan decision: 行に記録済みのユーザー判断が引用されているマージ済みの指摘は、Close the loop に判断事項として記載します。ステップ 1 と同じ方法で修正をコミットします。

完了条件：すべての CONFIRMED の指摘が修正され、同じチェックで再検証されているか、妥当なままである理由とともに retro の逸脱事項に記録されているか、判断事項として Close the loop に引き継がれていること。

Close the loop

retro の前に、次の手順を実行します。

1. 今回のセッションで、コマンド、読み取り、またはテストによって、すべての未解決事項に決着を付けます。Progress 行に残された以前の短時間実行の結果、レビュアーの指摘、プランのリスク、自分で「注目に値する」と考えたことを確認します。未解決事項として残せるのは、ユーザーが判断する必要のある事項、または人だけが実行できるアクションに限ります。推奨事項とともに記載してください。
2. コードには現れない形でテストを壊すフィクスチャ、既知の不安定なテスト、ツールチェーンのコマンドに必要なフラグなど、今回の実行で迂回を招き、次回も同じ問題を招く事実は、今回の作業後も残ります。その根拠を添えた 1 行を、リポジトリに既存の AGENTS.md、CLAUDE.md、CONTEXT.md、または ADR のいずれかに追記し、コミットします。そのようなファイルがない場合は、追記する行と追記先を明記した判断事項として残します。

Retro

1. retro を .crank/<slug>/retro.md に記録します。該当するものについて、変更内容、実行した検証、レビュー結果、プランからの逸脱、昇格した事実の記録先、残っている判断事項を記載します。
2. 今回の作業で作成されたコミットの SHA と retro のパスをユーザーに伝えます。Close the loop で未解決事項が残らなかった場合は、作業が完了したことも伝えます。その後、終了します。