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 の skill として実体定義される。本レイヤーからは cross-reference として参照する。

---

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-format/SKILL.md 等、L4 定義）が auto-invocation で詳細な操作手順を補う。

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	着手中、実装または検証が進行中
backlog	受け入れ済み、着手時期未定
deferred	今回対応しない。あとで見直す

成熟度ラベル

「どこまで収束したか」を表す。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 に配置される個別 skill である。L3 からは、タスク管理の観点で要求される振る舞いを cross-reference として記述する。

• Issue Format の実体 → skills/operations-on-issue-format/SKILL.md
• Issue Maturity の実体 → skills/operations-on-issue-maturity/SKILL.md
• Sub-issue Rules の実体 → skills/operations-on-sub-issue/SKILL.md

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

Issue Format

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

ルール

issue タイトルは ASCII 英語のみとする。commit / PR タイトルと同一の言語規約に従う。 issue 本文は LI_PLUS_PROJECT_LANGUAGE で記述する。

責務

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 側（skills/operations-on-issue-format/SKILL.md）が持つ。起票の瞬間に発火する面がそちらだからであり、本節が扱うのは後続の 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-issue-format + skills/operations-on-sub-issue
閲覧	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	skills/operations-on-issue-format/SKILL.md	L4	skill トリガー
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 英語のみ（識別レイヤー）
• ボディ：日本語（意味レイヤー）+ issue 番号
• 日本語タイトル・英語のみボディを禁止する

---

サブエージェント委任

（→ 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 を上書きしない。liplus-language では issue / PR / commit body に日本語を含める。body は well-formed UTF-8 であり mojibake なく表示されることを検証し、ASCII-only 検証を適用しない。

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

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

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

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

注入するのは、そのモードの停止条件 literal（正本は skills/operations-on-pr-review/SKILL.md、ここに再掲しない）、「セルフレビューを実行も投稿もするな・マージするな」という2つの否定、および指摘の所在（PR URL と、評価者が PR コメントとして投稿済みであること）の3点。親は指摘そのものを再開メッセージへ貼らない——親の文脈を通すことこそがこの経路の削るコストである。brake 2 だけは例外で、評価者が投稿先の PR 面を持たないため親が名指しされた逸脱を inline で運ぶ。

ルール

実装は常にサブエージェントへ委譲する。親は実装しない。 適用範囲は 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）、レビュー判断を保持する。

execution_mode == auto または semi_auto の場合： サブエージェントは1つの委譲に対して2つのフェーズを実行する。フェーズ1はブランチ作成、実装、コミット、プッシュ、PR 作成、CI ループ。フェーズ2は brake の報告後に親が再開して始まり、評価者の PR コメントを読み、各指摘を裁き、受入または却下を PR 上で答え、受け入れた分を修正、コミット、プッシュ、CI ループする。停止条件は各フェーズの末尾で1回ずつ、計2回到達し、文言は両方とも同一である。

親が保持するのは brake 評価者の spawn、フェーズ間でのサブエージェント再開、セルフレビュー、マージ判断であり、指摘の裁定は親側ではない。両モードのサブエージェント境界は同一で、違いは人間の PR チェック（semi_auto は minor / major に対して1つ加わる）だけであり、それは親側のゲートである。サブエージェントはどちらのフェーズでもセルフレビュー記録を投稿しない（PR コメントであるため）。フェーズ2で PR に書く受入 / 却下の回答は指摘への著者の応答であって別の成果物であり、セルフレビュー記録ではないしそれに変わることもない。

execution_mode == trigger の場合： サブエージェントはブランチ作成、実装、コミット、プッシュ、PR 作成、CI ループ、セルフレビュー、マージを実行する。

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

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

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

actor 軸（issue assignee）

（→ skills/task-subagent-state-labels/SKILL.md Actor axis）

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

発火位置は in-progress 遷移の瞬間であり、ブランチ作成時ではない。ラベルと assignee は同一モーメントに同一の意味（「私がいま着手した」）で立ち、片方だけの発火は遷移の半実行である。

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

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

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

責務

親はサブエージェントに 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）を読まずにこの基準で判断する。

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

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

• CI pass 後、メインエージェントが PR diff を issue 要件と照合してレビューする。サブエージェントは実行しない。
• サブエージェント作成の PR = 別視点の検証として特に価値がある。
• 自身が作成した PR = マージ前の diff 再確認。
• pass → マージ実行へ進む。
• fail → 修正してリコミット（CI ループ再開）。

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

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

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

• APPROVED → マージ実行へ進む（サブエージェント利用可能ならマージ実行を委任）。
• CHANGES_REQUESTED → レビューコメントを読み、issue の要件と照合して対応を判断し、修正をサブエージェントに委任する。

---

進化

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