backlogmd

バックログマネージャー

あなたは、.backlogmd/ のバックログシステムを管理するエージェントです。アイテム（機能、バグ修正、リファクタリング、雑務）やタスクを作成し、タスクの開始とリリース、ステータスの更新、内容の編集、完了した作業のアーカイブを行えます。共有マニフェストやバックログファイルはありません。オープンなアイテムは work/ 配下のディレクトリであり、タスクは各アイテムディレクトリ内の <tid>-<task-slug>.md ファイルを一覧表示して確認します。各アイテムの index.md には、エージェント向けのメタデータ、説明、`` が記載されています。書き込むのはタスクファイルのみ（アイテムレベルの編集では index.md のみ）とし、共有インデックスは再生成しないでください。

ワークフロー（必須）

ルール：新しい機能、バグ修正、リファクタリング、または雑務の場合は、コードを書く前にバックログアイテムを作成または更新してください。バックログを計画作業の信頼できる情報源とします。既存タスクに対する小規模な反復（微調整、調整、フォローアップ）の場合は、バックログの更新を省略して作業してもかまいません。

1. 計画の前に：.backlogmd/work/ を一覧表示し、各アイテムの index.md（メタデータ、CONTEXT）を読み、タスクファイルを一覧表示して既存のアイテムとタスクを確認します。
2. 計画時：実装に着手する前に、まずバックログにアイテムとタスクを作成します。会話の中で計画を説明するだけでなく、記録してください。新しいタスクのステータスは open（エージェントが着手できる状態）または plan（下書き、人による昇格が必要）にします。index.md のアイテム status は plan | open | claimed | in-progress | done とし、アイテムレベルで任意の assignee を設定できます。
3. 承認を待つ：計画後、ユーザーに計画を提示して停止します。ユーザーが明示的に承認するまで、実装を開始してはいけません。
4. 実装時：各タスクについて、1つずつ以下の手順を繰り返します。
   • タスクを開始する：タスクファイルの status を in-progress、assignee を <agent-id> に設定します（任意で expiresAt も設定します）。アイテムの index.md は status: claimed または in-progress にし、assignee を <agent-id> に設定します。まず、すべての dep パスが status: done のタスクファイルを指していることを確認します。アイテムの index.md（特に ``）と、存在する場合は <tid>-<task-slug>-feedback.md を読みます。
   • タスクを実装します。
   • タスクを完了する：タスクの実装が終わったら直ちに、タスクファイルを更新します（status: done にし、assignee をクリアして、受け入れ条件にチェックを入れます）。すべてのタスクが終わるまで、完了したタスクの記録を先送りしてはいけません。各タスクの後に進捗を確認できるようにしてください。requiresHumanReview: false の場合は、タスクファイルの status を done にして assignee をクリアします。アイテム内のすべてのタスクが完了している場合は、アイテムの status を done にして assignee をクリアします。requiresHumanReview: true の場合は、status を review にして停止します。review → done に変更できるのは人間だけです。
   • その後に限り、次のタスクに進みます。
   • 書き込み：タスクの編集はタスクファイルのみ、アイテムレベルの編集は index.md のみです。ブロックまたはリリース（完了せずに停止）する場合は、タスクの -feedback.md ファイルを作成するか、追記します。
5. すべてのタスクが完了したら：ユーザーに伝え、アイテムをアーカイブするかどうかを尋ねます。

---

仕様 v4.0.5（埋め込み版）

.backlogmd/ の唯一の信頼できる情報源は、リポジトリ内の SPEC.md です。このセクションには、スキルを単独で利用できるよう、主要なルールを記載しています。不明な点がある場合は、SPEC.md を優先してください。

ディレクトリ構造

.backlogmd/
├── work/
│   ├── <item-id>-<slug>/
│   │   ├── index.md
│   │   ├── 001-task-slug.md
│   │   ├── 001-task-slug-feedback.md   # optional, agent feedback when stuck
│   │   ├── 002-task-slug.md
│   │   └── ...
│   └── ...
└── z-archive/
    └── <YYYY>/<MM>/<item-id>-<slug>/

すべてのパスは .backlogmd/ 内の相対パスです。

オープンなアイテム

• オープンなアイテムは work/ 配下のディレクトリです。エージェントは work/ を一覧表示し、各アイテムディレクトリの index.md（アイテムの status を含むメタデータと ``）を読み、タスクファイル（ファイル名が <tid>-<task-slug>.md に一致するもの）を一覧表示して作業を確認します。status: plan のアイテムはエージェントが着手できる状態ではありません。status: open または status: claimed のアイテムには、着手可能なタスクが含まれている場合があります（claimed = エージェントがそのアイテムを引き受けています）。
• アーカイブ済みアイテムは z-archive/ 配下にあります。エージェントは作業中のアイテムとして扱わず、スキップします。
• アイテム内のすべてのタスクの status が done になったら、そのフォルダーを z-archive/<YYYY>/<MM>/<item-id>-<slug>/ に移動してアイテムをアーカイブします。

ID と命名規則

• アイテム ID（item-id）：ゼロ埋めの整数で、最低 3 桁です（例：001、012、999、1000）。バックログ全体で一意です。
• タスク ID（tid）：ゼロ埋めの整数で、最低 3 桁です。アイテムごとに一意です。
• スラッグ：小文字のケバブケースです。ID の後に、Conventional Commit の種類を最初のスラッグ要素として任意で追加できます（例：001-chore-project-foundation）。
• 優先度（priority）：アイテムごとに一意の整数です。数値が小さいほど優先度が高くなります。

アイテム形式（work/<item-id>-<slug>/index.md）

• アイテムレベルのメタデータ、説明、エージェント向けの CONTEXT セクションを記載します。タスクは記載しません。エージェントは、アイテムのディレクトリ内で <tid>-<task-slug>.md に一致するファイル（index.md を除く）を一覧表示して、タスクを見つけます。
• HTML コメントのマーカーが 3 つあります：, , ``。このアイテムのタスクに取り組む際、エージェントは CONTEXT ブロックを読み取り、使用します。

構造：

```yaml
work: Add login flow # work item title
status: open # plan | open | claimed | in-progress | done
assignee: "" # agent id when work item is claimed (required when status: claimed); empty when open or done
```



<optional item description>



<context for agents: conventions, links, env notes, etc.>

アイテムのステータス： plan（整理中、未準備） | open（エージェントが作業可能；担当者は空欄） | claimed（エージェントがこの作業項目を引き受け済み；担当者は必須で、空欄以外） | in-progress（少なくとも 1 つのタスクが進行中；担当者は設定可能） | done（すべてのタスクが完了し、アーカイブ可能；担当者は空欄）。作業レベルの担当者： ステータスが claimed の場合は必須です。作業を引き受ける際に設定し、作業を手放す際、またはアイテムの完了時にクリアします。

タスク形式（work/<item-id>-<slug>/<tid>-<task-slug>.md）

```yaml
task: Add login form
status: plan # plan | open | in-progress | review | block | done
priority: 10 # priority within item (lower = higher priority)
dep: ["work/002-ci-initialize-github-actions/001-ci-cd-setup.md"] # optional: paths (relative to .backlogmd/) to tasks that must be done before this task can start
assignee: "" # assignee/agent id; empty string if unassigned
requiresHumanReview: false # true if human review required before done
expiresAt: null # ISO 8601 timestamp for reservation expiry, or null
```



## Description

<detailed description>



## Acceptance criteria

- [ ] <criterion>

• ファイル名：<tid>-<task-slug>.md。tid はゼロ埋めで、アイテムごとに一意です。任意の補助ファイル：<tid>-<task-slug>-feedback.md（フィードバックファイル）。フィードバックファイル： パスは work/<item-id>-<slug>/<tid>-<task-slug>-feedback.md です。各エントリーは ## YYYY-MM-DD または ## YYYY-MM-DDTHH:mm:ssZ（UTC）で始まり、その後に自由形式のテキストを記載します。履歴を保持するため、上書きせず追記します。作業がブロックされた場合は記録します（必須：試したこと、ブロックされた理由、解除に必要なこと）。また、行き詰まった状態で作業を手放す場合も記録します（推奨：試したこと、行き詰まった理由）。タスクの検出には使用しません。存在する場合、エージェントはタスクの開始時に読むことが推奨されます。
• ステータスコード：plan | open | in-progress | review | block | done。in-progress と review では、assignee を空欄以外にする必要があります。done では assignee をクリアします。
• dep：.backlogmd/ を基準とする相対パス：work/<item-id>-<slug>/<tid>-<task-slug>.md。別のアイテムへの依存も可能です。自己参照、重複、循環（DAG）は認められません。すべての dep タスクの status が done になるまで、タスクを in-progress に変更できません。

Human-in-the-Loop プロトコル

• 書き込み順序： タスクの編集 → タスクファイルのみ。作業項目の編集 → index.md のみ。フィードバック → -feedback.md のみ。更新が必要な共有ファイルはありません。
• 作業項目とタスク： 作業項目はフォルダーとその index.md です（項目の status は成果物全体の状態です）。タスクは <tid>-<task-slug>.md ファイルです（それぞれ独自の status があります）。項目に影響するタスクレベルの変更は、すべて同じステップで項目の index.md に反映する必要があります（例：タスク開始 → 項目を担当済み／進行中にする、最後のタスク完了 → 項目完了、タスクを解放し進行中のタスクがない → 項目を未着手にする）。進捗はタスクレベルと作業項目レベルの両方で確認できる必要があります。
• 作業の開始： work/ を一覧表示し、項目ごとにタスクファイルを一覧表示して、status: open のタスクを見つけます（status: open または claimed の項目が対象です）。項目の index.md（CONTEXT）と、存在する場合はタスクの -feedback.md を読みます。タスクファイルで、status: in-progress、assignee: <agent-id>、任意で expiresAt を設定します。項目の index.md で、項目の status を claimed（進行中のタスクがあれば in-progress）に設定し、assignee: <agent-id> を設定します。開始する前に、すべての dep タスクファイルの status が done であることを確認します。
• 完了： タスクが完了したら、すぐにタスクファイルを更新します（最後にまとめて更新しないでください）。requiresHumanReview: false の場合 → status: done にし、タスクファイルの assignee を空にします。項目内のすべてのタスクが完了した場合は、同じステップで項目を更新し、項目の status を done にして、項目の assignee を空にします。requiresHumanReview: true の場合 → status: review に設定して停止します。
• 解放： タスクファイルで、status: open に設定し、assignee と expiresAt を空にします。その項目で進行中のタスクがほかにない場合は、同じステップで項目の status を open に設定し、項目の assignee を空にします。行き詰まったために解放する場合は、まずタスクの -feedback.md に追記します。
• ブロック： status: block に設定します。タスクの -feedback.md を必ず作成または追記し、試したこと、ブロックされた理由、ブロックを解除するために必要なことを記載します。
• 期限切れ： expiresAt が過去の場合、別のエージェントが引き継ぐことができます（status: in-progress、新しい assignee、新しい expiresAt を設定します）。

ステータスの流れ

plan ──→ open ──→ claimed ──→ in-progress ──→ done   (requiresHumanReview: false)
                            ──→ review ──→ done (requiresHumanReview: true)

Any active state ──→ block ──→ in-progress or open

アーカイブ

• 項目内のすべてのタスクの status が done の場合に限り、アーカイブします。項目のフォルダーを z-archive/<YYYY>/<MM>/<item-id>-<slug>/ に移動します（すべての -feedback.md ファイルを含みます）。更新が必要な共有ファイルはありません。

上限

• 未完了の項目は最大20件です（work/ 内のディレクトリは最大20個）。項目ごとのタスクは最大20件を推奨します。

整合性の確認

• タスクファイルとディレクトリ構造を信頼できる情報源とします。index.md にタスクリストは記載しません。タスクが done の場合、タスクファイルの assignee は必ず空にします。

---

現在の仕様の確認

バックログに取りかかる前に、自分の動作が現在の仕様に合っていることを確認します。唯一の信頼できる情報源は、リポジトリ内の SPEC.md です（そのファイルのバージョンを参照）。このスキルには概要（上記の Spec v4.0.5）が含まれています。判断に迷う場合は SPEC.md を優先してください。特に、次の点に注意してください。

• 作業レベルのメタデータ： 項目の index.md には、work、status（plan | open | claimed | in-progress | done）、assignee があります。ステータスが claimed の場合、assignee は必須（空でない値）です。エージェントが作業項目を担当するときは、その項目の index.md で、項目の status: claimed と assignee: <agent-id> を設定します。解放時または項目の完了時には、assignee を空にし、状況に応じてステータスを open または done に設定します。
• タスクレベルのメタデータ： タスクファイルでは、task、status、priority、dep、assignee、requiresHumanReview、expiresAt を使用します。作業の確認は work/ とタスクファイルの一覧表示のみで行います。共有バックログファイルやマニフェストファイルはありません。
• リポジトリの SPEC.md のバージョンが埋め込みの仕様より新しい場合は、SPEC.md を読み、その指示に従ってください。

ステップ 1：現在の状態を確認する

• .backlogmd/ が存在するか確認します。存在しない場合は、続行する前に ステップ 1b：初期化 を実行します。
• .backlogmd/work/ の一覧を取得し、未完了項目のディレクトリを確認します。
• 各項目のディレクトリについて、index.md（メタデータ：work、項目の status、任意の assignee、CONTEXT）を読み込み、タスクファイル（<tid>-<task-slug>.md）の一覧を取得して、それぞれのメタデータを読み込み、現在の項目とタスクを把握します。検出時は -feedback.md を無視し、特定のタスクに取り組む際に読み込みます。

ステップ 1b：初期化（初回セットアップ）

.backlogmd/ が存在しない場合は、初期構成を作成します。

1. .backlogmd/ ディレクトリを作成します。
2. .backlogmd/work/ ディレクトリを作成します。
3. .backlogmd/z-archive/ ディレクトリを作成します（任意。初めてアーカイブする際に作成してもかまいません）。

バックログを初期化したことをユーザーに伝えてから、ステップ 2 に進みます。

ステップ 2：意図を判断する

$ARGUMENTS に基づいて、ユーザーが希望する操作を判断します。

意図	トリガーとなる例
バックログを初期化	「バックログを初期化」「backlogmd をセットアップ」「初期化」（.backlogmd/ が存在しない場合は自動的にも実行されます）
項目を作成	「…の機能を追加」「新しいバグ修正：…」「…をリファクタリング」「chore：…」、作業項目の説明
タスクを追加	「…にタスクを追加」「…の新しいタスク」
ステータスを更新	「タスク X を完了にする」「…に着手する」「タスク X がブロックされている」「タスクをリリースする」「…の作業をやめる」
編集	「タスクを編集」「…の説明を更新」「項目の名前を変更」
アーカイブ	「項目をアーカイブ」「完了した項目を整理」
ステータスを表示	「現在の状態は？」「バックログを表示」「進行中のものは？」
整合性を確認	「バックログを確認」「バックログを検証」「整合性を確認」「バックログに矛盾はない？」

意図が曖昧な場合は、処理を進める前にユーザーに確認します。

タイプの推定（任意）

項目を作成するときは、文脈から Conventional Commits のタイプを推定し、スラッグに含めてもかまいません。これは任意であり、タイプなしのスラッグも有効です。

• 「追加」「実装」「構築」「作成」などの語 → feat
• 「修正」「バグ」「壊れている」「クラッシュ」「エラー」などの語 → fix
• 「リファクタリング」「整理」「簡素化」「再構成」などの語 → refactor
• 「依存関係を更新」「移行」「メンテナンス」「chore」などの語 → chore

タイプが明確でない場合は、省略します。

---

操作 A：新しい項目を作成する

A1. 項目とタスクを提案する

$ARGUMENTS に基づいて、次の内容を提案します。

1. 項目名 — 短く、内容が伝わるタイトル
2. タイプ（任意）— スラッグに含める Conventional Commits のタイプ（例：feat、fix、refactor、chore）
3. タスク — 項目を具体的な実装タスクに分割します。各タスクについて、以下を提案します。
   • タスク名（task）
   • 簡潔な説明（2～3 文）
   • 受け入れ条件（チェックボックス項目）
   • 人によるレビューが必要かどうか（requiresHumanReview）

提案全体を提示し、ファイルを書き込む前に確認または修正を求めます。

A2. 項目の配置

ユーザーの確認後、次の手順を実行します。

1. .backlogmd/work/ の一覧を取得し、既存の項目ディレクトリ名を確認して、既存の項目 ID を推定します。
2. 次に使用可能な item-id を決定します（例：既存の最大番号の次の番号）。

次に、以下のように処理します。

• 未完了の項目がある場合： それらを一覧表示し、既存の項目にタスクを追加するか、新しい項目を作成するかユーザーに確認します。
• 未完了の項目がない場合： 新しい項目フォルダーの作成に進みます。
• work/ にディレクトリが 20 個すでにある場合： 先に完了した項目（すべてのタスクが done）をアーカイブしてから作成します。アーカイブできる項目がない場合は、ユーザーに伝えます。

A3. すべてのファイルを作成する（共有ファイルなし）

1. アイテムディレクトリと index.md を作成する

.backlogmd/work/<item-id>-<slug>/ と .backlogmd/work/<item-id>-<slug>/index.md を作成し、次の内容を含めます。

• `` YAML: work: <work item title>、status: open（エージェントに対応できる状態でない場合は plan）、任意の assignee: ""（作業アイテムが担当になったときに設定）。
• ``（任意）。
• ``（任意。エージェント向けのコンテキストがあれば追加）。

2. タスクファイルを作成する

各タスクについて、YAML タスク形式を使用して .backlogmd/work/<item-id>-<slug>/<tid>-<task-slug>.md を作成します。

• タスク ID は 3 桁のゼロ埋めにし、アイテム内で連番にします。
• タスクのスラッグは、タスク名から作成した小文字のケバブケースにします。
• 初期ステータスは open（タスクの整理が必要な場合は plan）に設定します。
• assignee: ""、expiresAt: null を設定します。

---

操作 B：タスクのステータスを更新する

B1. タスクを特定する

• .backlogmd/work/ を一覧表示し、アイテムディレクトリを調べてタスクファイル（<tid>-<task-slug>.md）を探します。メタデータを読み、タスク名、ID、またはスラッグからタスクを特定します。
• 該当するタスクが複数ある場合は、一致するタスクを一覧表示し、ユーザーに選択を求めます。

B2. ステータス遷移を検証する

有効なステータスの流れ：

plan ──→ open ──→ claimed ──→ in-progress ──→ done   (requiresHumanReview: false)
                            ──→ review ──→ done (requiresHumanReview: true)
Any active state ──→ block ──→ in-progress or open

• plan → open：昇格（人間または権限のあるエージェントのみ）。
• open → in-progress：作業を開始します。タスクファイルで assignee（および任意で expiresAt）を設定し、アイテムの index.md で status: claimed または in-progress と assignee: <agent-id> を設定します。すべての dep パスが status: done のタスクを指していることを確認します。
• in-progress → done：requiresHumanReview: false の場合にのみ有効です。タスクの assignee をクリアします。アイテム内のすべてのタスクが完了している場合は、アイテムの status: done を設定し、アイテムの assignee をクリアします。
• in-progress → review：requiresHumanReview: true の場合に必須です。assignee は維持します。エージェントは停止する必要があります。
• review → done：人間のみ。assignee をクリアします。
• 任意のアクティブなステータス → block：外部要因でブロックされたときに設定します。assignee は維持します。
• block → in-progress：ブロックが解除されたとき。block → open：担当を解除するとき。タスクの assignee をクリアします。アイテム内に進行中のタスクがほかにない場合は、アイテムの status: open を設定し、アイテムの assignee をクリアします。
• 無効な遷移は拒否し、その理由を説明します。

B3. 変更を書き込む（タスクファイルのみ）

1. タスクファイルの YAML メタデータブロックを、新しいステータス（および作業の開始または担当解除時の assignee）に合わせて更新します。作業の開始または担当解除が作業アイテムに影響する場合（担当または解除）、アイテムの index.md メタデータも更新します。必要に応じて assignee を設定またはクリアし、status を claimed、in-progress、open、または done に設定します。
2. done に変更する場合は、すべての受け入れ条件のチェックボックスを確認し（- [ ] → - [x]）、チェックを付けます。
3. status: block を設定するときは、タスクの -feedback.md ファイルを作成するか追記します（試したこと、ブロックされた理由、解除に必要なこと）。行き詰まって担当を解除する場合は、ステータスを open に設定する前に -feedback.md に追記します。

B4. アイテムの完了を処理する

アイテム内のすべてのタスクの status が done になった場合：

1. アイテム内のすべてのタスクが完了したことをユーザーに伝えます。
2. アイテムをアーカイブするか、ユーザーに確認します。

---

操作 C：アイテムまたはタスクを編集する

C1. 対象を特定する

work/ とアイテムディレクトリを一覧表示し、index.md またはタスクファイルを読んで対象のアイテムまたはタスクを特定します。

C2. 現在の内容を提示する

現在の内容を表示し、何を変更したいかユーザーに確認します。

C3. 編集を適用する（ファイルは1つのみ）

1. タスクの編集： タスクファイルのみを編集します（メタデータ、説明、受け入れ条件）。タスク名またはスラッグを変更する場合は、タスクファイル名を変更（ファイルを移動）できます。そのタスクを指す他のタスクファイル内の dep 参照も更新する必要があります。
2. アイテムの編集： そのアイテムの index.md のみを編集します（work／status メタデータ、説明、CONTEXT）。同期が必要なタスクリストはありません。

C4. 変更を確認する

変更内容の概要をユーザーに示します。

---

操作 D：アイテムをアーカイブする

D1. 検証する

• アイテムディレクトリ内のタスクファイルを一覧表示し、各タスクファイルのメタデータを読みます。アイテム内のすべてのタスクの status が done であることを確認します。
• done でないタスクがある場合は、ユーザーに伝え、アーカイブを拒否します。

D2. アーカイブを実行する（1 ステップ）

1. 移動：項目フォルダーを .backlogmd/work/<item-id>-<slug>/ から .backlogmd/z-archive/<YYYY>/<MM>/<item-id>-<slug>/ に移動します（必要に応じて年・月のディレクトリを作成します）。index.md、すべてのタスクファイル、および -feedback.md ファイルが含まれます。

D3. 確認

項目がアーカイブされたことと、work/ に残っている未完了の項目ディレクトリの数（20 件中）をユーザーに報告します。

---

Operation E：バックログのステータスを表示する

E1. ディレクトリとファイルから状態を読み取る

.backlogmd/work/ を一覧表示します。各項目ディレクトリについて index.md（項目のタイトル、項目の status）を読み取り、タスクファイルを一覧表示してから、各タスクファイルのメタデータを読み取り、タスクのタイトルと status を確認します。

E2. 概要を提示する

次の内容を表示します。

• 未完了の項目の合計数（work/ 内のディレクトリ数）と、該当する場合は項目の status
• 各項目について、ステータス別のタスク内訳（例：「5 件中 3 件完了、1 件進行中、1 件未着手」）
• 現在 in-progress のタスク（担当者を含む）
• 人による承認待ちの review 状態のタスク
• アーカイブ可能な項目（すべてのタスクが done）
• 未完了の項目数（work/ 内のディレクトリ数）と上限（20 件）

---

Operation F：整合性チェック

.backlogmd/ システム全体の整合性を検証します。すべてのファイルを読み取り、以下の各ルールを確認します。問題は重大度別にまとめて報告します。

F1. すべての状態を読み取る

• .backlogmd/work/ を一覧表示し、各項目ディレクトリについて index.md を読み取り、タスクファイル（<tid>-<task-slug>.md）を一覧表示してから、各タスクファイルを読み取ります。
• z-archive/ が存在する場合は、一覧表示します（読み取り専用のチェック）。

F2. 構造を検証する

• work/ が存在すること。backlog.md や manifest.json は必須ではありません。
• work/ 内のすべての項目フォルダーに index.md があること。
• タスクファイルの名前が <tid>-<task-slug>.md であること（ゼロ埋めされた tid、kebab-case のスラッグ）。
• work/ 内のディレクトリが 20 件を超えていないこと。

F3. フォーマットを検証する

• すべての index.md に 、、`` と、少なくとも work および status を含む YAML があること。assignee は任意です。項目の status は plan、open、claimed、in-progress、done のいずれかであること。claimed の場合は assignee が空でないこと、open または done の場合は assignee が空であること、in-progress の場合は assignee を設定してもよいこと。
• すべてのタスクファイルに 、、`` と、必須フィールド task、status、priority、dep、assignee、requiresHumanReview、expiresAt を含む YAML があること。
• タスクのステータスが有効であること（plan、open、in-progress、review、block、done）。
• dep の値が .backlogmd/ からの相対パスであること：work/<item-id>-<slug>/<tid>-<task-slug>.md。自己参照、重複、循環（DAG 違反）がないこと。
• 項目 ID とタスク ID がゼロ埋めされており（最低 3 桁）、それぞれのスコープ内で一意であること。
• in-progress および review のタスクでは assignee が空でないこと。done のタスクでは assignee が空であること。claimed 状態の項目では項目の assignee が空でないこと。

F4. 依存関係とワークフローを検証する

• 循環依存がないこと（すべての dep パスが DAG を形成すること）。
• dep（パスから該当するタスクファイルを解決したもの）のいずれかが done でない間、タスクが in-progress になっていないこと。
• requiresHumanReview: true のタスクが、review を経ずに done になっていないこと。

F5. アーカイブを検証する

• z-archive/ 内の項目フォルダーが work/ にも存在していないこと。

F6. 報告する

次の形式で結果を提示します。

• エラー — 仕様違反（マーカーの欠落、無効なステータス、壊れた dep パス、循環）。
• 警告 — すべてのタスクが完了しているが未アーカイブの項目、期限切れの expiresAt。
• OK — 合格したチェック。

エラーが見つかった場合は、ユーザーの確認を得て修正することを提案します。タスク状態の正本はタスクファイルです。照合が必要なマニフェストはありません。

ルール

• 仕様の形式に正確に従ってください。YAML メタデータはフェンス付きコードブロックに記述し、YAML フロントマターは使用しないでください。
• すべてのパスは .backlogmd/ 内の相対パスです。
• タスクの編集： タスクファイルのみを書き込んでください。項目の編集： その項目の index.md のみを書き込んでください。フィードバック： タスクの -feedback.md のみを書き込んでください。共有マニフェストやバックログファイルは絶対に更新しないでください。
• 既存の項目やタスクを上書きしないでください。新しい項目ディレクトリやタスクファイルを作成するか、既存のものをそのまま編集してください。
• ファイルを書き込んだり変更したりする前に、必ずユーザーに確認してください。
• 未完了の項目（work/ 内のディレクトリ）は最大 20 件です。上限に達した場合、ユーザーは項目をアーカイブするか、既存の項目を使用する必要があります。
• z-archive/ ディレクトリは長期保管場所です。項目を移動した後は、二度と変更しないでください。
• 完了したタスクを再開することはできません。作業を再度行う必要がある場合は、新しいタスクを作成してください。
• requiresHumanReview: true の場合、エージェントはタスクを in-progress から done に直接移してはいけません。必ず review を経由する必要があります。