todo-list-manager

name	todo-list-manager
description	待办事项管理skilll。管理 todo.md 和 work_done.md为主的开发任务生命周期。当用户说"记录这个需求"、"帮我看看优先级"、"XX功能完成了"、"生成今日计划"、"看看今天该做什么"、"本周计划"、"本月计划"、"进度如何"时触发。也适用于：需要调整任务优先级、分析工作量、验证任务完成状态、整理待办事项。

Todo List Manager Skill

本 skill 负责管理 .dev_doc/todo.md 和 .dev_doc/work_done.md，提供需求录入、优先级排序、完成验证、工作量估算、变更记录，以及每周、每月计划管理六大核心能力。

核心原则（每次整理待办时必须参考）

#	原则	说明
1	优先级矩阵	P0~P4（重要紧急→不重要不紧急）
2	DDL标注	有明确截止时间应当说明
3	持续流动	关注当前推进的任务，完成后补充新任务，不严格按日分配
4	时效管理	超过2周未动的任务标记「存疑」或移除
5	模块化分组	按 HGS/气象局/bacc/重构 分组，而非扁平列表
6	完成标准	代码合并到主分支 + 开发文档标记状态 + git提交情况
7	不盲目估计	工作量由用户决定，不主动估算
8	完成粒度	谨慎决策什么样的功能记录为已完成，按实际大功能点记录；小更新作为补丁附在大功能点下，不单独建条目

优先级矩阵

优先级	类型	说明
P0	重要且紧急	立即处理
P1	重要不紧急	尽快处理
P2	紧急不重要	计划处理
P3	不重要不紧急	有空处理

持续流动原则

• 不做日粒度计划：不把任务绑定到特定某天
• 关注当前推进：列出当前正在做什么、阻塞什么
• 完成后补充：任务完成后，从 backlog 拉取新任务加入当前队列
• 只规划当前 + 待办：本周/月计划只列"当前进行中"和"待启动"，不做每日分解
• 队列状态：用 ⬜未开始/🔄进行中/✅已完成 标记，不估算工时

完成标准（三者缺一不可）

1. Git合并：代码已合并到主分支（main/dev_zby）
2. 文档状态：开发文档（.dev_doc/{模块}/）已更新标记状态
3. Git提交：有明确 commit 记录

完成粒度（原则8）— 避免过度切分

核心：

• 谨慎决策什么样的功能记录为「已完成」——是否构成一个独立可交付的功能点？
• 不要每个小的功能开发都记作一条 work_done 条目
• 按实际的大功能点来记录；小更新/小修复/小优化作为补丁附在所属大功能点下

判定标准（同时满足才算独立条目）：

维度	独立条目（建新条目）	补丁（合并到现有条目）
业务边界	解决独立的用户场景/问题域	隶属于已有大功能点的局部优化
文档载体	需要独立 .dev_doc/{feature}/	复用现有 feature 文档即可
可独立验收	有完整的"输入→处理→输出"链路	只是大链路中的一环
价值颗粒度	一次发布即可对外兑现价值	离开主条目则无独立价值

work_done.md 写法：

• ✅ 推荐：一个大功能点对应一条主条目 + 多个补丁子条目

  - 【P1】stdq.py 卫星遥测数据查询 Skill
    - 完成日期：2026-06-01
    - 功能特性：基础查询 + 中范围重构 + 多日支持
    - 补丁记录：
      - 2026-06-01 抽取 _load_config() + 4 处 glob_path Path 化
      - 2026-06-02 修复多日 query TypeError（f-string 重写路径拼接）
      - 2026-06-02 容器无 pyarrow 时改用 duckdb 写 parquet
  

• ❌ 反例：同一大功能拆成 3 个独立条目

  - stdq 中范围重构
  - stdq 多日 query TypeError 修复
  - stdq duckdb 写 parquet 修复
  

执行流程：

1. 用户报告"XX 完成了"时，先判定粒度——是大功能点还是补丁？
2. 补丁 → 在所属大功能点的"补丁记录"区追加，不建新条目
3. 大功能点首次完成 → 建主条目，后续补丁不断累积
4. 粒度拿不准时 → 列 2–3 个候选方案，询问用户确认

---

核心概念

任务层级

• 父任务：模块级别，如 1.3 数据库 Skill 重构
• 子任务：最小开发单元，如 (1) 封装cli
• 所有子任务完成后，父任务才算完成

时间尺度

尺度	触发条件	范围
每周	每周一早上 / "本周计划"	本周
每月	每月1号 / "本月计划"	本月
随时	"进度如何" / "当前有什么"	当前状态

工作日约束

• 默认只安排工作日（周一至周五）
• 周六、周日不安排计划
• 如用户明确要求周末工作，按用户要求安排

---

模式一：Todo 更新模式

当用户说"记录需求"、"调整优先级"、"XX完成了"时触发。

功能 1: 需求录入 (Add)

当用户提供新需求时：

Step 1: 解析需求 从用户描述中提取：

• 任务标题
• 所属模块（匹配 .dev_doc/ 下目录）
• 优先级建议（用户提供或 AI 建议）
• DDL（如果有）

Step 2: 生成 todo 条目

格式：

- 【P{优先级}] {任务编号}.{子任务编号} {任务标题}
  - 模块：{所属模块}
  - 描述：{任务详细描述}
  - DDL：{截止日期，如有}
  - 分支：{当前所在分支名}
  - 状态：{待开发/进行中}
  - 添加日期：{YYYY-MM-DD}

Step 3: 更新 todo.md

• 找到对应模块位置
• 按优先级插入（P0 > P1 > P2 > P3）
• 编号自动递增

功能 2: 优先级管理 (Prioritize)

当用户要求查看或调整优先级时，执行综合评分模型。

综合评分模型（满分 100）

维度	权重	评分标准
业务价值	0-30	对核心场景的影响程度
依赖关系	0-20	是否 block 其他关键任务
紧迫度	0-25	DDL 或业务时限的远近
认知清晰度	0-10	需求理解越清晰越高分

评分细则

业务价值 (0-30)：

• 核心功能/直接影响收入：25-30
• 重要功能/提升效率：18-24
• 辅助功能：10-17
• 边缘功能：0-9

依赖关系 (0-20)：

• 被多个关键任务依赖：18-20
• 被1-2个任务依赖：12-17
• 独立任务：8-11
• 被依赖但可替代：0-7

紧迫度 (0-25)：

• DDL 在 3 天内：23-25
• DDL 在 1 周内：18-22
• DDL 在 2 周内：12-17
• 无 DDL 但有时限：6-11
• 无明确时限：0-5

认知清晰度 (0-10)：

• 需求明确、可直接开发：9-10
• 需求较明确、有小问题待确认：6-8
• 需求模糊、需要进一步分析：3-5
• 需求不明确、需要重新调研：0-2

输出格式

## 优先级分析报告

### 当前任务优先级列表（按综合评分降序）

| 排名 | 任务 | 综合评分 | 业务价值 | 依赖关系 | 紧迫度 | 认知清晰度 | 建议 |
|------|------|---------|---------|---------|--------|-----------|------|
| 1 | xxx | 85 | 28 | 18 | 22 | 5 | P0 |
| ... | ... | ... | ... | ... | ... | ... | ... |

### 优先级调整建议
- 【建议 P0→P1】xxx：原因...
- 【建议新增 P0】xxx：原因...

注意：不根据工作量评分，工作量由用户自行判断。

功能 3: 完成验证 (Verify)

当 ez-dev 到达 P6 阶段，或用户说"XX完成了"时触发。

验证维度（核心原则6）

1. Git合并状态

• 必须检查任务对应的分支是否已合并到主分支（main/dev_zby）
• 检查命令：git branch --merged {main_branch} 或 git log --oneline main..{分支名}
• 如果分支已合并 → 满足条件
• 如果分支未合并但确定无后续操作 → 需要用户确认
• 未合并且有后续计划 → 不算完成

2. 开发文档状态

• 检查 .dev_doc/{模块}/ 下是否有对应开发文档
• 验证文档中的任务状态是否标记为「已完成」或类似状态
• 文档与代码的一致性

3. Git提交情况

• 检查是否有明确 commit 记录与该任务相关
• 从 commit 历史中验证实现情况

4. 功能完整性

• 检查所有子任务是否都已完成
• 检查是否有遗漏的边界情况

核心原则：完成需同时满足：Git已合并 + 文档已更新 + 有git提交记录。三者缺一不可。

验证结论

结论	含义	处理方式
通过	所有验证点都满足	移动到 work_done.md
需补充	部分验证点未满足	列出需要补充的内容
存疑	无法自动判断	提请用户人工确认

验证报告格式

## 任务完成验证报告

### 任务：{任务标题}
### 验证时间：{YYYY-MM-DD HH:mm}

### 验证结果：通过 / 需补充 / 存疑

### 详细验证

#### 1. Git合并状态
- 合并状态：✓/✗ 已合并到 {main_branch}
- 判断依据：{git log 或 merge info}

#### 2. 开发文档状态
- 文档检查：✓/✗ {文档路径}
- 状态标记：✓/✗ 已标记完成

#### 3. Git提交情况
- Commit记录：✓/✗ {commit hash}
- 涉及文件：{文件列表}

#### 4. 功能完整性
- 子任务闭环：✓/✗ {完成情况}

### 下一步操作
{等待用户确认 / 需要补充的内容}

功能 4: 变更记录 (Log)

所有优先级调整自动记录到 work_done.md 的 changelog 区。

Changelog 格式

## Changelog

### {YYYY-MM-DD}
- 【优先级调整】{任务标题}：{调整内容} → {调整后}
  - 原因：{调整原因}
- 【新增任务】{任务标题} → P{优先级}
- 【任务完成】{任务标题} → 已移动到 work_done.md
- 【存疑任务清理】{任务标题} → 超过2周未动，标记为存疑

---

模式二：当前状态模式

当用户说"当前有什么"、"现在在做什么"、"当前进度"时触发。

执行步骤

Step 0: 清理已完成任务（每次必做） 在展示当前状态之前，先扫描所有待办任务。

检测策略（两阶段）

阶段 1：有分支信息 如果任务有 分支：字段：

1. 执行 git branch --merged {main_branch} | grep {分支名}
2. 如果分支已合并 → 判定为已完成
3. 如果分支未合并 → 进入阶段 2

阶段 2：无分支信息或阶段 1 未通过 从任务描述中提取 2-3 个关键词（如"Milvus 批量插入"），执行：

git log --oneline main --all --grep="{关键词}" -n 5
git log --oneline main --all -S "{关键词}" -n 3

• 如果找到候选 commit，执行二次验证：

  git log -n 1 --follow {commit_hash} --name-only
  

  检查 commit 是否涉及任务 模块：目录下的文件（如 services/vector_stores/ 对应 vector-store 模块）
  • 改了模块文件 → 判定为已完成
  • 只改了测试文件/文档/无关文件 → 保持待办（不算误判）
  • 改了其他相关文件 → 标记为"存疑"，询问用户
• 如果只在其他分支 → 保持待办

时效检查

• 检查任务 添加日期 距离当前日期是否超过2周
• 超过2周且无进展 → 标记为「存疑」

执行流程

1. 对每个未标记"已完成"的任务执行检测
2. 已合并：追加到 work_done.md，从 todo.md 删除
3. 未合并：保持原样
4. 无法判断：标记为"存疑"，询问用户

输出报告

### 任务清理报告
- 【已迁移】{任务标题} → work_done.md
- 【未合并】{任务标题} → 仍需开发
- 【存疑】{任务标题} → 无法自动判断，请确认
- 【超时】{任务标题} → 超过2周未动，请确认是否继续

Step 1: 读取 todo.md 按优先级排序，列出当前所有任务。

Step 2: 分析当前队列

• 正在进行的任务（状态 = 进行中）
• 阻塞的任务
• 待启动的任务

Step 3: 生成当前状态报告

## 当前状态

### 日期：{YYYY-MM-DD} {星期X}

### 正在推进
| 优先级 | 任务 | 模块 | 状态 | 备注 |
|--------|------|------|------|------|
| P0 | xxx | 气象局 | 🔄进行中 | xxx |

### 待启动
| 优先级 | 任务 | 模块 | 备注 |
|--------|------|------|------|
| P1 | xxx | MCP | xxx |

### 存疑/阻塞
| 任务 | 问题 | 建议 |
|------|------|------|
| xxx | xxx | xxx |

### 参考信息
- 当前开发分支：{git branch}
- 近期完成：{来自 work_done.md 的最近 2-3 项}

---

模式三：每周计划模式

自动触发：每周一早上自动触发（用户首次当天对话时） 手动触发：当用户说"本周计划"、"这周计划"、"帮我安排本周工作"时触发。

执行步骤

Step 0: 清理已完成任务（每次必做） 同当前状态模式，采用两阶段检测策略（分支名优先，其次 git log 关键词搜索），输出任务清理报告。

Step 1: 确定本周范围

• 本周一至本周五（工作日）
• 如已过周一，从当天开始计算剩余工作日
• 周六、周日不安排

Step 2: 分析本周可用任务

• 从 todo.md 读取所有 P0、P1 任务（优先处理）
• 评估 P2 任务如有空余时间
• 排除已 block 或有外部依赖的任务

Step 3: 与用户确认周目标 询问用户：

• "本周计划完成哪些任务？"
• 解析用户输入，匹配到 todo.md 中的具体任务

Step 4: 写入 todo.md 并生成周计划

更新 todo.md 顶部，插入本周计划区块：

## 本周计划

### {YYYY}年第{WW}周 ({起始日期} ~ {结束日期})
**本周目标**：{一句话描述核心目标}

#### 当前进行中
| 优先级 | 任务 | 模块 | 状态 |
|--------|------|------|------|
| P0 | xxx | 气象局 | 🔄 |

#### 待启动
| 优先级 | 任务 | 模块 |
|--------|------|------|
| P1 | xxx | MCP |

#### 风险与调整预案
- {风险点}：{应对方案}

---

注意：不按日分解任务，不估算工时，只列出当前进行中和待启动。

---

模式四：每月计划模式

自动触发：每月1号自动触发 手动触发：当用户说"本月计划"、"这个月计划"、"帮我安排本月工作"时触发。

执行步骤

Step 0: 清理已完成任务（每次必做） 同当前状态模式，采用两阶段检测策略（分支名优先，其次 git log 关键词搜索），输出任务清理报告。

Step 1: 确定本月范围

• 计算本月工作日数量（通常 20-22 天）
• 排除周末（周六、周日）

Step 2: 分析本月可用任务

• 从 todo.md 读取所有任务
• 评估本月可完成的任务
• 识别跨月任务，拆分到月内

Step 3: 与用户确认月目标 询问用户：

• "本月计划完成哪些任务？优先级是什么？"
• 解析用户输入

Step 4: 生成月度计划

更新 todo.md，插入月度计划区块：

## 本月计划

### {YYYY}年{M}月
**可用工作日**：{X} 天
**本月目标**：{核心目标}

#### 本月各周重点

**第一周（{日期范围}）**
- 重点任务：{任务}
- 里程碑：{里程碑目标}

**第二周（{日期范围}）**
...

#### 关注任务

| 任务 | 状态 | 预计完成 |
|------|------|---------|
| 【进行中】xxx | 进行中 | 第X周 |
| 【待启动】xxx | 待启动 | 第X周 |

#### 月度里程碑
- {日期}：{里程碑}
- {日期}：{里程碑}

---

注意：不做每日分解，关注点在本月的关键节点和里程碑。

---

模式五：独立清理模式

当用户说"清理已完成任务"、"清理 todo"、"同步任务状态"时触发。

执行步骤

Step 1: 扫描所有待办任务 读取 .dev_doc/todo.md，对每个未标记"已完成"的任务：

1. 检查 Git merge 状态：

   • git branch --merged {main_branch} — 检查该分支是否已合并
   • git log --oneline {main_branch}..HEAD — 当前分支独有的 commits

2. 检查时效（原则4）：

   • 计算 添加日期 距离当前日期
   • 超过2周 → 标记为「存疑」

3. 分类处理：

   • 已合并到 main/dev_zby → 执行迁移
   • 未合并且有未完成工作 → 保持不动
   • 无法自动判断 → 标记为"存疑"

Step 2: 执行迁移 对每个"已合并"任务：

1. 读取任务完整信息（标题、模块、描述、工作量）
2. 追加到 work_done.md 对应模块
3. 从 todo.md 中删除该任务
4. 重新编号后续任务

Step 3: 输出报告

## 任务清理报告

### 日期：{YYYY-MM-DD}

| 任务 | 原分支 | 清理结果 |
|------|--------|----------|
| xxx | feature/xxx | ✅ 已迁移到 work_done.md |
| yyy | feature/yyy | ⚠️ 存疑，需人工确认 |
| zzz | - | ⬜ 未合并，保持不动 |
| www | - | ⏰ 超时（>2周），请确认 |

### 操作汇总
- 已迁移：{N} 项
- 存疑：{N} 项
- 超时：{N} 项
- 保持：{N} 项

---

模式六：进度确认与调整

当用户说"进度如何"、"完成了吗"、"调整计划"时触发。

执行流程

Step 0: 清理已完成任务（每次必做） 同当前状态模式，采用两阶段检测策略（分支名优先，其次 git log 关键词搜索），输出任务清理报告。

Step 1: 展示当前状态

• 正在进行中的任务
• 待启动的任务
• 存疑/阻塞的任务

Step 2: 询问用户更新

• 已完成 → 标记为 ✅，移入 work_done.md
• 进行中 → 更新备注
• 新任务 → 加入待办

Step 3: 输出确认报告

## 进度确认报告

### 日期：{YYYY-MM-DD}

### 已完成
- 【已完成 ✅】任务1 → 移入 work_done.md

### 进行中
- 【进行中 🔄】任务2
- 【进行中 🔄】任务3

### 待启动
- 【待启动 ⬜】任务4

### 调整
- 【新增】任务5 → P1
- 【移除】任务6 → 存疑清理

---

文件格式规范

todo.md 格式

# 项目待办事项清单

## 使用说明
- 完成后删除对应任务，记录到 work_done.md
- 按业务模块分类，每个模块对应 `.dev_doc/` 下的独立目录，复杂模块可建立多层文档结构
- 所有模块统一按优先级排序，处理优先级：P0 > P1 > P2 > P3
- 每次删除任务后，及时修改任务编号
- 如果没有P0的任务，选一个你觉得最重要的P1任务改为P0
- 不估算工作量，由用户自行判断

## 本周计划（如有）
{本周计划内容，见模式三}

## 本月计划（如有）
{本月计划内容，见模式四}

## 当前待办

### {模块名}
- 【P{优先级}] {任务编号}.{子任务编号} {任务标题}
  - 模块：{所属模块}
  - 描述：{任务详细描述}
  - DDL：{截止日期，如有}
  - 分支：{当前所在分支名}
  - 状态：{待开发/进行中}
  - 添加日期：{YYYY-MM-DD}

work_done.md 格式

# 已完成事项清单

> 更新日期: {日期}

---

## Changelog
### {YYYY-MM-DD}
- {变更记录}

---

## {模块名}
- 【P{优先级}] {任务标题}
  - 完成日期：{YYYY-MM-DD}
  - 分支：{git branch}
  - 涉及代码：{文件列表}
  - 功能特性：{简要说明}

---

触发条件汇总

用户说法	触发功能
"记录这个需求" / "添加一个任务"	Add
"看看优先级" / "调整优先级"	Prioritize
"XX完成了" / "ez-dev P6"	Verify
"当前有什么" / "现在在做什么" / "当前进度"	当前状态模式
"本周计划" / "这周计划" / 每周一早上	每周计划模式
"本月计划" / "这个月计划" / 每月1号	每月计划模式
"进度如何" / "完成了吗" / "调整计划"	进度确认与调整
"清理已完成任务" / "清理 todo" / "同步任务状态"	独立清理模式
每周一首次对话	自动触发本周进度确认

---

注意事项

1. 最小单元是子任务：不要只更新父任务，要细化到具体可执行的子任务
2. 验证是核心：完成验证确保代码、文档、实际实现三者一致（原则6）
3. 用户确认是必须的：Verify 结论需要用户确认后才能移动到 work_done.md
4. 自动记录变更：所有优先级调整都要记录到 changelog
5. 中文输出：所有输出内容使用中文
6. 工作日约束：默认只安排周一至周五，周末不安排
7. 计划写到 todo.md：每周/每月计划作为特殊区块写入 todo.md 顶部，过期后移动到 work_done.md
8. 时效管理：超过2周未动的任务标记为存疑（原则4）
9. 持续流动：不按日分解任务，关注当前进行中和待启动，完成后补充新任务
10. 不盲目估计：不主动估算工作量，由用户自行判断