From dev-toolkits
Manages development tasks via todo.md and work_done.md: recording requirements, prioritizing, marking completion, generating weekly/monthly plans, and tracking progress.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-toolkits:todo_list_managerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
本 skill 负责管理 `.dev_doc/todo.md` 和 `.dev_doc/work_done.md`,提供需求录入、优先级排序、完成验证、工作量估算、变更记录,以及每周、每月计划管理六大核心能力。
本 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 | 不重要不紧急 | 有空处理 |
⬜未开始/🔄进行中/✅已完成 标记,不估算工时.dev_doc/{模块}/)已更新标记状态核心:
判定标准(同时满足才算独立条目):
| 维度 | 独立条目(建新条目) | 补丁(合并到现有条目) |
|---|---|---|
| 业务边界 | 解决独立的用户场景/问题域 | 隶属于已有大功能点的局部优化 |
| 文档载体 | 需要独立 .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
- stdq 中范围重构
- stdq 多日 query TypeError 修复
- stdq duckdb 写 parquet 修复
执行流程:
1.3 数据库 Skill 重构(1) 封装cli| 尺度 | 触发条件 | 范围 |
|---|---|---|
| 每周 | 每周一早上 / "本周计划" | 本周 |
| 每月 | 每月1号 / "本月计划" | 本月 |
| 随时 | "进度如何" / "当前有什么" | 当前状态 |
当用户说"记录需求"、"调整优先级"、"XX完成了"时触发。
当用户提供新需求时:
Step 1: 解析需求 从用户描述中提取:
.dev_doc/ 下目录)Step 2: 生成 todo 条目
格式:
- 【P{优先级}] {任务编号}.{子任务编号} {任务标题}
- 模块:{所属模块}
- 描述:{任务详细描述}
- DDL:{截止日期,如有}
- 分支:{当前所在分支名}
- 状态:{待开发/进行中}
- 添加日期:{YYYY-MM-DD}
Step 3: 更新 todo.md
当用户要求查看或调整优先级时,执行综合评分模型。
| 维度 | 权重 | 评分标准 |
|---|---|---|
| 业务价值 | 0-30 | 对核心场景的影响程度 |
| 依赖关系 | 0-20 | 是否 block 其他关键任务 |
| 紧迫度 | 0-25 | DDL 或业务时限的远近 |
| 认知清晰度 | 0-10 | 需求理解越清晰越高分 |
业务价值 (0-30):
依赖关系 (0-20):
紧迫度 (0-25):
认知清晰度 (0-10):
## 优先级分析报告
### 当前任务优先级列表(按综合评分降序)
| 排名 | 任务 | 综合评分 | 业务价值 | 依赖关系 | 紧迫度 | 认知清晰度 | 建议 |
|------|------|---------|---------|---------|--------|-----------|------|
| 1 | xxx | 85 | 28 | 18 | 22 | 5 | P0 |
| ... | ... | ... | ... | ... | ... | ... | ... |
### 优先级调整建议
- 【建议 P0→P1】xxx:原因...
- 【建议新增 P0】xxx:原因...
注意:不根据工作量评分,工作量由用户自行判断。
当 ez-dev 到达 P6 阶段,或用户说"XX完成了"时触发。
1. Git合并状态
git branch --merged {main_branch} 或 git log --oneline main..{分支名}2. 开发文档状态
.dev_doc/{模块}/ 下是否有对应开发文档3. Git提交情况
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. 功能完整性
- 子任务闭环:✓/✗ {完成情况}
### 下一步操作
{等待用户确认 / 需要补充的内容}
所有优先级调整自动记录到 work_done.md 的 changelog 区。
## Changelog
### {YYYY-MM-DD}
- 【优先级调整】{任务标题}:{调整内容} → {调整后}
- 原因:{调整原因}
- 【新增任务】{任务标题} → P{优先级}
- 【任务完成】{任务标题} → 已移动到 work_done.md
- 【存疑任务清理】{任务标题} → 超过2周未动,标记为存疑
当用户说"当前有什么"、"现在在做什么"、"当前进度"时触发。
Step 0: 清理已完成任务(每次必做) 在展示当前状态之前,先扫描所有待办任务。
阶段 1:有分支信息
如果任务有 分支:字段:
git branch --merged {main_branch} | grep {分支名}阶段 2:无分支信息或阶段 1 未通过 从任务描述中提取 2-3 个关键词(如"Milvus 批量插入"),执行:
git log --oneline main --all --grep="{关键词}" -n 5
git log --oneline main --all -S "{关键词}" -n 3
git log -n 1 --follow {commit_hash} --name-only
检查 commit 是否涉及任务 模块:目录下的文件(如 services/vector_stores/ 对应 vector-store 模块)
添加日期 距离当前日期是否超过2周### 任务清理报告
- 【已迁移】{任务标题} → 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: 分析本周可用任务
Step 3: 与用户确认周目标 询问用户:
Step 4: 写入 todo.md 并生成周计划
更新 todo.md 顶部,插入本周计划区块:
## 本周计划
### {YYYY}年第{WW}周 ({起始日期} ~ {结束日期})
**本周目标**:{一句话描述核心目标}
#### 当前进行中
| 优先级 | 任务 | 模块 | 状态 |
|--------|------|------|------|
| P0 | xxx | 气象局 | 🔄 |
#### 待启动
| 优先级 | 任务 | 模块 |
|--------|------|------|
| P1 | xxx | MCP |
#### 风险与调整预案
- {风险点}:{应对方案}
---
注意:不按日分解任务,不估算工时,只列出当前进行中和待启动。
自动触发:每月1号自动触发 手动触发:当用户说"本月计划"、"这个月计划"、"帮我安排本月工作"时触发。
Step 0: 清理已完成任务(每次必做) 同当前状态模式,采用两阶段检测策略(分支名优先,其次 git log 关键词搜索),输出任务清理报告。
Step 1: 确定本月范围
Step 2: 分析本月可用任务
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):
添加日期 距离当前日期分类处理:
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: 询问用户更新
Step 3: 输出确认报告
## 进度确认报告
### 日期:{YYYY-MM-DD}
### 已完成
- 【已完成 ✅】任务1 → 移入 work_done.md
### 进行中
- 【进行中 🔄】任务2
- 【进行中 🔄】任务3
### 待启动
- 【待启动 ⬜】任务4
### 调整
- 【新增】任务5 → P1
- 【移除】任务6 → 存疑清理
# 项目待办事项清单
## 使用说明
- 完成后删除对应任务,记录到 work_done.md
- 按业务模块分类,每个模块对应 `.dev_doc/` 下的独立目录,复杂模块可建立多层文档结构
- 所有模块统一按优先级排序,处理优先级:P0 > P1 > P2 > P3
- 每次删除任务后,及时修改任务编号
- 如果没有P0的任务,选一个你觉得最重要的P1任务改为P0
- 不估算工作量,由用户自行判断
## 本周计划(如有)
{本周计划内容,见模式三}
## 本月计划(如有)
{本月计划内容,见模式四}
## 当前待办
### {模块名}
- 【P{优先级}] {任务编号}.{子任务编号} {任务标题}
- 模块:{所属模块}
- 描述:{任务详细描述}
- DDL:{截止日期,如有}
- 分支:{当前所在分支名}
- 状态:{待开发/进行中}
- 添加日期:{YYYY-MM-DD}
# 已完成事项清单
> 更新日期: {日期}
---
## Changelog
### {YYYY-MM-DD}
- {变更记录}
---
## {模块名}
- 【P{优先级}] {任务标题}
- 完成日期:{YYYY-MM-DD}
- 分支:{git branch}
- 涉及代码:{文件列表}
- 功能特性:{简要说明}
| 用户说法 | 触发功能 |
|---|---|
| "记录这个需求" / "添加一个任务" | Add |
| "看看优先级" / "调整优先级" | Prioritize |
| "XX完成了" / "ez-dev P6" | Verify |
| "当前有什么" / "现在在做什么" / "当前进度" | 当前状态模式 |
| "本周计划" / "这周计划" / 每周一早上 | 每周计划模式 |
| "本月计划" / "这个月计划" / 每月1号 | 每月计划模式 |
| "进度如何" / "完成了吗" / "调整计划" | 进度确认与调整 |
| "清理已完成任务" / "清理 todo" / "同步任务状态" | 独立清理模式 |
| 每周一首次对话 | 自动触发本周进度确认 |
npx claudepluginhub ayanjiushishuai/dev_toolkitsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.