3. Task

タスクレイヤー仕様書

本文書は Li+ プログラムのタスクレイヤー（rules/task/*.md + skills/task-*/SKILL.md）の仕様を定義する。 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する。

rules/task/*.md は .claude/rules/ 経由で常時コンテキストに存在する（compaction を生存）。skills/task-*/SKILL.md はトリガー時に skill auto-invocation で読み込まれる。

各セクション冒頭に対応する実体ファイル（rules または skill）を literal reference として明示する。customizer は参照行を見て該当ファイルを直接開けるようにする。

層境界注記：issue 操作詳細（Issue Format / Issue Maturity / Sub-issue Rules）の実体は L4 Operations Layer に置かれる。本レイヤーからは cross-reference として参照する。L4 内の配置は実行主体で分かれ、Issue Format は親が実行主体であるため rules/operations/main-agent-procedures.md 常駐、Issue Maturity / Sub-issue Rules は skill である。

---

issue 運用

（→ rules/task/task.md [Task Issue Rules]。常時ロード）

ルール

すべての作業は issue から始める。issue 番号のない commit / PR は禁止する。関係のない issue を流用せず、必ず新規作成する。

issue は基本的に AI が作成する。人間も作成できるが、既定の作成者は AI である。

issue 本文は「現在の要求スナップショット」として扱う。履歴ログではない。現在の source of truth = issue 本文 + ラベル。

issue に実装を書かない。

コメントは補助であり、現在地を理解するためにコメント列を読まなくてよい状態を保つ。

責務

issue 運用ルール（rules/task/task.md の [Working with Issues]）は rules/ 経由で常時ロードされ、関連する skill（skills/operations-on-issue-maturity/SKILL.md 等、L4 定義）が auto-invocation で詳細な操作手順を補う。実行主体がメインエージェントになりうる手続きは skill ではなく rules/operations/main-agent-procedures.md に正本を置く（Issue Format はこちら）。

issue は AI の内部 TODO である。ユーザーからの指示を待たずに管理する。

独自判断の外部化リダイレクトの第一候補は issue とする。モデルレイヤー側で定義された「判断を外部記憶に外部化する」上位判断ルールを、タスクレイヤーでは issue に具体化する。

外部化リダイレクトは独自判断の外部化にのみ適用する。対話 context それ自体は外部化対象外とする。issue body は判断の記録（何が決まったか）、対話 message は履歴（どう決まっていったか）。対話メッセージを issue body にそのまま転記しない。

作成タイミング： バグ発見時、仕様ギャップ発見時、大きな作業のタスク分割時、対話の中で永続化すべき作業メモが生まれた時、または対話中に Li+ spec 自体の改善点に気づいた時。Li+ spec 改善の issue 作成敷居はメモリレベルの気づきと同程度でよい。迷わず memo ラベルで作成する。

issue 作成時に3項目がすべて埋まっていることは要求しない。話題が永続化すべき作業単位になった時点で、AI が明示指示を待たずに issue を作成できる。人間が「issueから始めて」と起動句を言わなくても issue 化できる。

更新タイミング： 受理された要求が変わった時、成熟度が変わった時、タスク分割が必要になった時。

クローズ条件： 実装完了・CI パス・リリース済み、またはユーザーが動作確認を報告した時。

open 保持： 運用テスト中の issue はクローズしない。

触らない： 永続参照系としてクローズ禁止が明記された issue。

情報不足時は必ず人間に確認する。

自律

ラベルは運用の中で進化する。詳細な運用ポリシーと廃止履歴はオペレーションレイヤー（rules/operations/operations.md）を参照。

---

ラベル定義

（→ rules/task/task.md [Task Label Definitions]。常時ロード）

ラベルは AI の読みやすさとフィルタリングのためにある。

ルール

作成時は必ず説明文を書く。

責務

ラベルの状態変化に応じて適切に適用・更新する。

ライフサイクルラベル

着手・進行・待機の状態を表す。状態変化時に適用する。

ラベル	意味
in-progress	着手中、実装または検証が進行中
review-pending	実装フェーズ終了、orchestration（brake 評価 / レビュー / マージ / クローズ）待ち。executor 非依存。subagent は exit のたびに必須（brake 裁定で再開された委譲は2回 exit する）、main は best-effort
waiting	外部依存待ち（CI / 依存 issue / 環境）。pause 状態。遷移時に理由を issue コメントへ書く
blocked	人間の入力待ち。stop 状態。遷移時に理由を issue コメントへ書く
backlog	受け入れ済み、着手時期未定
deferred	今回対応しない。あとで見直す

state-machine subset = in-progress / review-pending / waiting / blocked。同時に付与できるのは 4 つのうち高々 1 つで、併記は禁止。これらは event ではなく状態であり、1つの issue の生涯で同じ状態に2回以上入ることがある。不変条件が縛るのはある時点で何が付いているかであって、その状態が何回立ったかではない。待機状態の境界は「何を待っているか」で決まる。review-pending は完成した実装そのものを待つ区間すべてを覆い、semi_auto の minor / major における人間の PR レビュー待ちもここに入る——その待ちは完成物への裁定を人間に求めるのであって、作業が必要とする入力を求めるのではないため、blocked にはならない。blocked は作業を進める / 判断を作るために人間の入力が要る状態である。

成熟度ラベル

「どこまで収束したか」を表す。issue 本文の収束度に応じて更新する。作成時に付与する。

ラベル	意味
memo	メモとして開始した状態。見出しは必要なものだけでよい
forming	本文を再構築しながら要求を整えている状態
ready	本文が実装開始できる形まで収束している状態。ただし更新は継続可能

memo / forming のまま実装開始の根拠にしない。

タイプラベル

作成時に1つ以上付与する。

ラベル	意味
bug	動いていない、壊れている
enhancement	新機能・改善要望
spec	Li+ の挙動に影響する仕様・ポリシー・定義
docs	ドキュメント変更（挙動への影響なし）
tips	リリースに属さない運用ノウハウメモ

---

Agentic Search（統合 skill、L1 配置）

（→ skills/model-agentic-search/SKILL.md。L1 Model Layer。トリガー時ロード）

#1380 (Phase 3 of #1217) で、旧 4 skill (skills/model-agentic-search/ 機械的 core + skills/model-web-search-judgment/ Web 側消費規律 + skills/task-research-strategy/ 親 AI governance + skills/task-retrieval-orchestration/ 親 AI 消費規律) を単一 skill skills/model-agentic-search/（#1380 当時は agentic-search、#1512 で現名に改名。冒頭の skills/model-agentic-search/ 機械的 core は統合前の core 単体を指す別物）に encapsulate 済。 auto-invocation 面が単一化、L3 task layer 側に残置する独立 skill は無くなった。

統合 skill は以下を内包する：

• 機械的 core: calibration + category OR trigger / question type 分類 / Tier 1 早期 stop + Tier 2 多角度 / 三状態 cross-check / Stage 1-2 escalation / 停止条件
• Web 側消費規律: citation handling, model-knowledge baseline reminder
• 親 AI 側 pre-retrieval governance: 検証優先、文脈保全、自発的並列調査
• 親 AI 側 post-retrieval 消費規律: budget gate (soft cap 9 / hard stop 12)、停止判断、naive single-shot defense

詳細は skills/model-agentic-search/SKILL.md 本体を参照する。

---

issue 操作

層境界注記：issue 操作（Issue Format、Issue Maturity、Sub-issue Rules）の実体は L4 Operations Layer に配置される。L3 からは、タスク管理の観点で要求される振る舞いを cross-reference として記述する。L4 内では実行主体で配置が分かれる —— 実行主体が親になりうるものは rules/operations/main-agent-procedures.md の常駐面、それ以外は個別 skill（rules/operations/main-agent-procedures.md の The bar and its pair）。Issue Format は前者、Issue Maturity / Sub-issue Rules は後者である。

• Issue Format の実体 → rules/operations/main-agent-procedures.md の ## Issue format（L4。rules/ 常時ロード。skill 側はポインタ）
• Issue Maturity の実体 → skills/operations-on-issue-maturity/SKILL.md
• Sub-issue Rules の実体 → skills/operations-on-sub-issue/SKILL.md

アダプターが auto-invocation を提供する場合、対応するトリガー時に自動ロードされる。

Issue Format

（→ rules/operations/main-agent-procedures.md の ## Issue format。L4。rules/ 常時ロード）

ルール

issue タイトルは ASCII 英語のみとする。commit / PR タイトルと同一の言語規約に従う。 issue 本文は LI_PLUS_PROJECT_LANGUAGE で記述する。 rules/operations/operations.md の ## Operations Rules が述べているのは同節自身の commit / PR の行についてであり、その傍らに置かれた2つの軸は上記の一致によってここへ及ぶ——タイトル軸、および操作対象のリポジトリが LI_PLUS_REPO のリポジトリ自身である場合に LI_PLUS_PROJECT_LANGUAGE が本文言語へ届かない carve-out である。いずれもそちらを読む。ここには写さない。

責務

issue は未完成なメモから開始できる。3項目は収束先の最小構文であり、作成時の必須条件ではない。

実装対象として扱う段階では、本文を以下へ収束させる：

• 目的
• 前提
• 制約
• 変更予定ファイル（ready 段階で推奨）

変更予定ファイル = 変更対象ファイルの一覧と依存関係メモ（例：ソース⇔docs）。memo / forming 段階では任意。ready に達した段階で明示を推奨する。

issue の完了判断は本文項目ではなく、issue 状態と PR/CI/release flow で管理する。本文に専用の完了条件欄を持たない。

収束後も新しい受理情報が入れば issue 本文を再構築して更新する。issue は「生きた要求定義書」として扱う。

必要な見出しだけを使う。空セクションを強制しない。

memo モードの rapid intake（割り込み最小化パス）

人間が「黙って」「silent」「quick memo」やそれに準ずる意図を示した時に発動する。issue 起票そのものに人間の認知コストを掛けず、人間の本タスクを継続させるための rapid path である。

rapid path：

• title = ASCII 英語、bug/kind プレフィックスのみ（例：bug(rerank): cross-encoder not firing）。動詞構造を深掘りしない
• body = 観測事実 1〜3 行 + 再現ヒント 1〜2 行。purpose / premise / constraints / target files は書かない
• labels = 型ラベル 1つ（bug / enhancement / spec / docs / tips）+ 成熟度 = memo
• assignee = 未割当

判別条件：「この issue 起票自体が本タスクなのか、本タスクを中断して挟み込んだものなのか」

• 中断挟み込み → rapid path（本節）
• 本タスク → 通常の forming/ready intake

「黙って」を「full intake は実行しつつ会話だけスキップする」と解釈すると、人間が要求した割り込みコスト削減そのものが達成されない。memo 成熟度は「未完成で恥ずかしい状態」ではなく valid な resting state である。forming/ready への昇格は、後で issue 自体が focus になった時点で行えばよい（skills/operations-on-issue-maturity/SKILL.md）。

自律

チェックリスト = 人間の判断が必要なもの（実機テスト、運用確認など）に限る。AI が判定できる作業単位には sub-issue を使う。

Issue Maturity

（→ skills/operations-on-issue-maturity/SKILL.md。L4。トリガー時ロード）

ルール

memo / forming のまま実装開始の根拠にしない。

責務

親 issue もメモから開始してよい。収束した親 issue は目的・前提・制約を中心にまとめる。

親 issue のクローズ条件は構造的に判断する：子 issue（deferred 扱いのものを除く）がすべてクローズされたらクローズする。

前提の自発的検証（forming → ready）

spec body が forming 段階に達した時点で、前提セクションに未検証の技術的仮定（外部 API 仕様、ランタイム制約、ライブラリの挙動、プラットフォーム制限など）が含まれていないかチェックする。未検証の前提があれば、人間に指摘される前に AI が自発的に検証調査を開始する。forming → ready の遷移には、前提セクションの技術的仮定がすべて検証済みであることを要求する。

検証完了の判定基準は外部事実照合結果の有無にのみ適用する。主観的な confident 感は対象外とする。前提が「検証済み」と判定されるのは、docs・spec・ソース・ランタイム確認・既存 issue/PR 記録などの外部根拠を引いた場合のみである。「合っている感じがする」は検証ではない。

memo 成熟度は「未完成で恥ずかしい状態」ではなく valid な resting state である。memo 成熟度の issue を生む起票時 rapid path は Issue Format 側（rules/operations/main-agent-procedures.md の ## Issue format）が持つ。起票の瞬間に発火する面がそちらだからであり、本節が扱うのは後続の forming/ready への昇格判断である。

Sub-issue Rules

（→ skills/operations-on-sub-issue/SKILL.md。L4。トリガー時ロード）

ルール

sub-issue は AI が追跡・実行できる作業単位として使う。分割は責務で行う。粒度で分けない。同じ責務なら1つの issue にまとめる。複数ファイルにまたがっていても責務が同じなら1つでよい。

ブランチと issue ツリーの対応は「1親 issue = 1ブランチ」。sub-issue は親のブランチ上にコミットし、独自ブランチは作らない。別ブランチが必要なら別の親 issue を立てる。詳細はオペレーションレイヤー仕様書のブランチ運用セクションを参照。

gh issue develop はブランチ作成用であり、親 issue のみを対象とする。sub-issue のリンクには REST API を使用し、issue number ではなく内部数値 ID を渡す必要がある。

責務

同時タスクは親子 issue 構造を使う。複数タスクを同一セッションで並行進行する場合、独立した issue を個別に作成せず親子構造にまとめる。ブランチリンクの制約詳細はオペレーションレイヤー仕様書を参照。

並行実装の分割ルール

ready の issue が2つ以上あり、対象ファイルが重複する場合、AI はファイル競合を分析して並行可能な sub-issue 構成を自発的に提案する。共有ファイル（複数の並行 issue が触るファイル）への変更は「統合 issue」として独立させ、他の並行 sub-issue がすべて完了した後に実行する。各並行 sub-issue は新規ファイルか自分だけが触るファイルで閉じるようにする。

前提条件：Bash(*) が .claude/settings.json の permissions.allow に含まれていること（バックグラウンドサブエージェントの Bash 自動承認に必須）。親エージェントが事前にブランチを checkout した状態でサブエージェントを起動する。

並行競合分析：ready の issue が複数あるとき、実行前に変更予定ファイルの重複を分析する。重複なし＝並行安全とし、並行 sub-issue 構成を人間に提案する。一部重複あり＝共有ファイルへの変更を独立した統合 sub-issue として切り出すことを提案する。統合 sub-issue は並行 sub-issue 完了後に実行する（直列依存）。分析根拠は issue body の変更予定ファイル欄とし、未記載の場合は目的・前提から推定する。

sub-issue ごとに個別 PR が出てしまった場合の事後復旧

sub-issue を持つ親 issue で sub-issue ごとに個別 PR が出てしまった場合（仕様違反だが既に出荷後に発覚した状況）は、以下の事後復旧手順を取る：

1. 各 sub-issue ブランチを cherry-pick または rebase で1本の親ブランチに統合する
2. 不正なブランチの merge で auto-close された sub-issue を手動で再オープンする
3. 統合した親 PR の merge で改めてクローズさせる

これは応急復旧であり、per-sub-issue PR を通常運用として正規化してはならない。本筋は single parent PR 構造である（前述）。本節の手順が存在するのは、過去のセッションで誤運用が発生した実績があるためである（例：github-rag-mcp #198 / OAuth 移行 sub-PR #203 / #204 / #205 / #206 が per-sub-issue PR で実行され、親の連鎖 auto-close 失敗を引き起こした）。

focus pointer 対応表

issue 操作セクションは個別 skill（skills/operations-on-*/SKILL.md）として配置されている。skill description が auto-invocation トリガーを担う。

操作	自動起動される skill
作成・編集	skills/operations-on-sub-issue（Issue Format は rules/operations/main-agent-procedures.md 常駐）
閲覧	skills/operations-on-issue-maturity + skills/operations-on-sub-issue
閉じる	自動起動なし
子イシュー追加	skills/operations-on-sub-issue

配置対応表（L3 / L4 境界の参照ガイド）：

項目	実体ファイル	レイヤー	ロード形態
Task Issue Rules / Task Label Definitions	rules/task/task.md	L3	rules/ 常時
Agentic Search (#1380 統合; 旧 Research Strategy + Retrieval Orchestration を吸収)	skills/model-agentic-search/SKILL.md	L1	skill トリガー
Subagent Delegation	skills/task-subagent-delegation/SKILL.md	L3	skill トリガー
Subagent Prompt	skills/task-subagent-prompt/SKILL.md	L3	skill トリガー
Subagent Spawn	skills/task-subagent-spawn/SKILL.md	L3	skill トリガー
Subagent State Labels	skills/task-subagent-state-labels/SKILL.md	L3	skill トリガー
PR Review Judgment	skills/task-pr-review-judgment/SKILL.md	L3	skill トリガー
Issue Format	rules/operations/main-agent-procedures.md	L4	rules/ 常時
Issue Maturity	skills/operations-on-issue-maturity/SKILL.md	L4	skill トリガー
Sub-issue Rules	skills/operations-on-sub-issue/SKILL.md	L4	skill トリガー

---

言語レイヤー分離

issue / commit / PR の形式に適用する。

• タイトル：ASCII 英語のみ（識別レイヤー）
• ボディ：LI_PLUS_PROJECT_LANGUAGE（意味レイヤー）。issue 参照（#<issue番号>）は commit / PR のボディに含める
• タイトルは ASCII 英語の固定であり、LI_PLUS_PROJECT_LANGUAGE が解決する値ではない（別軸）

---

サブエージェント委任

（→ skills/task-subagent-delegation/SKILL.md。L3 Task Layer。トリガー時ロード。発火の瞬間で分割しており、委任プロンプト作成は skills/task-subagent-prompt/SKILL.md、spawn パラメータ（model 方針 / 並列幅上限）は skills/task-subagent-spawn/SKILL.md、subagent 側の state-machine label は skills/task-subagent-state-labels/SKILL.md）

委譲プロンプトの成果物言語

委譲プロンプトに成果物の例を含める場合、issue / PR / commit のタイトル例は ASCII 英語のみとする。body の例（issue / PR / commit body と wiki entry）は、対象成果物に適用される言語契約に従う。言語は、対象成果物への human の明示指示、thread で受容済みの合意、対象 repository / workspace の project-language default の順で解決し、対象 repository 固有の governance も同時に満たす。

host workspace の言語契約は LI_PLUS_REPO の governance を上書きしない。body は well-formed UTF-8 であり mojibake なく表示されることを検証し、ASCII-only 検証を適用しない。

この precedence が解決する値は、サブエージェント自身には届かない。CLAUDE.md と rules/** は subagent context へ全文届くが hook の発火出力は届かず、LI_PLUS_BASE_LANGUAGE / LI_PLUS_PROJECT_LANGUAGE はまさにその session-start hook が親のセッションへ出す値である（評価者側の同じ非対称は skills/evolution-parallel-agent-eval/SKILL.md Report shape の Language が持つ）。したがって親が spawn 前に解決し、その run の値としてプロンプトへ名指しする。解決後の言語名は本 skill にも他の Li+ source にも書かない——source は全 workspace へ配布され値は workspace ごとであるため、ここに書いた名前は他の workspace へ契約の顔で届く（Decision Structure distributed-source-carries-no-resolved-config-value）。拘束は逆向きにも働く。ある run のために名指しされた値は、サブエージェントが編集するファイルへ書き込む値ではない。それが #1704 で本節自身のリテラルへ値が再侵入した経路である。

再開プロンプトの権限境界

（→ skills/task-subagent-prompt/SKILL.md Resume-phase authority boundary）

auto / semi_auto で brake が報告した後、親は実装サブエージェントを再開して著者に指摘を裁かせる。再開メッセージも1つのプロンプトであり、trigger モードの注入と同じ理由が当てはまる——再開点における権限境界はゲート状態の判断であって手順ではないため、これを伝えることは「手順の詳細を伝えない」規則と衝突しない。

自動ロードされる規則に任せず注入する理由は、再開したサブエージェントが「実装を一通り走らせ終え、あと CI green 1回でマージ可能な PR に届く」セッションを持ったまま戻ってくることにある。最後まで済ませようとする引きはまさにそこで最も強い。#1628 は semi_auto の委譲サブエージェントがこの境界を越え、セルフレビュー投稿とマージまで実行した実測である。

注入するのは、そのモードの停止条件を skills/operations-on-pr-review/SKILL.md Delegated-subagent stop condition で自分で読み、行動前に言い直せという指示（親が運ぶのはポインタであってリテラルではない。リテラルを注入するには親が先にその skill を読む必要があり、それは親に禁じられている——rules/operations/main-agent-procedures.md の The bar and its pair。#1708 で唯一「移設」ではなく「ポインタ化」で修復された項目であり、理由はこの literal の実行主体がサブエージェント自身であること。#1628 が実測したのは auto-load 任せでは境界が持たなかったことであって、指示して読ませても持たないことではない。境界そのものは verbatim のまま残る次の2つの否定が担う）、「セルフレビューを実行も投稿もするな・マージするな」という2つの否定、および指摘の所在（PR URL と、親の統合コメント 1 本がそれを載せていること）の3点。新ルーティングの下で指摘を保持しているのは親だが、それでも再開メッセージへは貼らない——durable な写しはそのコメントであり、どこにも残らないメッセージは2つ目の写しの置き場として誤りだからである。brake 2 も同じ面に着くが経路が違い、評価者が自前の PR 面を持たないため親が名指しされた逸脱を PR へ投稿する。裁定への親の修正指示を伴う再開も、この3点をそのまま取る。修正そのものはそのメッセージの主題であって4つ目の注入項目ではなく、リストは閉じたままである。

この3点でリストは閉じており、閉じているのは列挙ではなく上記の基準による——注入対象になるのは再開点におけるゲート状態の判断、すなわち再開した著者に何が許されているかという境界か、著者自身のセッションからは見えない親側の状態である。その境界の内側で著者が行うことは手順であり、正本の置き場に留まる。サブエージェント自身の state ラベル遷移はこの隙間に見える事例である。まさにこの瞬間に発火するのに列挙されていないのは、それがサブエージェントの既に持つラベル権限の内側にあり、skills/task-subagent-state-labels/SKILL.md が mandate として保持しているためである。同 skill は auto-load され、トリガーに再開の瞬間を名指ししている。ここへ列挙すれば、その mandate の2つ目の写しをこのリストが持つことになり、ドリフトするのは常に2つ目の写しである。

auto-load が既に覆っている項目がこのリストへ格上げされるのは、この地点での逸脱が実測されたときであって、その見込みによってではない。rules/model/subtractive-structural-beauty.md は required か unnecessary の二値しか認めず、見込みが買えるのは required ではなく safety net である。(b) に対するその実測が #1628 であり、ラベル遷移に相当する観測は現時点で存在しない。疑いの対象が auto-load 面そのものの発火信頼性であるなら、直すべきはその面である。ここへ通せば、この種の疑いがすべてこのリストへ写される場所になり、リストに終わりが無くなる。

再構成フォールバック

再開には親が宛先にできる対象が要る。対象を持たない状態は2つある。ホストに再開機構が無い場合（resume_agent の無い Codex）と、親がフェーズ1のエージェント id を持たない場合である。後者は避けるべき事故ではなく、実装より後のセッションで裁定が走るときの常態である——id は spawn したセッションの文脈にあるため、その後に開いた親はそもそも持っていない（#1682 がこの経路を通り、条件の外側から本節を類推適用した）。どちらも同じフォールバックへ入り、アダプターはホストがどちらの形を生むかだけを名指しする。

フォールバックの形：親は著者役のサブエージェントを新規 spawn し、それが issue body・PR diff・PR コメント・ブランチ上の commit body（既に済んだ裁定を載せている）から再構成する。役割は変わらないため、上記3点はそのまま注入する。加わるのは1点だけで、それは cold なセッションが自力で供給できないためである——この spawn はフェーズ2から入る。変更は実装済みで PR は開いており、その仕事は裁定であって実装ではない（skills/task-subagent-delegation/SKILL.md の2フェーズ）。真の再開はここを述べない。自分のセッションそのものがその陳述だからである。それ以外に差は無い。停止条件も、2つの否定も、指摘の所在も同じで、親が指摘を貼らない点も変わらない。

これは skills/task-subagent-delegation/SKILL.md Autonomy の substrate-absence フォールバックとは別物である。あちらはサブエージェント能力そのものが無いときに発火して仕事を親へ移す。ここでは能力はあり、失われたのは再開先だけなので、仕事はサブエージェント側に留まる。id 喪失を親へ流せば裁定が著者から外れ、rules/evolution/initiator-autonomy.md Two-stage brake の Adjudication actor を壊す。

ルール

実装は常にサブエージェントへ委譲する。親は実装しない。 適用範囲は Li+ 全体であり、LI_PLUS_REPO の自己進化 PR も USER_REPO<N> のユーザーリポジトリも同じ。差分サイズによる例外を置かない。例外条項は適用の瞬間に判断を要求し、判断軸である規則の単純さを崩すためである（判断記録は wiki implementation-always-delegated）。受容した対価は、1行の変更でも委譲プロンプトの作成コストが乗ること。この規則が委譲する「実装」は issue の変更であり、委譲は PR が開いた時点では終わらない。CI green 後に brake の指摘を受けて行う修正も同じサブエージェントのもので、親がそれを再開して実行させる（rules/evolution/initiator-autonomy.md Two-stage brake の Adjudication actor）。親側の修正窓が存在しないため、その範囲を区切る条項も要らない——旧来の「親は裁いた指摘の要求する範囲であれば適用してよい」という carve-out は、狭めるのではなく削除する。著者が書き込むものは、ブランチへであれ PR へであれ、大きさに関わらず親の仕事ではない。

親エージェントは実装とオペレーション手順の実行をサブエージェントに委任する。親は issue 作成、issue クローズ、非 state ライフサイクルラベル（backlog / deferred）、issue の assignee、レビュー判断を保持する。

assignee は委譲の瞬間に親がセットする。spawn と同じ動作の中で gh issue edit {issue_number} -R {owner}/{repo} --add-assignee "@me" を実行する（親と委譲先サブエージェントは同一の GitHub actor として認証されるため、@me が issue を持つアカウントを指す）。前担当を外して入れ替えない——--add-assignee は加算であり、それが仕様である。assignee はラベルではなく state-machine subset にも入らない。in-progress はサブエージェント側のまま、その作業が始まった時点で立てるものであり、assignee と一緒に前倒ししない——走者が居ないうちに置かれた running-claim は false lock を生む。分割が非対称である理由と Assignees 欄の読み方は skills/task-subagent-state-labels/SKILL.md Actor axis が保持する。

execution_mode == auto または semi_auto の場合： サブエージェントは1つの委譲に対して2つのフェーズを実行する。フェーズ1はブランチ作成、実装、コミット、プッシュ、PR 作成、CI ループ。フェーズ2は brake の報告後に親が再開して始まり、親が投稿した統合指摘コメントを読み、各指摘を裁き、受入 / 却下とその理由を commit body に記録し、受け入れた分を修正、コミット、プッシュ、CI ループする。裁定への親の修正指示を伴う再開も同じフェーズ2に入り、親は収束に要るだけ開く（skills/evolution-parallel-agent-eval/SKILL.md Procedure の Inspect the adjudication、回数上限なし）。停止条件は各フェーズの末尾と各修正ラウンドの末尾で到達し、文言はいずれも同一である。

親が保持するのは brake 評価者の spawn、評価者の報告を 1 本の PR コメントへ統合すること、フェーズ間でのサブエージェント再開、裁定の検分、セルフレビュー、マージ判断であり、指摘の裁定は親側ではない。両モードのサブエージェント境界は同一で、違いは人間の PR チェック（semi_auto は minor / major に対して1つ加わる）だけであり、それは親側のゲートである。サブエージェントはどちらのフェーズでもセルフレビュー記録を投稿しない（PR コメントであるため）。フェーズ2ではそもそも PR コメントを一切投稿せず、裁定は commit body へ置くため、セルフレビュー記録と取り違えられうるものを PR 上に何も書かない。

execution_mode == trigger の場合： サブエージェントはブランチ作成、実装、コミット、プッシュ、PR 作成、CI ループ、セルフレビューを実行する。「マージ」はこの列挙に入らない。モードマトリクスの「マージ実行者 = AI」がこのモードで名指しているのは、PR 作成時点で GitHub auto-merge の handoff を有効化する行為であり（rules/operations/operations.md PR auto-merge policy）、それは「PR 作成」の項目が既に覆っている。マージ自体は人間の承認を受けて GitHub が発火させ、その時点でこのセッションは終わっている。

停止条件はモードで割れており、正本は skills/operations-on-pr-review/SKILL.md の Delegated-subagent stop condition にある（オペレーションレイヤー仕様書「PR レビュー」節を参照）。

サブエージェントに伝えない情報：手順の詳細、ブランチ名、コミットメッセージ、意図。意図は issue body に記載されている。

サブエージェントは issue クローズと非 state ラベル（backlog / deferred）変更を行わない。state-machine subset ラベル（in-progress / review-pending / waiting / blocked）は parent と共に編集する。

actor 軸（issue assignee）

（→ skills/task-subagent-state-labels/SKILL.md Actor axis。親側の発火手順は skills/task-subagent-delegation/SKILL.md ルール）

状態軸（in-progress ラベル）は「実行中かどうか」を読み、actor 軸（assignee）は「誰が実行しているか」を読む。単独稼働なら状態軸だけで完備するが、二者以上が同一 issue に触れうる構成になった瞬間に「実行中」だけでは不完備になり、actor 軸が load-bearing になる。

二軸は別 actor・別モーメントの別動作である。in-progress はサブエージェントが自分の作業開始時に立て、assignee は親が委譲の瞬間にセットする。サブエージェントは自己アサインしない。Assignees 欄に既に自分が入っている issue に着任するのは委譲の通常形であり、調整すべき状態ではない。

分割は非対称であり、前倒しするのは assignee だけである。2つを揃えて親へ寄せれば1箇所で済む、という単純化はこの段落が拒む対象そのものである。in-progress は「作業が走っている」という主張であり、実際に走らせている主体しか正しく主張できない。委譲の前に置くと、実装前の調査段階でサブエージェントが落ちた場合にその主張だけが生き残る——誰も走っていないのに「走っている」が残り、他の AI エージェントや別セッションの実行者はその issue を「いま作業中」と読んで触れず、誰も解除しない。false lock である。assignee はその種の主張をしない。「誰に渡ったか」であって「走っている」ではなく、加算的であり、現オーナーは handoff record から読んで assignee 欄単体からは読まない（後述）ため、残留した assignee が誰かを締め出すことはない。この非対称の上に分割が乗っているのであって、整理して片付けられる分担の都合ではない。

assignee を前倒しして得られるもの：Work start は実行者が読む必要のあるモーメントであり、#1714 ではその読みが実装読み込みの後ろへ着地した——spawn から6分経ってラベルも assignee も未発火で、検出したのは人間だった。委譲の瞬間は読む対象ですらなく、親が既にそこに立っている。actor 軸をそこへ移すのは、読みの上に検査を足すのではなく解釈そのものを消す操作である。in-progress は実行者が読むモーメントのまま残す。それは「作業が実際に始まった時刻」を名乗るラベルとして正しい側であり、その遅れはラベルが正確であることであって修理対象ではない。

assignee は加算のままとする。--add-assignee が前担当を外さないのは欠陥ではなく仕様であり、途中で引き継ぎが起きた事実自体が残すに値する情報である。新しい担当を入れるために前担当を外さない。

交代時は引き継ぎ記録を書く。本文 = 現在の担当（状態のスナップショット。rules/task/task.md の Issue body = latest requirements snapshot, not history log）／コメント = 交代イベントとその経緯（同ファイルの Comments are secondary）。

加算の帰結として、assignee 欄に自分がいることは自分が現担当であることを意味しない。現担当の判定は引き継ぎ記録が正である。新規セッションの AI が「in-progress だが着手した記憶が無い」issue に遭遇するのは異常ではなく正常な検知シグナルであり、引き継ぎ記録を読んで現担当が自分か他者かを確認してから再開判断に入る。assignee 欄はこのシグナルを担わない——親が委譲時にセットするため、自分の名前がそこにあるのは委譲されたばかりの作業の期待状態である。

責務

親はサブエージェントに issue URL を伝える。

rules/**/*.md は .claude/rules/ 経由で常時ロードされ、skills/**/SKILL.md は .claude/skills/ 経由でトリガー時に auto-invocation される。サブエージェントは明示的なファイル読み込みなしで、rules/skills が自律的にオペレーションルールを提供する。rules/skills が未生成の環境では、フォールバックとしてリポジトリの rules/**/*.md および skills/**/SKILL.md のパスを伝える。親からの詳細指示はオペレーションルールと矛盾するリスクがある。

issue body 更新

サブエージェントは実装中に前提・制約が変わった場合、issue body を更新できる。ただしラベル変更・issue クローズは行わない。

失敗報告

サブエージェントが失敗した場合、issue コメントに失敗報告を残す。報告形式は規定しない。

ブランチリンク

ブランチリンクのターゲットルールはオペレーションレイヤー仕様書のブランチ運用セクションを参照。

自律

サブエージェント機能が利用できない場合、親がオペレーションを直接実行する。すべてのルールは変わらず適用される。

これは substrate 欠如の fallback であって、上記「実装は常に委譲」の例外ではない。発火条件は機能の不在であり、「変更が小さい」という判断では決して発火しない。

---

PR レビュー判断

（→ skills/task-pr-review-judgment/SKILL.md。L3 Task Layer。トリガー時ロード）

責務

メインエージェントが PR レビューを判断するための基準。operations 手順（skills/operations-on-pr-review/SKILL.md 等、L4）を読まずにこの基準で判断する。

判断の前後でメイン自身が実行する行為——セルフレビューの formal record 投稿、承認待ちの確認手順（Review approval check）、マージ手続き——は、この面にも禁止された面にも無く、常駐の rules/operations/main-agent-procedures.md が正本である。本 skill が持つのは判断であり、判断が解放する行為はそちらが持つ。承認待ちの確認手順もその一つで、あちらがレビュー決定を検出し、その決定に対する判断はこちらにある。

判断根拠: issue body + PR diff + CI result

execution_mode == auto の場合（セルフレビュー）：

• CI pass 後、メインエージェントが PR diff を issue 要件と照合してレビューする。サブエージェントは実行しない。
• サブエージェント作成の PR = 別視点の検証として特に価値がある。
• 自身が作成した PR = マージ前の diff 再確認。
• pass → セルフレビューの formal record を投稿し、マージへ進む（rules/operations/main-agent-procedures.md の ## Self-review formal record / ## Merge Execution）。
• fail → 修正してリコミット（CI ループ再開）。

execution_mode == semi_auto の場合（セルフレビュー + 型別ゲート）：

• セルフレビューは auto と同じ。メインエージェントが実行し、サブエージェントは実行しない。
• pass で formal record を投稿するのも auto と同じ。その上にリリース種別に応じた人間チェックが重なる。ゲートの詳細（patch は直マージ / minor・major は人間チェック / PR 単位の例外 / L1 brake 2 の上書き）は rules/operations/execution-mode.md にある。

execution_mode == trigger の場合（外部レビュー）：

• APPROVED → PR 作成時点で有効化してある auto-merge の handoff が、この承認でマージを発火させる（rules/operations/main-agent-procedures.md の ## Merge Execution）。実行すべきマージコマンドは残っておらず、したがって委任すべきものも無い。
• CHANGES_REQUESTED → レビューコメントを読み、issue の要件と照合して対応を判断し、修正をサブエージェントに委任する。

---

進化

再構築・削除・最適化はすべて許容する。構造の一貫性のみ維持する。