| 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 拉取新任务加入当前队列
- 只规划当前 + 待办：本周/月计划只列"当前进行中"和"待启动"，不做每日分解
- 队列状态：用
⬜未开始/🔄进行中/✅已完成 标记，不估算工时
完成标准（三者缺一不可）
- Git合并：代码已合并到主分支（main/dev_zby）
- 文档状态：开发文档（
.dev_doc/{模块}/）已更新标记状态
- 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 修复
执行流程：
- 用户报告"XX 完成了"时，先判定粒度——是大功能点还是补丁？
- 补丁 → 在所属大功能点的"补丁记录"区追加，不建新条目
- 大功能点首次完成 → 建主条目，后续补丁不断累积
- 粒度拿不准时 → 列 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：有分支信息
如果任务有 分支：字段：
- 执行
git branch --merged {main_branch} | grep {分支名}
- 如果分支已合并 → 判定为已完成
- 如果分支未合并 → 进入阶段 2
阶段 2：无分支信息或阶段 1 未通过
从任务描述中提取 2-3 个关键词（如"Milvus 批量插入"），执行：
git log --oneline main --all --grep="{关键词}" -n 5
git log --oneline main --all -S "{关键词}" -n 3
时效检查
- 检查任务
添加日期 距离当前日期是否超过2周
- 超过2周且无进展 → 标记为「存疑」
执行流程
- 对每个未标记"已完成"的任务执行检测
- 已合并：追加到 work_done.md，从 todo.md 删除
- 未合并：保持原样
- 无法判断：标记为"存疑"，询问用户
输出报告
### 任务清理报告
- 【已迁移】{任务标题} → 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，对每个未标记"已完成"的任务：
-
检查 Git merge 状态：
git branch --merged {main_branch} — 检查该分支是否已合并git log --oneline {main_branch}..HEAD — 当前分支独有的 commits
-
检查时效（原则4）：
- 计算
添加日期 距离当前日期
- 超过2周 → 标记为「存疑」
-
分类处理：
- 已合并到 main/dev_zby → 执行迁移
- 未合并且有未完成工作 → 保持不动
- 无法自动判断 → 标记为"存疑"
Step 2: 执行迁移
对每个"已合并"任务：
- 读取任务完整信息（标题、模块、描述、工作量）
- 追加到
work_done.md 对应模块
- 从
todo.md 中删除该任务
- 重新编号后续任务
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" / "同步任务状态" | 独立清理模式 |
| 每周一首次对话 | 自动触发本周进度确认 |
注意事项
- 最小单元是子任务：不要只更新父任务，要细化到具体可执行的子任务
- 验证是核心：完成验证确保代码、文档、实际实现三者一致（原则6）
- 用户确认是必须的：Verify 结论需要用户确认后才能移动到 work_done.md
- 自动记录变更：所有优先级调整都要记录到 changelog
- 中文输出：所有输出内容使用中文
- 工作日约束：默认只安排周一至周五，周末不安排
- 计划写到 todo.md：每周/每月计划作为特殊区块写入 todo.md 顶部，过期后移动到 work_done.md
- 时效管理：超过2周未动的任务标记为存疑（原则4）
- 持续流动：不按日分解任务，关注当前进行中和待启动，完成后补充新任务
- 不盲目估计：不主动估算工作量，由用户自行判断
