spec(subagent): simplify delegation to hook-chain driven workflow

Li+agent.md

@@ -81,11 +81,14 @@ Purpose:
 - Main agent retains Model Layer + Task Layer (dialogue, requirements, issue management, review).
 
 When delegating to a subagent, convey:
-- Li+core.md path and Li+operations.md path (subagent reads both before any action).
-- Issue number, repository, working directory, intent.
-- Execute the full cycle (branch, implementation, commit, push, PR, CI loop) and report result.
-Do not convey: Li+github.md, branch name, commit message, step-by-step procedure, file scope constraint.
-Subagent reads the issue and operations rules, then decides execution details autonomously.
+- Li+core.md path, issue URL.
+Do not convey: Li+github.md, Li+operations.md path, branch name, commit message, step-by-step procedure, intent, file scope constraint.
+Intent is already in issue body.
+Subagent reads Li+core.md, then hook chain drives the rest:
+  self-assign → on_issue fires → Li+github.md loaded
+  branch create → on_branch fires → Li+operations.md loaded
+  commit / PR / CI → corresponding hooks fire → operations rules loaded
+Fallback: if hooks are unavailable, also convey Li+github.md path and Li+operations.md path.
 
 Subagent issue management:
 - Subagent may update issue body when premise or constraints change during implementation.

Li+claude.md

@@ -209,6 +209,17 @@ ${APPEND_MSG}"
   exit 0
 fi
 
+# on_branch (assignees): assign = act now = start of branch work → Li+operations.md Branch_And_Label_Flow
+if echo "$CMD_LINE" | grep -qE 'gh(\.exe)? (issue assign|api .*/issues/.*/assignees)'; then
+  CONTEXT=$(get_section \
+    "on_branch: Branch_And_Label_Flow re-read (assignees)" \
+    "$OPERATIONS_MD" \
+    "Branch And Label Flow" \
+    "Docs And Requirement Ownership")
+  emit_context "$CONTEXT"
+  exit 0
+fi
+
 # on_issue: gh issue → Li+github.md Issue_Flow section re-read
 if echo "$CMD_LINE" | grep -qE 'gh(\.exe)? (issue|api .*/issues)'; then
   CONTEXT=$(get_section \

Li+github.md

@@ -86,16 +86,11 @@ Issue Rules
   Parent close condition is structural = all child issues closed except deferred.
 
   Sub-issue = AI-trackable work unit.
-  Sub-issue does not get its own branch.
-  Session branch links to parent issue.
-  Multiple child issues can share one session branch.
-  Session branch = branch-side external memory and handoff surface.
-  Another AI may continue from parent issue + linked branch without relying on prior chat memory.
   Split by responsibility, not granularity.
+  Branch rules for sub-issues: see Li+operations.md Branch_And_Label_Flow.
 
   Simultaneous tasks require parent-child structure:
   If multiple tasks in same session = create parent issue + sub-issues.
-  Reason: gh issue develop links only one issue per branch.
   Do not create multiple independent issues for simultaneous work.
 
   Sub-issue API:
@@ -130,9 +125,14 @@ Issue Rules
   Subagent executes: branch, implementation, commit, push, PR, CI loop, merge.
 
   Convey to subagent:
-  Li+core.md path, Li+operations.md path, issue number, repository, intent.
-  Do not convey: Li+github.md, step-by-step procedure, branch name, commit message.
-  Subagent reads Li+core.md and Li+operations.md, then decides execution details.
+  Li+core.md path, issue URL.
+  Do not convey: Li+github.md, Li+operations.md path, step-by-step procedure, branch name, commit message, intent.
+  Intent is already in issue body.
+  Subagent reads Li+core.md, then hook chain drives the rest:
+    self-assign → on_issue fires → Li+github.md loaded
+    branch create → on_branch fires → Li+operations.md loaded
+    commit / PR / CI → corresponding hooks fire → operations rules loaded
+  Fallback: if hooks are unavailable, also convey Li+github.md path and Li+operations.md path.
   Detailed parent instructions risk conflicting with operations rules.
 
   Issue body update:
@@ -142,9 +142,7 @@ Issue Rules
   Failure reporting:
   On failure, subagent writes failure report as issue comment. Format is not specified.
 
-  Branch linking:
-  gh issue develop targets child issue, not parent.
-  Reason: PR merge auto-closes the linked issue. Linking parent causes premature parent close.
+  Branch linking: see Li+operations.md Branch_And_Label_Flow.
 
   If subagent capability is unavailable:
   Parent executes operations directly. All rules still apply.

Li+operations.md

@@ -68,6 +68,18 @@ Event-Driven Operations
   Issue link via gh issue develop is always required.
   gh issue develop must precede first push to GitHub.
 
+  Sub-issue branch rules:
+  Sub-issue does not get its own branch.
+  Session branch links to parent issue.
+  Multiple child issues can share one session branch.
+  Session branch = branch-side external memory and handoff surface.
+  Another AI may continue from parent issue + linked branch without relying on prior chat memory.
+  Reason: gh issue develop links only one issue per branch.
+
+  Branch linking target:
+  gh issue develop targets child issue, not parent.
+  Reason: PR merge auto-closes the linked issue. Linking parent causes premature parent close.
+
   On local error:
   gh issue develop may fail locally but succeed on GitHub side.
   Check linked branches before retrying:

docs/2.-Task.md

@@ -90,11 +90,9 @@ issue の完了判断は本文項目ではなく、issue 状態と PR/CI/release
 
 ### sub-issue
 
-sub-issue は AI が追跡・実行できる作業単位として使う。sub-issue にはブランチを作らない。セッションブランチは親 issue にリンクする。複数の子 issue の作業を同じセッションブランチで進めてよい。
+sub-issue は AI が追跡・実行できる作業単位として使う。分割は**責務**で行う。粒度で分けない。同じ責務なら1つの issue にまとめる。複数ファイルにまたがっていても責務が同じなら1つでよい。
 
-セッションブランチは branch 側の外部記憶であり、引き継ぎ面でもある。別の AI は親 issue とリンク済みブランチを読めば、以前の会話に依存せず途中から継続できる状態を目指す。
-
-分割は**責務**で行う。粒度で分けない。同じ責務なら1つの issue にまとめる。複数ファイルにまたがっていても責務が同じなら1つでよい。
+sub-issue のブランチルール（ブランチを作らない、セッションブランチは親 issue にリンクする等）はオペレーションレイヤー仕様書のブランチ運用セクションを参照。
 
 sub-issue API：
 
@@ -106,7 +104,7 @@ gh api repos/{owner}/{repo}/issues/{number} --jq '.id'
 gh api repos/{owner}/{repo}/issues/{parent}/sub_issues --method POST -f sub_issue_id={id}
 ```
 
-同時タスクは親子 issue 構造を使う。複数タスクを同一セッションで並行進行する場合、issue を個別に作成するとブランチリンクが1件にしか張れない（プラットフォーム制約）。
+同時タスクは親子 issue 構造を使う。複数タスクを同一セッションで並行進行する場合、独立した issue を個別に作成せず親子構造にまとめる。ブランチリンクの制約詳細はオペレーションレイヤー仕様書を参照。
 
 ### チェックリスト
 
@@ -148,7 +146,7 @@ issue / commit / PR の形式に適用する。
 
 ### 伝達内容
 
-親はサブエージェントに Li+core.md パス、Li+operations.md パス、issue 番号、リポジトリ、意図を伝える。Li+github.md、手順の詳細、ブランチ名、コミットメッセージは伝えない。サブエージェントが Li+core.md と Li+operations.md を読んで実行詳細を自ら決定する。親からの詳細指示はオペレーションルールと矛盾するリスクがある。
+親はサブエージェントに Li+core.md パスと issue URL を伝える。Li+github.md、Li+operations.md パス、手順の詳細、ブランチ名、コミットメッセージ、意図は伝えない。意図は issue body に記載されている。サブエージェントは Li+core.md を読み、以降は hook チェーンで自律的にオペレーションファイルを読み込む（self-assign → on_issue → Li+github.md、branch 作成 → on_branch → Li+operations.md、以降 commit / PR / CI も同様）。hook が発火しない環境では、フォールバックとして Li+github.md パスと Li+operations.md パスも伝える。親からの詳細指示はオペレーションルールと矛盾するリスクがある。
 
 ### issue body 更新
 
@@ -160,7 +158,7 @@ issue / commit / PR の形式に適用する。
 
 ### ブランチリンク
 
-`gh issue develop` は子 issue に対して実行する。親 issue にリンクしない。理由：PR マージ時にリンクされた issue が自動クローズされるため、親にリンクすると親が早期クローズされる。
+ブランチリンクのターゲットルールはオペレーションレイヤー仕様書のブランチ運用セクションを参照。
 
 ### フォールバック
 

docs/3.-Operations.md

@@ -54,7 +54,11 @@ trigger mode でも issue の作成・本文更新とブランチ準備は待た
 
 ### ブランチ作成
 
-issue リンクは常に必須。リンクは GitHub への初回 push より前に実行する。sub-issue にはブランチを作らない。ブランチを持つのは実際に PR を出す作業単位（親 issue）だけ。
+issue リンクは常に必須。リンクは GitHub への初回 push より前に実行する。
+
+sub-issue にはブランチを作らない。セッションブランチは親 issue にリンクする。複数の子 issue の作業を同じセッションブランチで進めてよい。セッションブランチは branch 側の外部記憶であり、引き継ぎ面でもある。別の AI は親 issue とリンク済みブランチを読めば、以前の会話に依存せず途中から継続できる状態を目指す。`gh issue develop` のリンクは1 issue につき1ブランチの制約があるため、同時タスクでは親子構造を使う。
+
+`gh issue develop` は子 issue に対して実行する。親 issue にリンクしない。理由：PR マージ時にリンクされた issue が自動クローズされるため、親にリンクすると親が早期クローズされる。
 
 ブランチ作成前にローカルとリモートの存在確認を行う。リモートに既存ブランチがある場合、後からリンクは張れない。
 

docs/4.-Adapter.md

@@ -63,7 +63,8 @@ settings.json の hook command はプロジェクトディレクトリにスペ
 
 | コマンドパターン | 再読込対象 | 追加動作 |
 |---|---|---|
-| `gh issue` / `gh api .*/issues` | タスクレイヤーの Issue Flow セクション | — |
+| `gh issue assign` / `gh api .*/issues/.*/assignees` | オペレーションレイヤーの Branch And Label Flow セクション | assign = 即行動 = ブランチ作業開始 |
+| `gh issue` / `gh api .*/issues`（assignees 以外） | タスクレイヤーの Issue Flow セクション | — |
 | `gh issue develop` / `git switch -c` / `git checkout -b` | オペレーションレイヤーの Branch And Label Flow セクション | — |
 | `git commit` | オペレーションレイヤーの Commit Rules セクション | — |
 | `gh pr create` | オペレーションレイヤーの PR Creation セクション | PR body への子 issue 参照の自動補完 |
@@ -127,9 +128,14 @@ bootstrap は次回セッションから有効。現セッションは Li+config
 
 ### 伝達内容
 
-メインエージェントはサブエージェントに Li+core.md パス、Li+operations.md パス、issue 番号、リポジトリ、作業ディレクトリ、意図を伝える。サブエージェントはブランチ作成から実装、コミット、プッシュ、PR 作成、CI ループまでの全サイクルを実行し、結果を報告する。
+メインエージェントはサブエージェントに Li+core.md パスと issue URL のみを伝える。Li+github.md、Li+operations.md パス、ブランチ名、コミットメッセージ、手順の詳細、意図、ファイルスコープ制約は伝えない。意図は issue body に既に記載されている。
 
-Li+github.md、ブランチ名、コミットメッセージ、手順の詳細、ファイルスコープ制約は伝えない。サブエージェントが issue とオペレーションルールを読み、実行詳細を自律的に決定する。
+サブエージェントは Li+core.md を読み込んだ後、hook チェーンが残りを駆動する：
+- self-assign → on_issue 発火 → Li+github.md 読込
+- branch create → on_branch 発火 → Li+operations.md 読込
+- commit / PR / CI → 対応 hook 発火 → operations ルール読込
+
+フォールバック：hook が利用できない場合は Li+github.md パスと Li+operations.md パスも追加で伝える。
 
 ### issue 管理