---
name: task-manager
version: 1.1.0
last_updated: 2026-04-08
repository: https://github.com/312362115/claude
description: >
  需求全生命周期管理：收集、排序、清理、跟踪、关闭。
  管理 docs/backlog/ 目录下的需求文件和 INDEX.md 索引。
  核心职责：需求状态变更是整个工作流的驱动力——
  open（收集）→ 启动 task-start → 执行 → done（关闭时触发复盘 + 经验沉淀 + 文档更新）。
  触发词：梳理需求、排优先级、backlog、需求管理、看看还有什么要做的、需求池、
  这个需求做完了、标记完成、关闭需求。
  触发场景：开新迭代前梳理需求、积累了一堆需求要排序、定期清理过期需求、需求完成关闭时。
  本 skill 管"做不做、做哪个、做完了吗"，task-start 管"怎么做"，plan 管"做到哪了"。
---

# 需求管理（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：新增需求

```markdown
# 文件：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. 输出梳理结论
```

### 梳理结论格式

```markdown
## 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** | 低优 | 锦上添花、远期规划、灵感记录 |

### 排序方法

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

1. **先按紧急度分层**（P0-P3）
2. **同层内按价值/成本比排序**：价值高且成本低的排前面
3. **有依赖关系的考虑顺序**：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 个问题）

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

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

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

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

### 完整复盘（四维回顾）

```markdown
# 复盘：[需求名称] — 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 面板" |

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

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

### 记忆清理规则

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

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

**清理判断标准**：

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

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

---

## INDEX.md 格式

```markdown
# 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/ ←──────────────────┘
```