crank-execute

実行

目標

計画を出荷します。計画を唯一の信頼できる情報源として扱い、直接実行してください。再設計はしないでください。

厳守事項

これらはすべてのステップで適用されます。特定のステップに関するルールは、そのステップで適用されます。

• 主張より証拠を先に。 このターンで検証を実行し、その出力を読まずに、タスクが完了したと報告してはいけません。
• ステージ付き計画のタスクにはステージを付記する。 ステージ付き計画のタスク番号をユーザーに伝える際は、すべてステージを付記します。例：Task 14 (stage 2 of 3)。ステージを締めくくるタスクには、そのゲートと、ステージ行の終了状態も付記します。例：Task 18 (stage 2 of 3, gate): <exit state>。台帳の行、概要、コミットメッセージでは、タスク番号をそのまま使います。
• 目的地は固定、道筋は柔軟。 計画で出荷する内容、つまり各タスクの目標、契約、アーキテクチャは固定です。そこへ至る道筋は固定ではありません。バグ、古くなった詳細（名前が変更されたシンボル、移動したファイル）、または前提の失敗によってタスクが妨げられた場合は、タスクが約束するものをそのまま出荷できる最小限の変更を迂回策として行い、台帳の行に記録します。出荷内容を変える修正は経路変更です。その場合は作業を止め、推奨案とともに状況を提示してください。タスクに影響しない想定外の問題（タスクが触れない既存のバグ）は、サイドクエストにせず、遡及記録にとどめます。
• レビュアーは独立して判断する。 レビュー依頼はすべて前提なしで行います。レビュアー自身が情報を収集し、差分を確認し、計画から担当タスクを読み、レポートファイルから実装者の証拠を読み、固定の評価基準ファイルを適用します。依頼時に渡すのは参照先と BASE SHA だけです。それ以上の情報、たとえば差分の説明や弁護、評価基準の再掲や注釈は、依頼したレビューを事前に誘導することになります。
• 一度検証したら、証拠を信頼する。 タスクの RED→GREEN 証拠（実装者による動作ごとの出力）は、そのタスクに対するスイートの正式な実行結果です。最終ゲートでの計画とカバレッジの確認は、差分全体に対する唯一の正式な再実行です。
• 依頼を明言したら、必ずエージェントを起動する。 タスクをサブエージェントに割り当てると言った時点、または実行の選択した形でそう定めた時点で、次のアクションは必ずそのエージェントの起動です。インラインで作業してはいけません（事前の担当者確認自体は依頼ではありません）。メインスレッドで作業するのが適切な場合は、依頼を発表する代わりに、スレッド上で作業を続けることとその理由を述べてください（実行形態を変更する場合は、形態を改めて示します）。
• 依頼はブロッキング呼び出しである。 起動から戻りまで、サブエージェントが作業を担います。起動後にターンを終え、戻り通知によって再開するまで待ち、再開後の次のアクションでは必ずその戻り内容を読みます。それ以外のすべて、つまり次のタスク、担当ファイル付近の編集、進捗の確認は、その戻りを受け取るまで保留します。並列モードでは、起動の一括依頼を一度のメッセージで送り、全体をひとつのブロッキング呼び出しとして扱います。ほかの作業に進む前に、すべての戻り内容を読みます。サブエージェントの戻りが想定より遅れている場合は、BASE 以降の git log、台帳、ディスク上のレポートファイルなど、永続状態に照らして確認してから、エージェントを再開するか、推奨案とともに停滞を提示します。
• 意見の振れが生じたら、ループを止める。 前回のレビューで求められた内容を覆すよう求めるレビューは、進展ではなく意見の振れです。コードを確認せずに反転させてはいけません。両方の判定を推奨案とともにユーザーに提示してください。
• 明示的な承認なしに、強制プッシュ、過去のコミットの修正、履歴の書き換え、ブランチの削除をしてはいけません。

参照資料

サブエージェント

このスキルでは、サブエージェントを2段階で起動します。それぞれについて、SUBAGENT-TIERS.md に従って解決してください。読み込まれた指示ファイルの優先設定を先に確認し、ハーネスのモデルはその代替としてのみ使用します。standard は、調査、実装、タスクごとのレビュー、最終レビューの各観点に使用します。heavy は、ステージが1つ、または Stages テーブルがない計画の最終横断レビュー、最終レビューのマージとその修正ラウンド後の再レビュー、および BLOCKED タスクに対する一度限りのエスカレーションに使用します。このファイルの依頼またはメインスレッドの既定値は、計画外の調査に適用されます。実行形態（Flow のステップ1）は、実装とレビューに適用されます。

用語集

ステップ 2 の前に VOCABULARY.md を読んでください。そこに記載された用語の意味は、以降のすべての箇所に適用されます。ステップ 3 と 5 でレビュアーの指摘に判定を下す際、用語の意味を誤って適用した指摘は却下します。

レビュー判定

タスクごとのレビューゲート（フローのステップ 3）と最終レビューゲート（フローのステップ 5）は、どちらも同じ方法で判定します。

• 反証できる指摘だけを却下し、反証に至った理由を記録します。レビュアーが持っていないタスク間のコンテキスト、仕様、カバレッジ表はあなたが把握しています。そのため、誤検出があれば、レビューアーに調査範囲を広げさせるのではなく、あなたが反証します。たとえば、正しい再利用が重複と見なされている場合、一貫性のある単一の継ぎ目を対象としたテストが水平スライスと見なされている場合、またはレビュアーが確認した範囲外のファイルですでに満たされている受け入れ基準が未達と指摘されている場合です。却下する際は、その理由を記録します。タスクごとのレビューでは task-<N>-review.md の ## Dismissed 見出しの下に追記し、最終レビューではレトロの最終レビューセクションに記録します。
• 確認されたギャップがあれば、レビューは不合格です。
• Plan decision: の引用を含む修正リスト項目は、計画または記録済みのユーザー判断で指定された内容を示し、マージ担当者の確認時点でもその主張が有効であることを意味します。修正してください。ただし、修正によって記録済みのユーザー判断を覆すことになる場合は、推奨事項を添えてレトロの未解決項目として記録します。
• ブロッキングではない Notes を含む APPROVED は、それでも完了です。Notes は先送りされた指摘であり、タスクごとのレビューでは task-<N>-review.md から、最終レビューではレトロの最終レビューセクションから確認できます。そのため、修正ラウンドには進まず、次に進みます。再レビューの対象外に関する所見も同様に扱います。

成果物

主要な成果物は出荷済みコード、つまり進捗台帳に記録されたタスクごとのコミットです。レトロは副次的なドキュメントです。

進捗台帳

台帳は、何がリリースされたかを記録する永続的な記録です。単独での実行を含め、どのような実行形態でも、ここでタスクの完了状況を追跡します。まず git ディレクトリに保存し、書き込みを拒否された場合は作業ツリーにフォールバックします。

1. git ディレクトリのパスを出力してから、そのディレクトリを作成します。複合ワンライナーではなく、単独のコマンドを2つ使います（作業ツリーを保護するサンドボックスは、シェルの複合コマンドを拒否します）。

   git rev-parse --git-path crank
   mkdir -p <the path it printed>
   

   台帳は <that dir>/progress-<slug>.md です。スラッグをキーにしているため、複数の計画の台帳を共存させられます。スラッグは計画の親ディレクトリ名です。

2. ハーネスがその場所への書き込みを拒否する場合（作業ツリーの分離によって共有の .git パスが保護されている場合）は、作業ツリーのルートにある .crank/<slug>/progress.md を使い、フォールバックしたことを一度だけ記録します。

計画ごと、作業ツリーごとに台帳を1つ用意します。台帳の冒頭には、実行の基準点と、現在の実行の Pre-flight 行（Flow のステップ1）を記録し、その後に計画のタスクごとに1行ずつ記録します。

# Crank execute — <branch>
Plan: <plan path, normally .crank/<slug>/plan.md>
Base: <the HEAD SHA when the run started>

<the Pre-flight lines>

- [ ] Task 1: <subject>
- [ ] Task 2: <subject>

行の書式。 以下の各項目は、— の後にタスクの行へ追加します。

• <sha> — <verdict>。タスクが完了した時点でチェックボックスを [x] にし、コミット SHA（複数ある場合はすべて）に続けて、APPROVED、review skipped (clean return)、または単独実行の場合は no per-task review を記録します。再開時、[x] の行は完了済みを意味します。git log で確認して、そのタスクはスキップしてください。
• detour: <one line> — タスクで発生した迂回を、解決済みか未解決かにかかわらずすべて記録します。これにより、振り返りの Deviations と最終レビューで内容を確認できます。
• open: <one line> — タスクに関する未解決の質問を記録します。ステップ3でタスクの本文を読む人が、通常は手順、Check:、Files ブロックをもとに解決します。
• note: <one line> — タスクに引き継がなければならない事実を記録します。ステップ3で読む、すでに反映済みのインターフェース、パス、または計画の記述と一致しなくなった契約などです。
• review: <path to task-<N>-review.md> — レビューを実施した場所を記録します。そのファイルにはレビュー担当者の Notes と、理由を添えた却下内容（References → Review verdicts）が記録され、振り返りでも参照されます。この行には判定とポインターを記録し、レビュー内容はファイルに残します。

Pre-flight 行の下に置く行は1つだけです。実行を途中で終えるとき（ステップ4）に、Stopped: <why> — resume at Task <N> と記録します。

未整理の事実の保存先。 後続のタスクに引き継ぐ必要がある事実は、そのタスクの行に note: として記録します。修正されたリポジトリの事実（変更後のシンボル名、移動後のファイルパス、フィクスチャの注意点など）は、根拠とともに .crank/<slug>/grounding.md（ARTIFACT-HOME.md → Grounding）に記録し、orientation.md の初期情報として使います。それ以外はすべて、振り返りの Open items に記録します。

振り返り

計画の最後のタスクを完了させた実行が、.crank/<slug>/retro.md に振り返りを書きます（Flow のステップ7）。短い実行の場合は、代わりに台帳を次の実行へ引き継ぎます（Flow のステップ4）。セクションは以下のとおりです。

• Summary — リリースした内容と、<branch> 上のコミット <first>..<last>。
• Deviations — 発生した迂回（何が妨げとなり、どう解決したか）に加え、差分が計画と大きく異なる箇所とその理由をすべて記録します。迂回がなければ「None」とします。
• Final review — 判定、修正した指摘（コミット SHA を記載）、誤検出として却下した指摘、延期した指摘を、それぞれ References → Review verdicts に従って記録します。
• Open items — Flow → Close the loop を経ても残った項目のみを記録し、それぞれを該当ステップの完了条件に記載します。延期した指摘と却下した指摘は、上記の Final review セクションに残します。
• Promoted — この作業の終了後も引き継ぐために今回の実行で共有した事実を、それぞれ事実、その根拠となる行、記録先の file:line とともに記載します。引き継ぎがなければ空欄にします。
• Validation evidence — 実行したコマンドと、その結果。

Flow

1. 読み込みと批判的レビュー

RESOLVE-PLAN.md に従って、計画とその保存先 .crank/<slug>/ を特定します。 プランの全体像を自分で確認してください。ヘッダー（Spec:、Goal:、Gates:）、Global Constraints、Updates since spec、Refactor scope、File structure、Coverage、Stages、Out of scope、および各タスクのタイトルを読みます。タスク本文は、ステップ3で読み進める際に、一度に1つずつ読みます。プランのヘッダーに仕様（Spec:行）が記載されている場合は、それも読んでください。最終レビューの基準となるのは仕様であり、プランは仕様をタスクに分解したものにすぎません。プランにGlobal Constraintsセクションがある場合、その値はすべてのタスクに適用されます。

進捗台帳（Deliverables → Progress ledger）を開きます。この作業ツリーにこのプラン用の台帳がすでにある場合は、中断された実行として、そのセクションに従って再開します。そうでなければ、新たに開始します。新規・再開を問わず、実行のたびに、以下のリストから実行形態を選びます。必須のモードはありません。次に、Pre-flightの各行をすべて記入して台帳に書き込みます。アンカーとタスク行の間に記入し、以前の実行で残された行（Stopped:行を含む）を置き換えます。新規実行では、この書き込みによって、アンカーとプランの各タスクに対応する未チェックの行を1つずつ含む台帳が作成されます。この書き込みは、プランが確定した後に行う最初のファイル変更であり、それ以降の編集、コミット、ディスパッチより先に行います。また、プランの読み進めに伴うディスパッチも同じターン内に行います。

Pre-flight: branch <current branch>
Grounding: <.crank/<slug>/grounding.md — N entries | none>
Shape: <solo | sequential | parallel>
Subagents: standard = <model> (implement, per-task review, final review lenses) · heavy = <model> (final review) · resolved from <user CLAUDE.md | project CLAUDE.md/AGENTS.md | harness fallback>
Tasks: <N> (<M> remaining)
Bound: <Task <N>, the plan's last | Task <N>, the user's stop | Task <N>, the stage <S> gate the user named>

行のルール：作業のグラウンディングファイルが存在しないか空の場合、Grounding行にはnoneと記載します。それ以外の場合は、ファイル名とエントリー数を記載します。Modelsには、SUBAGENT-TIERS.mdを適用した後の解決済みの名前を記載し、単なるティア名は使いません。resolved fromには、サブエージェントの優先設定が記載された指示ファイルの名前を記載します。読み込まれた指示ファイルにそのような設定がない場合は、harness fallbackと記載します。Soloモードでは、Subagents行はstandard = <model> (plan walk) · heavy = <model> (final review) — implementation inline · resolved from <source>とします。<M> remainingは、台帳にある未チェックのボックスの数です。新規実行ではM = Nとなります。Bound行には、実行が終了するタスクを記載します。プランの最後のタスク、またはユーザーが指定したそれ以前のタスク（「Task 4の後で停止」「stage 1のゲートで停止」— ゲートの場合は、プランのStages表に記載された該当ゲートの最後のタスク）です。Stages表だけでは、Boundは最後のタスクのままです。

• Solo（このセッション内） — 小規模なプラン（おおむね3タスク以下）、進行中の状態を共有するタスク、簡単な修正に適しています。タスクごとのレビューは行わず、最終ゲートでSoloのレビューを1回だけ行います。
• Sequential subagents — 3タスクを超える場合のデフォルトです。タスクごとに新しいコンテキストと独立したレビュアーを使用します。
• Parallel subagents — タスクが、共有状態を持たず、互いに重複しないファイルを変更する場合に限ります。

いったん表明した実行形態は、その実行中は変更できません（Hard Rules → 表明したディスパッチにより、サブエージェントの起動が必須になります）。以下の停止確認、またはステージゲートへの回答によってBoundが移動するかプランのタスクが変更される場合、あるいは後から実行形態の変更によりShapeが置き換わる場合は、次の編集またはディスパッチの前に、変更された各行を台帳に書き直します。 その後、計画のウォークをstandardティア（SUBAGENT-TIERS.md → Dispatch またはメインスレッド）に割り当てます。計画のパス、該当する場合は取り組みの .crank/<slug>/grounding.md、対象タスク、および以下の3つのバケットをそのまま渡します。ウォークの対象は1つのステージです。最初の未チェックタスクを含むステージ（Stagesテーブルがない計画では、すべての未チェックタスク）をHEADと照らして確認します。後続ステージでは、前のステージでまだ書き込まれていないファイルが固定されるため、各ステージはゲート（ステップ3、Stage gate）でウォークします。調査結果は計画の隣にある .crank/<slug>/plan-walk-<stage>.md（ステージがない場合は plan-walk.md）に書き込みます。タスクごとに、各調査結果のバケット、その根拠、および見つかった場合は修正後のアンカーを記載し、各調査結果をバケット名とともに示すタスクごとの1行、または none を返します。ウォークでは、計画が引用する内容を確認します。根拠を伴う主張――アンカー（`<path>` → `<symbol>`）、`<path>:<line>`（シンボルなし）という代替形式、コマンドとその出力、searched <scope>, none found――は、ARTIFACT-HOME.md → Grounding の「検証してから信頼する」ルールに従い、1回の読み取りまたは再実行によって、引用箇所で確認します。同じ事実を扱う grounding の項目も、同じ方法で確認します。引用のない主張は、すべてを導出します。ウォークで実際に実行したチェックに限り、根拠とともに引用した場合に、調査結果によって実行を停止します。根拠は path:line、または結果が空だった検索です。

ウォークは報告を行います。修正の反映はあなたが行います。別の行またはシンボルで確認された引用は、新しいアンカーに置き換えて、その引用を含む計画セクションで修正します。これはステップ2でブリーフディレクトリを準備する前に行い、各実装担当者が読む唯一のセクションが、すでに正確な状態になるようにします。確認できなかった引用は、他の調査結果と同様にバケットに振り分け、修正後の事実は grounding に記録します。2つのバケットでは実行を停止し、3つ目は実行中に持ち越します。

• Blockers — 計画で指定されたシンボルをウォークで grep しても見つからない、引用先のパスが存在しない、または別のタスクと矛盾する前提条件が記載されている場合です。
• Plan-mandated defects — 計画自体の記述がレビュー基準に反する内容を指示している場合です。たとえば、何も検証しないテスト、コードベースにすでにあるヘルパーの逐語的な重複、コントラクトを覆い隠すキャストや any などです。その指示を引用してください。計画で明示的に指示された内容の上書きは、迂回ではなく常に再ルーティングです。問題を提示し、どの指示を優先するかユーザーに確認してください。
• Carried — ウォークで問題ではなく未確定と判断された内容です。2通りに読めるステップ、曖昧に使われた名前、特定できなかったシンボル、Behavior 行で固定されていないタスクの説明文中の要件などが該当します。各項目は、そのタスクの台帳行に、質問だけを記した1つの open: 行として持ち越します。タスク自身のステップ、Check: 行、または Files ブロックですでに回答されている質問は、解決内容として計画セクションに記載し、持ち越しません。途中で検証した事実（名前が変更されたシンボルの現在の名前、移動したファイルのパスなど）は grounding に記録します。

停止対象の2つのバケットは、個別の発見ごとに中断するのではなく、1回のまとめた質問として提示し、回答があるまで停止します。その後、git status --short と現在のブランチを確認します。ブランチが main／master で、変更が軽微でない場合は、コミット前に一度だけ確認します。

完了条件：ウォーク対象ステージのすべてのタスクが、調査結果のバケット分けまたは none の判定を受けていること。引用された主張がすべて引用箇所で確認されるか、バケットに振り分けられていること。停止対象のバケットが1回の質問で提示され、回答済みであること。すべての持ち越し項目が台帳行または grounding に記載されていること。ブランチと git status --short が確認済みであること。台帳が開かれ、この実行で記入した Pre-flight 行が含まれ、実行における最初のファイル変更として書き込まれ、計画内のタスクごとに1行があること。

2. 簡易ディレクトリ

どの形式でも、この実行用の簡易ディレクトリ（ブリーフ、レポート、ルーブリックの保存先）をリポジトリのルート配下 .crank/<slug>/exec/ に作成し、そのパスを一度だけ明記してください。進捗台帳の保存先は別です。最初のタスクの前に中身を用意してください。すべてのコピーはそのまま、つまりファイルをコピーし、再入力はしないでください。

簡易ディレクトリ内のファイル	参照元	サブエージェントモード	単独
implementer-rules.md	IMPLEMENTER-BRIEF.md 内のブロック	コピー	コピー — その恒常的な不具合ルールおよびRED→GREEN→REFACTORの各セクションは、ステップ 3 のインライン実装に適用されます。これらのルールが実装担当者のレポートに振り分ける内容は、代わりにあなたの振り返りに記録します
orientation.md	IMPLEMENTER-BRIEF.md 内のテンプレート。以下の調査に従って記入	作成	スキップ
review-rubric.md	PER-TASK-REVIEW-BRIEF.md	コピー	コピー — 最終ルーブリックの差分全体の品質の評価軸は、ここにある差分ごとのチェック項目を参照します
final-review-rubric.md	FINAL-REVIEW-BRIEF.md	コピー	コピー
final-merge-rubric.md	FINAL-MERGE-BRIEF.md	コピー	コピー
re-review-rubric.md	RE-REVIEW-BRIEF.md	コピー	スキップ

オリエンテーションの調査：テンプレートを簡易ディレクトリに書き込み、.crank/<slug>/grounding.md が存在する場合は、そのエントリーから未記入の欄を埋めます（ARTIFACT-HOME.md → Grounding）。その後、標準ティアのサブエージェントに、リポジトリを調査して残りを埋めるよう指示します。ただし Commands ブロックには、プランの Gates: 行をコピーします。調査では、欄が埋まっていても省略せず、引用箇所でシードされた各行を検証します。そのため、orientation.md に含まれるのは、この実行で検証された事実だけです。

完了条件：.crank/<slug>/exec/ が存在し、そのパスが一度だけ明記されていること。また、この形式で表が要求するすべてのファイルがディスク上にあり、コピーは参照元とバイト単位で同一で、orientation.md がサブエージェントモードで記入されていること。

3. タスクごと

1. 指示して実装する。 編集を始める前に、そのタスクのBASE（現在の HEAD SHA）を記録します。レビューでは <BASE>..HEAD の差分を確認し、複数コミットからなるタスクのすべてのコミットを含めます。ここで、このタスクのプランのセクション（手順、その Check: 行と Stop if: 行、Files ブロック、Interfaces、Verify: の手順）のみを読み、他のタスクのセクションは読みません。台帳によると、この実行の前のタスクですでにこのセクションが参照するファイルに変更が加えられている場合は、実行の BASE ではなく HEAD に照らしてその引用箇所を確認し、プランのセクション自体でアンカーを書き換えます。後続のすべてのタスクは台帳ではなくこのセクションを読むためです。セクションで未確定のまま残された判断（台帳の open: 項目、置き場所が二通り考えられるファイル、動作上は前提とされているのに明記されていないルール）は、同じ方法で確定します。つまり、ブリーフを作成する前にセクションへ記述し、出荷する内容に適用される場合は、オラクルを添えた Behavior 行として書きます。仕様またはプランの仕様以降の更新に、このタスクで構築または変更する画面についての Prototype: 判定があり、セクションに Prototype: 行がない場合は、ブリーフを書く前に、その行をセクションで確定します。判定に記載されたパスで採用案を開くか、in chat と記載された判定の下にコピーされたブロックを読みます。そのパスを示す Prototype: 行を記述します。in chat の場合は、採用案のブロックをその下にコピーし、ユーザーが採用案から除外した内容も記します。次に、セクション内の既存の Behavior 行でまだ固定されていない判定の各確定事項を、オラクルを添えた Behavior 行として記述します。採用案のレイアウト、情報階層、主要なアフォーダンス、ユーザーが他の案から取り入れた内容、そしてユーザーが除外した各要素が存在しないことを記載します。各除外要素のオラクルでは、画面がレンダリングされ、その要素が表示されないことを確認します。ブリーフによってセクションに内容を追加することはありません。レビュアーはブリーフではなくセクションを読むため、ブリーフだけに記載された確定事項は、レビューで逸脱と判定されます。 サブエージェントモードでは、IMPLEMENTER-BRIEF.mdを基に、brief ディレクトリにtask-<N>-brief.mdを作成します。Task ブロックでは、見出しによってタスクの計画セクションを指定し、タスクの- [ ] Behavior N:行を記載します。また、orientation.mdとimplementer-rules.mdを参照し、レポートのパスをtask-<N>-report.mdとします。ディスパッチ時には、その brief ファイルを実装担当者に渡し、簡潔な報告を返すよう依頼します。Files ブロックが重複しない場合に限り、複数の実装担当者を1つのメッセージで並行してディスパッチします。スポーンするたびに処理がブロックされます（Hard Rules → A dispatch is a blocking call）。

   実装自体は、ソロの場合はあなたが、brief ディレクトリのimplementer-rules.mdに従います。実装担当者の場合は、その担当者が従います。実装では、そのファイルで定められたRED→GREEN→REFACTORサイクルを、タスク内の各振る舞いについて1回ずつ実行し、その後タスクのverify手順を実行します。計画で明示的にサイクルを省略している場合（設定の切り替え、ドキュメントの編集、生成コード）は省略します。タスクがグリーンになったら、タスク名を含むメッセージで一度だけコミットし、台帳の該当行を更新します。計画に記載された事実（件数、フィクスチャの形状、シンボル名など）を修正する寄り道があった場合は、計画全体を検索し、後続セクションでその事実を固定している箇所があれば、ウォーク修正と同様にすべて書き換えます。

   実装担当者のステータスがDONEまたはDONE_WITH_CONCERNSの場合は、2のトリアージに進みます。NEEDS_CONTEXTの場合は情報を提供して再ディスパッチします。BLOCKEDでリルートが記載されている場合（移動先自体を変更する必要がある場合）は、直接ユーザーに伝えます。それ以外のBLOCKEDの場合は、例外的に一度だけ上位ティアにエスカレーションし（標準ティアを既定とするルールの唯一の例外）、その後ユーザーに伝えます。適用対象のサイクルについてRED→GREENの証拠がない報告、または複数の振る舞いを扱うタスクなのに一括のペアしかない報告は、CHANGES_REQUESTEDとします。

2. レビュー（サブエージェントモードのみ）。 簡潔な報告をトリアージします。レポートはディスク上に残します。問題のない報告、すなわちStatus: DONE、Detours: noneまたはsettled only、Concerns: noneであり、各振る舞いについてRED→GREENのペアがあるか、サイクルを省略する計画の行が引用されている場合は、このレビューを省略します。台帳の該当行にreview skipped (clean return)と記録します。（プロジェクトの決定によるものです。1週間の実行で、タスクごとのレビュー41件中40件が承認され、そのほとんどは観察事項や解決済みの寄り道を対象にディスパッチされていたため、未解決の寄り道と懸念がある場合に限りレビューします。）解決済みの寄り道とは、brief、orientation.md、根拠情報、またはあなたがすでに指示したもので、実装担当者の着手前に判断が済んでいるものです。それでも台帳の該当行にはdetour:として記録します。

   未解決の寄り道または懸念は、計画にもあなたにもまだ判断されていない事項です。報告に対するあなた自身の疑念も同様であり、その場合は台帳の該当行に記載して、標準レビュー担当者を先入観なしでディスパッチします（Hard Rules → Reviewers judge independently）。レビュー担当者には、記録済みのBASE SHA、計画のパスとこのタスクの番号（計画のGlobal Constraintsを常時参照する基準とする）、RED→GREENの証拠を確認するための実装担当者の**task-<N>-report.mdへのパス、brief ディレクトリのreview-rubric.md、およびbrief ディレクトリのレビューのパス**task-<N>-review.md（レビュー全文の記載先）を渡します。観察事項を理由にレビューを依頼することはありません。各項目の扱いは、Deliverables → Progress ledger → Where a loose fact livesに従います。

   レビューでは、ルーブリックのチェック項目ごとに1行、テストを明記した振る舞いごとに1行を記載し、その後に判定、さらにCannot verify:の一覧を記載します。理由のないn/a、または行に記載のないチェック項目は未実施のチェックです。判定を読む前に、レビューを差し戻してください。unpinned:の各行は計画の不備です。オラクルを含むBehavior行をタスクの計画セクションに記載し、その動作を固定するテストを今回の調査結果に追加します。各Cannot verify:項目は自分で解決し、判定はReferences → Review verdictsに従います。

3. 修正ラウンド（CHANGES_REQUESTED の場合）。 次のタスクに進む前に実行します。FIX_BASE（レビュー担当者が直前に評価した HEAD）を記録し、残っている指摘を一字一句そのまま brief ディレクトリの task-<N>-findings.md に記載します（後続のラウンドでは ## Round <R> 見出しの下に追記します）。修正担当者と再レビュー担当者はこのファイルを読みます。IMPLEMENTER-BRIEF.md の task-<N>-fix-brief.md テンプレートから修正担当者向け brief を作成します。このテンプレートにはラウンドの範囲、指摘で言及されたファイルまで対象を広げた Files ブロック、そして task-<N>-report.md に追記する検証の再実行内容が含まれており、再レビュー担当者は自身でテストを実行せずにそれを読みます。次に、標準の実装担当者をこの brief に基づいて作業させます。

   修正担当者が変更を取り込んだ後、再レビューを依頼します。最初のレビューと同じポインター形式を使いますが、ルーブリックには re-review-rubric.md を指定し、計画タスクへのポインターの代わりに指摘ファイルを渡します。レビュー先は同じ task-<N>-review.md とし、## Round <R> 見出しの下に追記します。差分範囲は <FIX_BASE>..HEAD とし、再レビュー担当者自身が確認します。また、ルーブリックの比較に関する例外規定のため、タスクの BASE SHA も渡します。再レビューが CHANGES_REQUESTED を返した場合は、新しい FIX_BASE から次のラウンドを開始します。このループは承認されるまで続けます。ただし、承認とは「毎ラウンドの要求にすべて従う」ことではありません。振り子状態になったらループを停止し（Hard Rules）、直前のラウンドで解決済みの点を再スタイル化するだけ、または再び持ち出すだけの再レビュー判定は、この段階で却下する指摘です。

4. ステージゲート。 完了したタスクによってステージが閉じ、Bound がその先にある場合は、そのステージの最初のタスクに着手する前に次のステージを確認します。ステップ 1 でそのステージのタスクを HEAD に対して確認する作業を依頼し、停止条件となる項目を一つの質問として提示し、修正内容を計画に反映し、回答によって変更される Pre-flight の行を台帳で書き直します。ゲートが Bound である場合は、Short run に従って台帳を引き継ぎ、実行を終了します。

タスクごとの完了条件：台帳の該当行がコミット SHA とともに [x] となり、Line grammar に従って判定欄が記入されていること、発生したすべての寄り道が detour: としてその行に記載されていること、そしてレビューを実施した場合は task-<N>-review.md がディスク上に存在し、すべての Cannot verify: 項目があなたによって解決され、却下した項目が ## Dismissed の下に追記され、ファイルのパスがその行に review: として記載されていること。

4. Short run：台帳を引き継ぐ

台帳に未チェックのボックスを残したままタスクループが終わる実行はショートランです。Bound（ステップ 1）が最後のタスクに届かなかった場合、または経路変更や BLOCKED の報告によって停止した場合に該当します。最終ゲート、ループ終了処理、振り返りは、計画の最後のタスクを完了した実行が担当します。Bound が終わらせるのは作業単位であり、フェーズではありません。実行はその単位の検証後に終了し、検証で判明した内容にかかわらず、新たに見つかった不具合は推奨事項を添えた顕在化済みの指摘として記録し、新たな修正ラウンドには移りません。ショートランはここで終了し、計画を引き継ぐ担当者に brief を渡せる状態で台帳を残します。

未チェックの各タスクを、この実行で実際に納品した内容と照らし合わせて確認し、Deliverables → Progress ledger → Line grammar に従って次の内容を記録します。

• 未チェックの各タスクの行に、そのタスクに必要な open: と note: の項目を記載します。
• .crank/<slug>/grounding.md に、証拠を添えて修正したリポジトリの事実をすべて記載します。複数のタスクにまたがる事実は、各行ではなくここに記載します。
• Pre-flight の行の下に Stopped: の行を記載します。

次に、ステップ 8 に従って引き継ぎます。

完了条件：未チェックのすべてのタスクについて、この実行の差分と照らし合わせて確認し、必要な情報が記載されているか、影響がないことが確認されていること。Stopped: の行に再開地点が記載されていること。git status --short がクリーンであるか、残っている変更が引き継ぎ時に記載されていること。

5. 全体を検証する

計画内のすべてのタスクが台帳で [x] になっています。それまでに停止した実行は、ステップ 4 までに終了しています。完了を宣言する前に、順番に 3 つのゲートを通過してください。どれか 1 つでも失敗したら実行を停止します。

1. 計画の確認。 計画内のすべてのタスクを、実際のコミットと照らして再確認します。計画のゲートコマンドを実行します。計画に Gates: ヘッダー行がある場合はそのコマンドを、計画がそれより古い場合は suite／lint／typecheck／build を、今回のターンで改めて実行し、出力を確認します。
2. カバレッジの確認。 計画の Coverage テーブルを行ごとに確認し、各行について検証手順が今回のセッションで成功したことを確認します。古い結果のものや、先行タスクによって壊れた可能性のあるものは再実行します。human-only と記された行はレトロスペクティブの Open items に記録します。計画に Coverage テーブルがない場合は、仕様の受け入れ基準（仕様がない場合は計画に記された目標）を順に確認し、それぞれが差分を満たしているか自分で確認します。
3. 最終レビュー（新鮮な視点で）。 すべての最終レビュアーは、先入観のない状態（Hard Rules → Reviewers に従い、独立して判断）でレビューします。各レビュアーには、レビューの観点と回答形式が記された、ブリーフディレクトリ内の final-review-rubric.md とともに、仕様のパス（仕様がない場合は計画のパス）、Coverage テーブルと、存在する場合は Global Constraints を含む計画のパス、各タスクで取った迂回措置を記録したタスク行がある台帳のパス、実行開始時に台帳に記録された BASE SHA（差分の範囲は <BASE>..HEAD）を渡します。
   • ステージが 1 つ、または Stages テーブルがない計画の場合：これらの情報を渡し、レビュー全体を記録するブリーフディレクトリ内のレビュー用パス final-review.md を指定して、heavy レビュアーを 1 名ディスパッチします。
   • ステージが 2 つ以上ある計画の場合：これらの情報と、担当するレンズ（contract、coherence、quality のいずれか）、およびブリーフディレクトリ内の各レンズ用レビュー先 final-review-<lens>.md をそれぞれ指定して、standard tier のレンズレビュアー 3 名を同時にディスパッチします。3 名全員から回答が返ったら、これらの情報、ブリーフディレクトリ内の final-merge-rubric.md、3 つのレンズ用レビュー先、およびレビュー用パス final-review.md を渡して、heavy マージ担当者を 1 名ディスパッチします。マージ担当者の回答が最終レビューの回答となります。

CHANGES_REQUESTED の場合、コードに手を加える前に、References → Review verdicts に従って各指摘を精査します。精査を通過した修正だけを適用し、それ以外は変更しません。動作に関する修正は、まず失敗するテストを追加し、個別にコミットします。水平スライスに関する指摘には、実装がなければスライスごとのテストが失敗することを示して対応します。実証したスライスは、その後レトロスペクティブの Final review セクションに記録します。その後、上記の情報を渡して heavy レビュアー 1 名が先入観のない状態で 1 回だけ再レビューを行います。final-review-rubric.md を再利用し、final-review.md に ## Round <R> 見出しを付けて追記します。さらに、レビュアーが判断した時点の HEAD である FIX_BASE と、精査を通過した指摘を渡します。これにより、レビュアーはルーブリックの Fix round 分岐に進みます。修正できない指摘は、レトロスペクティブの Open item として明確に記載します。先行するタスクごとのレビューで要求された変更を覆すことになる指摘は、方針の揺れにあたります。そこで停止し、Hard Rules に従って報告します。

完了条件：ゲートコマンドが今回のセッションで成功しており、Coverage のすべての行が今回のセッションで成功しているか、human-only としてレトロスペクティブの Open items に記録されており、final-review.md に最新ラウンドの判定が記録されていること。また、そのラウンドで未解決となった指摘はすべて、個別のコミットで修正されるか、理由を記録して却下されるか、レトロスペクティブの Open item として記載されていること。

6. 未解決事項を片付ける

完成した作業を納品します。振り返りを書く前に、計画で生じた未解決事項をすべて集めます。以前の短い実行で台帳のタスク行に保留された事項、台帳が参照するすべての task-<N>-review.md にある Notes と却下事項、今回の実行での計画上のリスク、人間のみが対応できる Coverage の行、そして自分で「注記する価値がある」と判断した事項です。そのうえで、それぞれを次のように振り分けます。

1. 解決する。 コマンド、読み取り、テストで今回のセッション中に解決できる場合は、今すぐ実行して出力を読みます。検証済みの事実は解決済みとし、引き継ぎには記載しません。解決とは検証であり、やり直しではありません。確認によって実際の不具合が判明した場合は、次の項目に振り分けます。確認された軽微な問題は、振り返りに延期事項として残します。
2. 修正する。 リリース済みコードの不具合は最終ゲートを通過できません。「全体を検証する」に戻して対応します。計画にない修正は範囲を限定します。このスキル独自のディスパッチ形式に沿って、調査を1回、テストを先に書く修正を1回、レビューを1回だけ行い、そのレビューで何が判明してもそこで停止して報告します。
3. 記録に昇格する。 今回の作業で寄り道の原因となり、次回も同じ寄り道を招く事実（フィクスチャの落とし穴、既知の不安定なテスト、ツールチェーンの罠など）は、作業が終わっても残ります（ARTIFACT-HOME.md → Grounding）。その事実を裏付ける証拠を添えた1行を、リポジトリにすでにある CLAUDE.md、CONTEXT.md、または ADR のいずれかに追記し、追記先の file:line を振り返りの Promoted セクションに記録します。リポジトリに該当するファイルがない場合は、次の項目に振り分けます。つまり、行と追記先を明記した判断として記録し、頼まれていないファイルは作成しません。
4. 判断事項としてエスカレーションする。 ユーザーに委ねる必要が本当にあるものは残します。ユーザーだけが判断できるトレードオフや、人間にしか実行できない作業（目視でのスモークチェック、こちらが持っていない認証情報など）です。

完了条件：すべての未解決事項が解決、修正、追記先の file:line を添えて記録に昇格、または推奨案付きの判断事項として記載されていること。今回のセッションで確認できた事実を言い換えただけの項目は残しません。

7. 振り返り

リポジトリのルートにある .crank/<slug>/retro.md に、Deliverables → Retro に記載された各セクションを含めて振り返りを書きます。

8. 引き継ぐ

完了した作業を報告します。リリースしたもの、その証拠となる検証、そして「未解決事項を片付ける」の後も項目が残った場合に限り、その項目をそこで記載したとおりに報告します。

短い実行の場合は、代わりに次の内容を報告します。コミット SHA とともに完了したタスク、残っているタスク、停止した理由、台帳のパス、および再開するための Next: /crank-execute .crank/<slug>/plan.md。残りの情報は台帳に記載されています。

安全なデフォルトを採用し、それを明記して、後に残る次のステップを最初に示します。

• 振り返りは .crank/<slug>/ に、コミットは <branch> 上のローカルに残します。それぞれ1行で明記します。
• Next: 作業を進めるための単一のコマンドまたは判断事項を示します。たとえば、ベースブランチから実行する git merge <branch>、または「未解決事項を片付ける」で残った唯一の判断事項です。

最後に、希望があれば別の方法（PR を開く、ブランチを破棄する、振り返りをコピーまたは印刷する）も選べることを述べる一文を添えて終了します。番号付きの質問にはせず、その後は続けません。