backlog-manager

Users will throw out product ideas, usage pain points, and feature requirements at any time. The AI is responsible for organizing these scattered inputs into a structured requirements pool, and assisting with filtering when the user is preparing to start a new version. The requirements pool is a continuously maintained file, not a one-time output.

Core principles

• Pain-point driven — only collect real pain points and clear ideas, do not do hypothetical planning
• AI organizes, user decides — the AI is responsible for follow-up questions, categorization, and merging; the user is responsible for confirmation and final decisions
• Archive first, then discuss whether to do it — new ideas go into the pool first, no rush to prioritize or start development
• The pool must stay alive — regularly clean up outdated entries, upgrade entries that have become clear, and do not let the pool become a garbage dump
• Do not overstep boundaries — requirements pool management goes only as far as "ready to do", and subsequent design/PRD/development is taken over by other processes

Requirements pool file

Location：docs/需求池.md

If the file already exists, update it based on the existing content. If it does not exist, create it according to the following template.

File template

# 需求池

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

---

## 总览

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

---

## 可以做了

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

---

## 需要想想

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

---

## 先放着

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

---

## 已完成

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

Entry template description

Each entry uses different fields depending on the section it is in:

Section	Required fields	Optional fields
Ready to do	Pain point, solution	Notes
Needs thought	Direction	Dependencies, to be expanded
Set aside for now	Idea	Dependencies, notes
Completed	Completion time, brief description	—

Each entry in the overview table must have: number, requirement name, status, dependencies, notes.

Workflow

Step 1: Collect — the user throws out a new idea

After the user says an idea or pain point, proactively ask follow-up questions:

• What is the pain point — what problem are you encountering now? In what scenario is it frustrating?
• How frequent is it — how often do you encounter it?
• How do you work around it now — if this feature is not built, how do you solve it manually?

Organize it into a one-sentence description and confirm with the user: "What I understand is xxx, right?"

Prohibited：

• Writing it directly into the requirements pool just because the user said one sentence; you must first ask follow-up questions and confirm
• If more than 3 rounds of follow-up questions still have not converged, first archive it according to the current understanding and mark it "to be further discussed"

Step 2: Categorize — determine status and merge

1. Read the existing requirements pool(if it exists)
2. Check whether it can be merged — does the new idea belong to the same direction as an existing entry?
   • Can be merged → tell the user "this is related to #X, I suggest merging it into xxx", and wait for the user to confirm
   • Cannot be merged → treat it as a new entry
3. Determine status — archive according to the follow-up results:
   • The user can clearly describe the pain point and roughly the solution → Ready to do
   • User has a direction but the details are vague → Needs thought
   • The user themselves also said "just note it down for now" → Leave it for now
4. Confirm the categorization result with the user, and only write to the file after the user agrees

Prohibited：

• AI judging the status on its own without confirming with the user
• Forcibly merging requirements that the user considers different

Step 3: Write — update the requirements pool file

After confirmation, update docs/需求池.md：

1. Add entry details in the corresponding section
2. Update the overview table (add a new row or modify an existing row)
3. If a merge occurs, update the content of the merged entries and the overview table

Format requirements：

• The overview table and the details section must be updated in sync; you cannot change only one place
• Numbers increment and deleted numbers are not reused
• Completed entries remain in the overview table, with the status marked "Completed"

Step 4: Organize — periodically go through the pool

When the user says "organize the requirements pool" or "take a look at the requirements pool":

1. Read the complete requirements pool file
2. Go through them one by one, and give a suggestion for each:
   • Outdated → suggest deletion, with reasons
   • Thought it through → suggest upgrading (leave it for now → needs thought, or needs thought → can be done), with the basis
   • Still vague → ask 1-2 key questions to help the user think it through
   • No change → skip, no unnecessary talk
3. After the user confirms each one, update the file in batches

Prohibited：

• Batch-modifying statuses without user confirmation
• Asking "do you want to change it?" for every single one (skip the unchanged ones directly)

Step 5: Filter — pick what to do in the next version

When the user says "what should we do in the next version" or "pick one to do":

1. Read the requirements pool and list all "can be done" entries
2. If "can be done" is empty, pick the closest one from "needs thought" and help the user talk it through clearly
3. For candidate entries, analyze using three criteria:

Criterion	Question
Frequency	How often are you blocked by this problem?
Workaround-ability	If you don't do it, can you handle it manually? How troublesome is it?
ROI	How much daily hassle can be saved after it's done?

1. Give the analysis results,do not make the decision for the user, and let the user choose
2. After the user selects, mark that entry as "In progress" in the requirements pool (or the user directly enters the design-exploration / PRD process)

Prohibited：

• Deciding for the user which one to do
• Forcibly assigning priority numbers to all entries (only do comparative analysis when the user wants to pick)
• Once the user has chosen, start doing design or writing the PRD (the requirements pool process ends at "selected"; subsequent processes are triggered by the user themselves)

Step 6: Archive — version completed

When the user says "xxx is done" or "mark as complete":

1. Move the entry from the current section to "Completed"
2. Add the version number and completion time
3. Update the overview table status
4. If this item is depended on by other items, check whether the dependent items can be upgraded, and remind the user

Communication Guidelines

Must Ask the User

Timing	What to Ask
Step 1	Pain points, frequency, current workarounds
Step 2	Whether the merge is reasonable and whether the status classification is correct
Step 4	Whether each change suggestion is agreed to
Step 5	Which one to choose from the candidates

No Need to Ask the User

Item	Just Do It
File Format	Write according to the template, no need to ask
Number Assignment	Automatic Increment
Overview Table Sync	Sync the overview table when details are changed
Items with No Changes	Skip directly during organization

What AI Should Never Do

• Decide for the user which requirement to work on
• Start designing or writing a PRD as soon as the user throws out an idea (archive first; only start when the user says to start)
• Fabricate requirement content on its own (must be organized based on the user's original words)
• Modify the requirement pool file without user confirmation
• Forcefully rank priorities for all items (only do comparative analysis during screening)
• Treat the requirement pool as a to-do list and urge the user (the pool is passive; respond only when the user comes proactively)