develop-change

変更の開発

開始時にアナウンス：「develop-change スキルを使って計画をディスパッチします。」

前提条件

• worktree 内にいること（worktree-discipline）。
• 重要な変更の場合、計画があること（plan-change）。
• あなたはディスパッチャーです。タスクのサブエージェントは develop-tdd を読み込み、レビュアーは review-conformance を読み込み、修正担当者は develop-tdd または develop-refactor を読み込みます。このスキルを読み込むことはありません。

手順

委任：計画の各タスクをディスパッチする

ループを進行します。サブエージェントが develop-tdd に従って計画内の1つのタスクを実行し、あなたは計画、記録、判断を管理します。

• 計画内のすべてのタスクをディスパッチします。タスクが1つだけの計画も含みます。ディスパッチの許可をユーザーに求めないでください。これが通常の手順です。

• 同時に実行できるのは最大5つで、対象ファイルが重複しない場合に限ります。 Files touched: の一覧が重複しないタスク（plan-change）だけを並行して実行します。それ以外は順番に実行します。

• プロンプトには計画内のタスクへの参照のみを記載します。 サブエージェントのディスパッチには、利用可能なハーネス（Task または Agent ツール、/agent コマンド）を使用します。

  Execute task 3 of docs/plans/2026-08-30-<topic>.md under the develop-tdd
  skill. Create your task worktree with
  `sh .guardrails/scripts/task-worktree.sh start t3` from the change worktree
  you are in; it is .worktrees/<change-branch>-t3, on branch
  <change-branch>-t3 off <change-branch>. Commit your work on that branch and
  leave it there — do not merge it. Once your task worktree exists,
  do not commit on <change-branch> and do not keep working in the change
  worktree. For each of the task's paths, follow
  the guidelines file `guidelines-file.sh TEST` printed for it:
  <file>: <paths>   (one line per file it printed)
  Return the dispatch report.
  

  プロンプトにタスクの worktree パスを記載します。 サブエージェントは変更用 worktree のサブツリーに固定されていますが、その固定を侵すまでそのことを認識できません（worktree-discipline の手順1）。変更用 worktree で開始し、そこで task-worktree.sh start を実行します。プロンプトで禁止する内容は、タスク用 worktree が作成された後から適用されます。すなわち、変更ブランチでのコミットと、変更用 worktree での追加作業です。

  タスクの内容を改めて記載しないでください。パス、コード、期待される出力は、すでに計画に記載されています。

• 各タスクブランチは自分でマージします。 サブエージェントはタスクブランチでコミットしますが、マージはしません。報告が成功を示したら、変更用 worktree で次を実行します。

  sh .guardrails/scripts/task-worktree.sh merge <tag>
  

  これにより、タスクブランチが変更ブランチにマージされ、タスク用 worktree とタスクブランチが削除されます。ベースブランチには一切触れません。

ディスパッチ報告

サブエージェントは develop-tdd で指定されている形式の報告のみを返します。差分、ログ、説明など、ほかの内容は含めません。

• worktree: 行に、プロンプトで指定したパス以外のパスが記載されている場合、そのタスクは正しく実行されていません。マージしないでください。指定した worktree でやり直すようサブエージェントに指示するか、sh .guardrails/scripts/task-worktree.sh discard <tag> を実行してからタスクを再度ディスパッチします。discard が操作するのはネストされたパスのみで、ほかの場所でチェックアウトされているタスクブランチは拒否されます。
• 各テストが実装前に失敗していたことを示す唯一の記録は、red -> green: の行です。新しいテストごとに1行を必須とします。verify-before-merge のチェック4でこれらの行が確認されます。
• 報告が届くたびに、該当タスクのそばに報告の内容と inherited: の行を計画に書き込み、そのタスクを完了としてマークします。 merge-change の手順5で、これらが計画から検証記録にコピーされます。手順5の後にディスパッチされた修正（6a または 6c の失敗に対する修正、ベース移動ラウンドのレビュー）は、その行を検証記録に直接書き込みます。

停滞とその他の停止条件

回答がユーザーのものになる場合に限り、停止してください。 同じ箇所で繰り返し失敗した場合も該当します。

• 同じタスクが red -> green サイクルで 2 回失敗した場合
• 同じタスクに対して、レビューで 2 回所見が返された場合
• 適合性レビューで所見が報告され、その修正がマージされた後に、同じ所見が再度報告された場合

新たな所見がある適合性レビューは、ループが機能している状態であり、再発ではありません。再発として数えるのは、同じ箇所で同じガイドライン条項に関する所見だけです。箇所とは、以前の所見で示されたファイルと行を指します。同じ条項に関する所見でも、別の箇所であれば新たな所見であり、再発ではありません。low を超える所見だけを数えます。low を超える所見がないラウンドが最後となり、その中で所見が再発していても変わりません。すでに計画に記録した所見と照合してください。レビュー担当者は各ラウンドで新たに選ばれ、既存の所見を把握していません。

その場合は停止し、何が停滞しているか、何を試したかを報告して、選択をユーザーに委ねます。対応レベルを上げるか、タスクを別の方法で分割するかを選んでもらいます。適合性レビューで所見が再発した場合は、その所見を受け入れるか、該当するガイドライン条項に反する判断をするかを選んでもらいます。タスクが難しいことは、停止する理由にはなりません。

このしきい値に達していない場合は、ループを続けて再ディスパッチします。ただし、新しいプロンプトではアプローチを変えてください。同じタスクを同じ方法で言い換えて再ディスパッチしても、同じ失敗が起きます。

次の 3 つの停止条件は意図的に設けられており、ユーザーの判断に委ねられます。

• worktree-discipline のステップ 4（red ベースライン）
• verify-before-merge のチェック 5（文書化されたカバレッジの欠落を受け入れる場合）
• develop-refactor が設計変更を要すると返したアーキテクチャ上の所見について、design-architecture が対応する場合：代替案はユーザーが選びます。

それ以外の場合は、ループを続けてください。

判断に必要な場合に限り、コードを読んでください： ディスパッチの報告に予想外の内容がある場合、2 つのタスクが分岐しているように見える場合、または所見の判断が必要な場合です。

適合性レビュー

最後のタスクブランチがマージされたら、変更差分に該当するガイドラインファイルを選びます。

sh .guardrails/scripts/guidelines-file.sh TEST \
    $(git diff --name-only main...<change-branch>)
sh .guardrails/scripts/guidelines-file.sh CODE \
    $(git diff --name-only main...<change-branch>)
sh .guardrails/scripts/guidelines-file.sh ARCHITECTURE \
    $(git diff --name-only main...<change-branch>)

いずれかのファイルで終了コード 2 が返されるか、ファイルが見つからない場合は停止し、ガードレールのスクリプトとテンプレートを再インストールしてください（ratchet のアップグレード）。出力がある各ファイルについて、review-conformance スキルを使うサブエージェントを 1 つずつ、すべて同時にディスパッチします。それぞれが 1 つのファイルを読み、何も変更しないため、互いに競合することはありません。

Review main...<change-branch> under the review-conformance skill against
<file>, for these paths: <paths>. Read the change worktree at <path>; do not
create a task worktree, edit, or commit. Return the report review-conformance
states.

レビュー担当者は何も変更せず、タスクのワークツリーも割り当てられません。 プロンプトには、変更作業のワークツリーのパスと、変更禁止の指示を一緒に記載してください。これらがないと、サブエージェントはほかのディスパッチに従い、タスクのワークツリーを作成してしまいます。

すべてのレビューが報告されたら、修正をディスパッチします。所見のあるレビューごとにサブエージェントを 1 つ、通常のタスクと同様にネストしたタスクワークツリーで実行します。CODE または ARCHITECTURE ファイルの所見には develop-refactor を、TEST ファイルの所見には develop-tdd を使い、それぞれ task-worktree.sh merge でマージします。develop-refactor が設計変更を要すると返したアーキテクチャ上の所見は、design-architecture に送ります（「停滞」）。並行して処理するのは、ファイルが重複しない場合に限ります。所見を修正したエージェントは、その所見をレビューしません。

Fix the findings below, from the review of main...<change-branch> against
<file>, under the develop-refactor skill (develop-tdd for a TEST file).
Create your task worktree with
`sh .guardrails/scripts/task-worktree.sh start <tag>` from the change worktree
you are in; it is .worktrees/<change-branch>-<tag>. Commit there and leave it
there — do not merge it.
<the findings, verbatim>
Return the report the skill states.

その後、レビューを再度実行します。low を超える所見がない最初のラウンドが最後です。ラウンド数に上限を設けず、所見が初めて再発した時点で停止します（「停滞」）。所見が届くたびに、その内容と対応方針を計画に記録します。これは red -> green: の行と同様です。merge-change のステップ 5 で、それらを記録の ## Guideline reviews にコピーします。これらのレビューは merge-change のステップ 4 ではなく、その前に実行します。所見があれば、この一連の手順をステップ 1 から再実行します。

注意すべき兆候

考え	実際
「タスクは1つで、並行作業もないから、自分でやろう」	ディスパッチしてください。コードとテスト出力はコンテキストに入りません。
「サブエージェントが自分のブランチをマージできる」	作業ツリーでチェックアウトされている変更ブランチへの更新は Git に拒否されます。また、タスク作業ツリーから git merge <change-branch> を実行すると、マージの方向を間違えたまま終了コード 0 で終了します。task-worktree.sh merge を実行してください。
「結果の行が緑だから、すべてのテストが一度は赤だった」	それを示すのは red -> green: の行だけです。
「同じプロンプトでもう一度ディスパッチする」	まずアプローチを変更してください。
「merge-change のステップ4で名前を修正する」	それを行うとマージの手順が再実行されます。ここで適合性レビューを実行してください。
「レビュアーが問題に気づいたのだから、そのまま修正もできる」	レビュアーは何も変更しません。修正は別途ディスパッチし、次のラウンドでレビューします。
「1人のレビュアーがすべてのファイルを確認できる」	レビューごとにファイルは1つです。1ファイルを担当するレビュアーなら、見落としが少なくなります。

完了条件

• すべての計画タスクが完了し、その red -> green: の行が計画に記載されています。
• TEST、CODE、ARCHITECTURE の各適合性レビューが、最終ラウンドで重大度が低以下の状態で実行され、すべての指摘が修正または処置済みです。
• 続いて check-traceability を実行し、その後 merge-change を実行します。ステップ6aのゲートは verify-before-merge です。このゲートを通過するまで、変更が完了したと主張してはいけません。

参考資料

• references/rationale.md — ここに記載されたルールが自分のケースに合わないと思われる場合、またはルールの変更を提案する前に読んでください。