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	リリースマイルストーンに属さない運用ノウハウメモ

---

マイルストーン

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

層境界注記：マイルストーン運用の実体は L4 の skill にある。L3 からはタスク管理の観点で cross-reference する。

ルール

マイルストーンはリリース単位。同じリリースで出荷する issue をグループ化する。

すべての issue に作成時点でマイルストーンを付与する。ただし tips issue はマイルストーン不要。

マイルストーン名はバージョン番号（例: v1.2.0）。

sub-issue は親のマイルストーンを継承する。親にマイルストーンがあり子にない場合、同じマイルストーンを子に付与する。

リリースフロー完了前にマイルストーンを削除しない。

責務

該当するマイルストーンがない場合は、人間にどのマイルストーンに入れるか確認する、または新規作成を提案する。

説明には一行テーマ＋スコープの箇条書きを記載する。

マイルストーンのライフサイクル：

• 作成タイミング：人間が新しいリリーススコープを決定した時。
• 削除タイミング：リリースフロー完了後（リリース公開 + wiki sync 完了後）。closed の中間状態はスキップし、gh api -X DELETE で open のまま直接削除する（実機検証 2026-04-21）。
• 根拠：GitHub の milestone UI にはリリース後の情報保持価値がなく、監査証跡はリリースノート + PR / commit history に残る。closed milestone を残すと UI ノイズが蓄積するだけで retention benefit はゼロ。

---

削除判定

（→ rules/task/deletion-impact.md。常時ロード）

destructive 操作の判断軸を定義する。

ルール

復旧困難度 ∝ 削除注意度 をひとつの軸として扱う。中身の知識は二次変数。削除判定は双方向に壊れる（消すべきでないものを消す destructive / 消すべきを残す preserve-by-default）ため、familiarity ではなく blast radius で calibrate する。

責務

削除前に単一質問を通す：「これを間違って消したら何が壊れる？何分で復旧できる？」。

blast radius = 壊れる範囲 × 復旧コスト の二軸で判定する。片方だけで判定しない。

• git-tracked は広く壊れても revert / checkout で即時復旧可能 → 真の警戒度は中
• local かつ non-git-tracked かつ意味のある設定・状態は recovery 経路がゼロ → 真の警戒度は高
• git 外かつ不可逆（外部送信・本番データ・release 昇格など）→ 真の警戒度は最高

自律

「source of truth」「base layer」のような重要性ラベルに引っ張られて、git-tracked な中央ファイルを最高警戒に誤分類しない。論理的依存の上位 ≠ 復旧困難度。真の最高警戒は不可逆な外部副作用に限定する。

---

Research Strategy

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

情報取得時の判断指針。調査タスクや issue 調査の発火点で auto-invocation される。

自律

情報源の性質区別

情報源	性質
GitHub（issues, PRs, commits）	判断ログ。誰がいつ何をなぜ決めたかの記録
github-rag-mcp（利用可能な場合）	issues, PRs, releases, docs, commit diff に対する hybrid retrieval（意味検索とキーワード検索を併用する dense + sparse 構成）。対象が不明な場合の発見に使用
Web（ドキュメント、仕様書、検索結果）	一次情報源
モデル知識	フォールバック。権威ではない

github-rag-mcp の二つの検索面

github-rag-mcp は相補的な二つの検索面を持つ。

検索面	対象	問いの形
live .md 面	spec / docs の現在スナップショット	「今どうなっているか」
commit diff 面（judgment-history）	commit diff の時系列デルタ	「いつ現れたか・いつ消えたか・なぜ変わったか」

commit diff 面は、削除されたファイルや .md 以外の拡張子を持つファイルも「過去の実体」として追跡対象に含める。live .md 面では失われる判断履歴を、append-only な commit diff 経由で保持する。

検索面スコープ

live .md 面は現在スナップショット検索にのみ適用する。 commit diff 面は judgment-history 検索（時系列デルタ、削除済みコンテンツ、.md 以外の拡張子）にのみ適用する。 二つの面は相補関係にあり、互いに代替しない。 どの発火点でどの面に問い合わせるかの検索トリガー設計は、本セクションの範囲外とする（別途設計対象）。

検証優先

事実が不確かな場合は、先に外部で検証する。正しさの最適化は速度の最適化に優先する。

文脈保全

メインの作業文脈を保全する検索経路を選ぶ。サブエージェントが利用可能な場合は自発的にサブエージェントを並列投入して検索する。利用不可の場合は直接検索する。戦略は環境非依存、実行手段は環境に応じて変わる。

自発的並列調査

調査対象が issue の場合：判断を述べる前に、サブエージェントを並列投入して関連 issue・PR・diff を取得する。人間に個別の取得指示を求めない。

サブエージェントの利用可否は実行手段を決めるが、自発的に調査を開始する姿勢は環境によらず必須である。

---

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 は「生きた要求定義書」として扱う。

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

自律

チェックリスト = 人間の判断が必要なもの（実機テスト、運用確認など）に限る。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 モードの 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
• milestone = 未割当。割当は後で forming → ready 昇格時に行う
• assignee = 未割当

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

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

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

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-milestone + 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/ 常時
Deletion Impact	rules/task/deletion-impact.md	L3	rules/ 常時
Research Strategy	skills/task-research-strategy/SKILL.md	L3	skill トリガー
Subagent Delegation	skills/task-subagent-delegation/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 トリガー
Milestone Rules	skills/operations-on-milestone/SKILL.md	L4	skill トリガー

---

言語レイヤー分離

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

• タイトル：ASCII 英語のみ（識別レイヤー）
• ボディ：日本語（意味レイヤー）+ issue 番号
• 日本語タイトル・英語のみボディを禁止する

---

サブエージェント委任

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

ルール

親エージェントは実装とオペレーション手順の実行をサブエージェントに委任する。親は issue 作成、issue 管理（ラベル変更・クローズ）、レビュー判断を保持する。

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

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

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

サブエージェントはラベル変更・issue クローズを行わない。

責務

親はサブエージェントに 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 コメントに失敗報告を残す。報告形式は規定しない。

ブランチリンク

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

自律

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

---

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 == trigger の場合（外部レビュー）：

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

---

進化

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