2. Task

タスクレイヤー仕様書

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

---

issue 運用

ルール

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

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

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

issue に実装を書かない。

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

責務

issue 運用ルール（task/Li+issues.md の [Working with Issues]）は li-plus-issues skill 経由で読み込まれる。skill auto-invocation により、issue に関連する対話が発生した時点で自動的にコンテキストに追加される。

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

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

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

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

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

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

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

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

自律

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

---

ラベル定義

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

ルール

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

責務

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

ライフサイクルラベル

「いつ着手するか」を表す。状態変化時に適用する。

ラベル	意味
in-progress	着手中、実装または検証が進行中
backlog	受け入れ済み、着手時期未定
deferred	今回対応しない。あとで見直す

成熟度ラベル

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

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

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

タイプラベル

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

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

---

マイルストーン

ルール

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

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

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

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

リリース前にマイルストーンをクローズしない。

責務

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

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

作成タイミング：人間が新しいリリーススコープを決定した時。クローズ：リリースが公開された時。

---

Research Strategy

情報取得時の判断指針。li-plus-issues skill 経由で読み込まれる。

自律

情報源の性質区別

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

検証優先

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

文脈保全

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

自発的並列調査

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

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

---

issue 操作

issue 操作（Issue Format, Issue Maturity, Sub-issue Rules）は operations/Li+github.md に配置され、.claude/rules/ 経由で常時コンテキストに存在する。PostToolUse hook が focus pointer として操作タイミングで該当セクションへの注意喚起を行う。

Issue Format

ルール

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

ルール

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

責務

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

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

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

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

Sub-issue Rules

ルール

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 の変更予定ファイル欄とし、未記載の場合は目的・前提から推定する。

focus pointer 対応表

issue 操作セクションは operations/Li+github.md に配置されている（rules/ で常時コンテキスト）。hook は focus pointer として該当セクションへの注意喚起を行う。

操作	focus 対象（operations/Li+github.md 内）
作成・編集	[Issue Format] + [Milestone Rules] + [Sub-issue Rules]
閲覧	[Issue Maturity] + [Sub-issue Rules]
閉じる	focus 不要
子イシュー追加	[Sub-issue Rules]

Issue Rules、Label Definitions、Research Strategy は li-plus-issues skill（.claude/skills/）に配置され、skill auto-invocation で必要時に読み込まれる。Milestone Rules は operations/Li+github.md に配置され、issue 作成・編集時の focus pointer で注意喚起される。

---

言語レイヤー分離

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

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

---

サブエージェント委任

ルール

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

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

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

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

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

責務

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

Li+core.md と Li+github.md は .claude/rules/ 経由で自動ロードされ、Li+issues.md は .claude/skills/ 経由で自動ロードされる。サブエージェントは明示的なファイル読み込みなしで、rules/skills が自律的にオペレーションルールを提供する。rules/skills が未生成の環境では、フォールバックとして model/Li+core.md パス、task/Li+issues.md パス、operations/Li+github.md パスも伝える。親からの詳細指示はオペレーションルールと矛盾するリスクがある。

issue body 更新

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

失敗報告

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

ブランチリンク

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

自律

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

---

PR レビュー判断

責務

メインエージェントが PR レビューを判断するための基準。operations 手順を読まずにこの基準で判断する。

判断根拠: 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 の要件と照合して対応を判断し、修正をサブエージェントに委任する。

---

進化

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