SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillstask-manager

task-manager

Office & productivity

View repository

Updated 10-15 11:00

About this skill

Requirements Management (Task Manager)

A backlog left unrefined is a garbage dump. Refine it regularly: do what should be done, delete what should be deleted, raise what should be raised.

Core Responsibilities

需求管理 = 收集 + 排序 + 清理 + 跟踪
Responsibility What to Do
Collect Write new requirements to docs/backlog/, update INDEX
Prioritize Regularly reassess priority (P0-P3)
Clean Up Mark expired/invalid requirements as dropped, keep the backlog clean
Track Requirement status flow: open → in-progress → done / dropped

Requirement Status Definitions

open ──→ in-progress ──→ done
  │                        │
  └──→ dropped             └─ 触发复盘 + 经验沉淀
Status Meaning Trigger Timing Driven Behavior
open Collected, awaiting scheduling When the requirement is created None
in-progress In development When task-start is initiated None (makes it easy to track progress across sessions)
done Fully completed User confirms closure Trigger retrospective + Ingest
dropped Abandoned Requirement invalidated/priority reduced to zero Record the drop reason

The value of in-progress: across sessions, it lets you quickly locate "where you left off last time" — see which items in the backlog are in-progress, then check the corresponding plan progress.

Operation 1: Add a Requirement

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

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

# <需求标题>

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

## 描述
具体要做什么？

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

After creation, update docs/backlog/INDEX.md, and place it in the corresponding group by priority.

Operation 2: Refine the Backlog

Trigger Timing

  • The user actively requests refinement
  • Before starting a new iteration/sprint
  • When the backlog exceeds 15 open requirements

Refinement Process

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

Refinement Conclusion Format

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

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

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

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

Operation 3: Priority Ranking

Priority Definitions

Level Meaning Judgment Criteria
P0 Urgent Blocks other work, production issues, approaching deadline
P1 Important Core functionality, high-frequency user needs, has a clear deadline
P2 Normal Valuable but not urgent, optimization-type requirements
P3 Low Priority Nice-to-have, long-term planning, idea notes

Ranking Method

When priorities need to be ranked among multiple requirements:

  1. First stratify by urgency（P0-P3）
  2. Within the same stratum, rank by value/cost ratio: Those with high value and low cost come first
  3. Consider the order of dependencies: If A depends on B, then B comes before A

Operation 4: Status Change

Change Operation
open → in-progress Update the backlog file status + mark in INDEX.md [~](in development)
in-progress → done Trigger the closure process(See below)
open/in-progress → dropped Update backlog file status + add in INDEX.md ~~删除线~~ + state the drop reason
Priority adjustment Update backlog file priority + move to the corresponding group in INDEX.md

open → in-progress

When task-start initiates a requirement, automatically update the corresponding backlog status:

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

[~] indicates in development, distinguished from [ ](to do),[x](done).

Requirement closure process (open → done)

Marking a requirement as done is the most important node in the entire workflow—it is the only trigger point for retrospectives and experience accumulation. "Coding complete" does not equal "requirement complete". Requirement complete = the user confirms this requirement is completely done. Code must be committed when marking done: changes such as backlog status updates and retrospective documents cannot be accumulated; commit them together with marking done.

用户说"这个需求做完了" / "标记完成" / "关闭这个需求"
  │
  ├─ 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，不积攒

Mandatory full retrospective signals(if any of the following occurs, regardless of requirement size):

  • A direction adjustment or major rework occurred during the requirement
  • There was a significant deviation between the solution design and actual execution
  • A previously unknown pitfall or implicit knowledge was discovered
  • The user explicitly requested a retrospective

Lightweight retrospective (3 questions)

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

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

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

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

Full retrospective (four-dimensional review)

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

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

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

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

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

## 行动项
- [ ] ...

Experience accumulation path

docs/decisions/ is the source of truth; memory is only a cross-session index. Storing only in memory without writing documentation is not allowed.

Step Storage location Nature
Full retrospective text docs/decisions/YYYY-MM-DD-<主题>.md Source of truth, committed with git
Key experience memory (feedback/project type) Cross-session index
General specification CLAUDE.md Experience elevated to specification

Memory writing rules (detailed in Step 5)

memory is the "memo for the next conversation"—only store information useful across sessions, and do not store things that can be derived from code/git/docs.

When to write memory：

Trigger scenario What type to write Example
Discovered during retrospectiveNon-obvious pitfall feedback "Prisma migrate does not support ALTER COLUMN under SQLite; the table needs to be rebuilt"
Summarized during retrospectiveReusable practice feedback "Use CONCURRENTLY when adding an index to a large table, otherwise the table will be locked"
The user corrected your approach feedback "Do not use mock tests in this project; we got burned last time"
The user confirmed a non-obvious solution feedback "Packaging the refactor in a single PR is right; splitting it too finely just causes churn"
Learned the project's phase goals/constraints project "Compliance transformation must be completed before Q2; scope prioritizes compliance"
Learned the location of external resources reference "For performance monitoring, look at the Grafana xxx dashboard"

Three questions for deciding whether to write：

  1. Will this information still be needed in the next conversation? → If not needed, do not write it
  2. Can it be derived from code/git log/docs? → If it can be derived, do not write it
  3. Will it expire within 2 weeks? → If it will expire, write the project type (to facilitate later cleanup)

What not to write: code structure, file paths, function signatures, specific bug fix solutions—these can be seen from the code and git.

Memory Cleanup Rules

Uncleaned memory is a garbage dump, just like a backlog.

Cleanup Trigger Timing：

  1. During docs-management Lint: also check memory and add a "Memory Inspection" section to the health check report
  2. Reading expired memory at the start of a conversation: if the memory content is found to be inconsistent with the current code/project status, update or delete it on the spot
  3. When memory entries exceed 20: proactively suggest that the user clean them up

Cleanup Judgment Criteria：

Situation Action
The project type has not been updated for more than 1 month Check whether it is still valid; delete it if invalid
The code/module described by the feedback type has been refactored or deleted Delete
Two memory entries are duplicated or contradictory Merge or delete the older one
A file/function referenced in memory no longer exists Delete
The content has been consolidated into CLAUDE.md or docs/ Delete the memory (docs is already the source of truth)

Cleanup Operation: delete the memory file + update the MEMORY.md index, which, like writing, is two steps.

INDEX.md Format

# Backlog Index

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

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

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

## P3 — 低优
- [ ] [需求标题](文件名.md) — 一句话描述
- ~~[已放弃需求](文件名.md) — 一句话描述~~
  • [ ] = open (to do)
  • [~] = in-progress (in development)
  • [x] = done (completed)
  • ~~删除线~~ = dropped (abandoned)

Relationship with Other Skills

Requirement status changes are the driving force of the entire workflow.

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

Experience Closed Loop

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