backlog-manager

[スキル名] backlog-manager

ユーザーはいつでも製品のアイデア、使用上の問題点、機能要件を投げかけてきます。AI はこれらの断片的な入力を構造化された要件プールに整理し、ユーザーが新しいバージョンを立ち上げる準備ができたときに、その選別を支援します。要件プールは継続的に管理されるファイルであり、一度きりの成果物ではありません。

核となる原則

• 問題点駆動 — 実際の問題点と明確なアイデアのみを収集し、仮説的な計画は立てません。
• AI が整理、ユーザーが決定 — AI は質問、分類、統合を担当し、ユーザーは確認と最終決定を担当します。
• まずアーカイブ、それから実行するかどうか — 新しいアイデアはまずプールに入れ、優先順位付けや開発の開始を急ぎません。
• プールは常に活性化 — 古くなった項目は定期的に削除し、明確になった項目は昇格させ、プールがゴミ捨て場にならないようにします。
• 越権しない — 要件プールは「実行可能」な状態まで管理し、その後の設計/PRD/開発は他のプロセスが引き継ぎます。

要件プールファイル

場所：docs/需求池.md

ファイルが既に存在する場合は、既存の内容を更新します。存在しない場合は、以下のテンプレートに従って作成します。

ファイルテンプレート

# 需求池

> 随手記，随时加，隔段时间过一遍。
>
> 状态说明：
> - **可以做了** — 痛点清晰，知道要做成什么样，随时能进设计/PRD
> - **需要想想** — 方向有了，细节没展开，需要调研或讨论
> - **先放着** — 记着就行，现在不花精力想
> - **已完成** — 做完了，标版本号归档

---

## 总览

| # | 需求 | 状态 | 依赖 | 备注 |
|---|------|------|------|------|
| 1 | xxx  | 可以做了 | 无 | xxx |

---

## 可以做了

### 需求名称
- 痛点：xxx
- 方案：xxx
- 备注：xxx

---

## 需要想想

### 需求名称
- 方向：xxx
- 依赖：xxx
- 待展开：xxx

---

## 先放着

### 需求名称
- 想法：xxx
- 备注：xxx

---

## 已完成

### 需求名称（V0.xx）
- 完成时间：yyyy-mm-dd
- 简述：xxx

項目テンプレートの説明

各項目は、所属するセクションに応じて異なるフィールドを使用します。

概要表の各項目には、番号、要件名、ステータス、依存関係、備考が必須です。

作業フロー

ステップ 1：収集 — ユーザーが新しいアイデアを提示

ユーザーがアイデアや問題点を述べた後、積極的に質問します。

• 問題点とは何か — 現在どのような問題に直面していますか？どのような状況で不満を感じますか？
• 頻度はどのくらいか — どれくらいの頻度で遭遇しますか？
• 現在どのように回避していますか — この機能がなくても、手動でどのように解決していますか？

一文で要約し、ユーザーに「私の理解では xxx ですが、合っていますか？」と確認します。

禁止事項：

• ユーザーが一言言っただけで直接要件プールに書き込むこと。必ず質問して確認する必要があります。
• 3 回以上質問しても収束しない場合、現在の理解で一旦アーカイブし、「要追加議論」とマークします。

ステップ 2：分類 — ステータスの判断と統合

1. 既存の要件プールを読み込む（存在する場合）
2. 統合可能か確認 — 新しいアイデアは既存の項目と同じ方向性ですか？
   • 統合可能 → ユーザーに「これは #X に関連しています。xxx に統合することをお勧めします」と伝え、ユーザーの確認を待ちます。
   • 統合不可 → 新しい項目として扱います。
3. ステータスの判断 — 質問の結果に基づいてアーカイブします。
   • ユーザーが問題点と大まかな解決策を明確に説明できる → 実行可能
   • ユーザーに方向性はあるが詳細が不明確 → 検討が必要
   • ユーザー自身が「とりあえず覚えておいて」と言う → 保留
4. ユーザーに分類結果を確認し、ユーザーが同意した後にファイルに書き込みます。

禁止事項：

• AI がユーザーに確認せずに独自にステータスを判断すること。
• ユーザーが異なると考える要件を強制的に統合すること。

ステップ 3：書き込み — 要件プールファイルの更新

確認後、docs/需求池.md を更新します。

1. 該当するセクションに項目の詳細を追加します。
2. 概要表を更新します（新しい行を追加するか、既存の行を修正します）。
3. 統合が発生した場合、統合された項目の内容と概要表を更新します。

フォーマット要件：

• 概要表と詳細セクションは同期して更新する必要があります。片方だけを変更することはできません。
• 番号は増加させ、削除された番号を再利用しません。
• 完了した項目は概要表に残し、ステータスを「完了」とマークします。

ステップ 4：整理 — 定期的なプールの見直し

ユーザーが「要件プールを整理して」または「要件プールを見て」と言った場合：

1. 要件プールファイル全体を読み込みます。
2. 各項目を順に確認し、それぞれに提案をします。
   • 古くなった → 削除を提案し、理由を説明します。
   • 明確になった → 昇格を提案します（保留 → 検討が必要、または検討が必要 → 実行可能）、根拠を説明します。
   • まだ不明確 → 1〜2つの重要な質問を投げかけ、ユーザーが明確にするのを助けます。
   • 変更なし → スキップし、無駄な会話はしません。
3. ユーザーが各項目を確認した後、ファイルを一括で更新します。

禁止事項：

• ユーザーの確認なしに一括でステータスを変更すること。
• 各項目について「変更しますか？」と尋ねること（変更がない場合は直接スキップします）。

ステップ 5：選別 — 次のバージョンで何をするかを選択

ユーザーが「次のバージョンで何をしますか？」または「一つ選んでください」と言った場合：

1. 要件プールを読み込み、「実行可能」なすべての項目をリストアップします。
2. 「実行可能」が空の場合、「検討が必要」の中から最も近いものを選び、ユーザーが明確にするのを助けます。
3. 候補項目について、3つの基準で分析します。

4. 分析結果を提示し、ユーザーの決定を代行しません。ユーザーに選択させます。
5. ユーザーが選択した後、要件プールでその項目を「進行中」とマークします（またはユーザーが直接 design-exploration / PRD プロセスに進みます）。

禁止事項：

• ユーザーにどれを実行するかを決定させること。
• すべての項目に強制的に優先順位番号を付けること（ユーザーが選択したいときにのみ比較分析を行います）。
• ユーザーが選択した後すぐに設計や PRD の作成を開始すること（要件プールプロセスは「選択」までであり、その後のプロセスはユーザー自身がトリガーします）。

ステップ 6：アーカイブ — バージョン完了

ユーザーが「xxx が完了しました」または「完了とマークしてください」と言った場合：

1. 項目を現在のセクションから「完了」に移動します。
2. バージョン番号と完了時間を追加します。
3. 概要表のステータスを更新します。
4. その項目が他の項目に依存している場合、依存項目が昇格可能か確認し、ユーザーに通知します。

コミュニケーション規範

ユーザーに尋ねる必要があること

ユーザーに尋ねる必要がないこと

AI が決してすべきではないこと

• ユーザーにどの要件を実行するかを決定させること。
• ユーザーがアイデアを投げた後、すぐに設計や PRD の作成を開始すること（まずアーカイブし、ユーザーが開始すると言ったときにのみ開始します）。
• 独自に要件の内容を作成すること（ユーザーの元の発言に基づいて整理する必要があります）。
• ユーザーの確認なしに要件プールファイルを変更すること。
• すべての項目に強制的に優先順位を付けること（選別時にのみ比較分析を行います）。
• 要件プールをToDoリストとしてユーザーを急かすこと（プールは受動的であり、ユーザーが自発的に来たときにのみ応答します）。