| name | task-manager |
| version | 1.1.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| 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：新增需求
# 文件：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/ ←──────────────────┘
