需求管理（Task Manager）

backlog 不梳理就是垃圾堆。定期梳理，该做的做、该删的删、该提的提。

核心职责

需求管理 = 收集 + 排序 + 清理 + 跟踪

职责	做什么
收集	新需求写入 `docs/backlog/`，更新 INDEX
排序	定期重新评估优先级（P0-P3）
清理	过期/无效需求标记 dropped，保持 backlog 清洁
跟踪	需求状态流转：open → in-progress → done / dropped

需求状态定义

open ──→ in-progress ──→ done
  │                        │
  └──→ dropped             └─ 触发复盘 + 经验沉淀

状态	含义	触发时机	驱动行为
open	已收集，待排期	需求创建时	无
in-progress	开发中	task-start 启动时	无（方便跨会话跟踪进度）
done	彻底完成	用户确认关闭	触发复盘 + Ingest
dropped	放弃	需求失效/优先级归零	记录 drop 原因

in-progress 的价值：跨会话时能快速定位"上次做到哪了"——看 backlog 中哪些是 in-progress，再看对应的 plan 进度。

操作 1：新增需求

# 文件：docs/backlog/YYYY-MM-DD-<主题>.md

---
priority: P2
status: open
spec: （关联方案，如有）
plan: （关联计划，如有）
---

# <需求标题>

## 背景
为什么要做这个？

## 描述
具体要做什么？

## 验收标准
做到什么程度算完？

创建后更新 docs/backlog/INDEX.md，按优先级放到对应分组。

操作 2：梳理 backlog

触发时机

用户主动要求梳理
开新迭代/冲刺前
backlog 超过 15 个 open 需求时

梳理流程

1. 读取 docs/backlog/INDEX.md，了解全貌
2. 逐条检查 open 状态的需求：
   │
   ├─ 还有价值吗？
   │   └─ NO → 标记 dropped，说明原因
   │
   ├─ 优先级还对吗？
   │   └─ 调整 priority 和 INDEX 位置
   │
   ├─ 描述还准确吗？
   │   └─ 更新描述/验收标准
   │
   └─ 有没有已完成但没标记的？
       └─ 标记 done，更新 INDEX
3. 输出梳理结论

梳理结论格式

## Backlog 梳理结论 — YYYY-MM-DD

### 概况
- 总计：X 条需求
- Open：X 条 | Done：X 条 | Dropped：X 条

### 本次调整
- P1 → P0：[需求名] — 原因
- P2 → dropped：[需求名] — 原因
- 新增：[需求名] — P2

### 建议下一步做
1. [需求名](链接) — P0，理由
2. [需求名](链接) — P1，理由

操作 3：优先级排序

优先级定义

级别	含义	判断标准
P0	紧急	阻塞其他工作、线上问题、截止日期临近
P1	重要	核心功能、用户高频需求、有明确截止时间
P2	普通	有价值但不紧急、优化类需求
P3	低优	锦上添花、远期规划、灵感记录

排序方法

当需要在多个需求间排优先级时：

先按紧急度分层（P0-P3）
同层内按价值/成本比排序：价值高且成本低的排前面
有依赖关系的考虑顺序：A 依赖 B，则 B 排在 A 前面

操作 4：状态变更

变更	操作
open → in-progress	更新 backlog 文件 status + INDEX.md 中标注 `[~]`（开发中）
in-progress → done	触发关闭流程（见下方）
open/in-progress → dropped	更新 backlog 文件 status + INDEX.md 中加 `~~删除线~~` + 写明 drop 原因
优先级调整	更新 backlog 文件 priority + INDEX.md 中移动到对应分组

open → in-progress

task-start 启动需求时，自动更新对应 backlog 状态：

1. 更新 backlog 文件 frontmatter: status: in-progress
2. 更新 INDEX.md: [ ] → [~]

[~] 表示开发中，和 [ ]（待做）、[x]（完成）区分。

需求关闭流程（open → done）

需求标 done 是整个工作流最重要的节点——这是复盘和经验沉淀的唯一触发点。 "编码完成"不等于"需求完成"。需求完成 = 用户确认这个需求彻底搞定了。 标 done 时必须提交代码：backlog 状态更新、复盘文档等变更不能积攒，随标 done 一起 commit。

用户说"这个需求做完了" / "标记完成" / "关闭这个需求"
  │
  ├─ Step 1: 更新 backlog 文件 status → done
  ├─ Step 2: 更新 INDEX.md 中 [ ] → [x]
  │
  ├─ Step 3: 复盘判断
  │   │
  │   ├─ 小需求（≤2 文件，过程顺利，无返工）？
  │   │   └─ 跳过复盘
  │   │
  │   ├─ 中等需求（过程中有波折但不大）？
  │   │   └─ 轻量复盘：回答 3 个问题
  │   │
  │   └─ 大需求 / 过程曲折 / 方向调整 / 反复修改？
  │       └─ 完整复盘：四维回顾
  │
  ├─ Step 4: 复盘产出写入 docs/decisions/YYYY-MM-DD-<主题>.md
  ├─ Step 5: 记忆管理（详见下方"记忆写入规则"）
  ├─ Step 6: 触发 docs-management.Ingest（更新相关 spec/plan 状态标注）
  ├─ Step 6.1: 复盘中提到环境/工具链的坑？→ 提醒补到 guides/
  ├─ Step 6.2: 复盘中提到线上问题/部署问题？→ 提醒补到 runbooks/
  ├─ Step 7: 更新 docs/decisions/INDEX.md（如果存在）
  └─ Step 8: 提交代码 — 将本次需求的所有变更（含 backlog 状态、复盘文档）一起 commit，不积攒

强制完整复盘信号（出现以下任一，不管需求大小）：

需求过程中出现了方向调整或重大返工
方案设计和实际执行有显著偏差
发现了之前不知道的坑或隐含知识
用户明确要求复盘

轻量复盘（3 个问题）

# 复盘：[需求名称] — YYYY-MM-DD

1. **方案和实际的偏差在哪？**
   - [偏差描述，没有偏差就写"无"]

2. **哪里返工了、为什么？**
   - [返工原因，没有返工就写"无"]

3. **下次怎么避免？**
   - [可复用的经验]

完整复盘（四维回顾）

# 复盘：[需求名称] — YYYY-MM-DD

## 需求概述
- 目标：[一句话描述]
- 结果：[完成情况]
- 过程顺利度：1-5 星

## 做得好的（保持）
- ...

## 做得不够好的（优化）
- ...（附原因分析）

## 通用能力沉淀
- ...

## 行动项
- [ ] ...

经验沉淀路径

docs/decisions/ 是真相源，memory 只是跨会话索引。不允许只存 memory 不写文档。

步骤	存储位置	性质
复盘全文	`docs/decisions/YYYY-MM-DD-<主题>.md`	真相源，随 git 提交
关键经验	memory（feedback/project 类型）	跨会话索引
通用规范	CLAUDE.md	经验提升为规范

记忆写入规则（Step 5 详细说明）

memory 是"下次对话的备忘录"——只存跨会话有用的信息，不存能从代码/git/docs 推导出的东西。

什么时候写 memory：

触发场景	写什么类型	示例
复盘中发现了不显然的坑	feedback	"Prisma migrate 在 SQLite 下不支持 ALTER COLUMN，需要重建表"
复盘中总结了可复用的做法	feedback	"大表加索引用 CONCURRENTLY，否则锁表"
用户纠正了你的做法	feedback	"不要在这个项目用 mock 测试，上次踩过坑"
用户确认了一个非显然的方案	feedback	"单 PR 打包重构是对的，拆太细反而是 churn"
了解到项目的阶段性目标/约束	project	"Q2 前必须完成合规改造，scope 优先合规"
了解到外部资源的位置	reference	"性能监控看 Grafana xxx 面板"

写入判断三连问：

下次对话还需要这个信息吗？ → 不需要则不写
能从代码/git log/docs 推导出来吗？ → 能推导则不写
会在 2 周内过期吗？ → 会过期则写 project 类型（方便后续清理）

不写的：代码结构、文件路径、函数签名、具体的 bug 修复方案——这些从代码和 git 就能看到。

记忆清理规则

记忆不清理就是垃圾堆，和 backlog 一样。

清理触发时机：

docs-management Lint 时：顺带检查 memory，在健康检查报告中加一节"记忆巡检"
对话开始时读到过期 memory：发现 memory 内容和当前代码/项目状态不符，当场更新或删除
memory 条目超过 20 条时：主动建议用户清理

清理判断标准：

情况	操作
project 类型超过 1 个月未更新	检查是否仍然有效，失效则删除
feedback 类型描述的代码/模块已重构或删除	删除
两条 memory 内容重复或矛盾	合并或删除旧的
memory 中引用的文件/函数已不存在	删除
内容已被沉淀到 CLAUDE.md 或 docs/	删除 memory（docs 已是真相源）

清理操作：删除 memory 文件 + 更新 MEMORY.md 索引，和写入一样是两步。

INDEX.md 格式

# Backlog Index

## P0 — 紧急
<!-- 当前无 P0 -->

## P1 — 重要
- [~] [开发中的需求](文件名.md) — 一句话描述
- [ ] [待做需求](文件名.md) — 一句话描述
- [x] [已完成需求](文件名.md) — 一句话描述

## P2 — 普通
- [ ] [需求标题](文件名.md) — 一句话描述

## P3 — 低优
- [ ] [需求标题](文件名.md) — 一句话描述
- ~~[已放弃需求](文件名.md) — 一句话描述~~

[ ] = open（待做）
[~] = in-progress（开发中）
[x] = done（完成）
~~删除线~~ = dropped（放弃）

与其他 skill 的关系

需求状态变更是整个工作流的驱动力。

task-manager（本 skill）
  │
  ├─ open → 收集需求、排优先级
  │   ↓ 决定做某个需求
  │
  ├─ task-start → 对焦 + 方案
  │   ↓
  │ task-execute → 编码 + 进度管理
  │   ↓
  │ task-finish → 每次提交前自检
  │   ↓
  │ （手动测试、bug 修复、调整...可能反复多轮）
  │   ↓
  ├─ done → 需求彻底完成
  │   ├─ 复盘 → docs/decisions/（经验沉淀）
  │   ├─ Ingest → docs-management（更新相关文档）
  │   └─ memory → 跨会话索引
  │
  └─ dropped → 需求放弃，记录原因

经验闭环

task-start（检索 decisions/ 历史经验）→ 执行 → task-manager 标 done（产出新经验）
      ↑                                                    │
      └──────────────── docs/decisions/ ←──────────────────┘

task-manager