工作待办流（work-todo-organizer）
用途
把「想到要做的事」变成可跟、可提醒、可复盘的结构化流程，而不是散落的便签和记忆。四件事：
- 整理 —— 收拢待办，按紧迫度分组，一眼看清该先动哪件
- 轻提醒 —— 周期性（每日/每周）推送简短提醒，只点最该动的几件，不催命
- 记录 —— 完成即归档，带时间线、历时、过程备注，可回溯
- 复盘 —— 以「整件事」为单位输出生命周期报告（步骤时间线 + 卡点 + 引导问题）
何时使用
- 用户说「整理一下我最近要处理的事」「有哪些待办」「帮我盯着这件事」
- 用户交代一件新活，或让你把目录里带「待确认/待修改/待处理」的文件整理成待办
- 用户要求「每天/每周提醒我」「早点提醒我」「有周期性任务要跟」
- 用户问「这件事进展到哪了」「上个月做完了什么」「复盘一下这个项目」
- 用户要「待办看板」「把待办导出成文档」
核心引擎
scripts/todo.py，纯标准库，无需安装依赖。所有操作都通过它执行：
PY="<本机 python 绝对路径>"
T="<本 skill 目录>/scripts/todo.py"
"$PY" "$T" --store "<workspace>/.workbuddy/todo-flow/todos.json" <命令>
存储位置：默认自动向上查找 <workspace>/.workbuddy/，数据落在 .workbuddy/todo-flow/todos.json；跨工作区使用时显式传 --store。不要手改这个 JSON，一律走命令。在 Windows + Git Bash 下先 export PYTHONIOENCODING=utf-8，中文输出才不乱码。
命令速查
| 命令 | 作用 |
|---|---|
init |
初始化待办库（幂等） |
add "标题" [--project P] [--due D] [--repeat R] [--priority high\|mid\|low] [--tag a,b] [--step "甲;乙;丙"] [--note N] [--source S] |
新增待办。--due 支持 2026-10-08 / 明天 / 10-08；--repeat 支持 daily/weekly/biweekly/monthly/quarterly |
list [--view all\|overdue\|today\|week\|done\|archived] [--project P] [--tag T] [--json] |
整理视图，自动按 逾期/今天/本周/更远/无期限 分组 |
digest [--date D] |
只生成轻提醒文案，不改数据 |
daily |
每日巡检：先把已完成的周期事项滚动出新一期，再出提醒 |
done <编号> [--note "..."] |
完成整件事；加 --step K 只完成第 K 步 |
reopen <编号> / edit <编号> ... / note <编号> "..." |
重开 / 修改 / 记一笔过程 |
rollover [--after N] |
逾期巡检，把逾期项写入事件流 |
log [--days 30] |
完成记录（近 N 天，按项目汇总） |
review --id <编号> / review --project <项目> |
整件事复盘：步骤时间线、卡点提示、引导问题（设置角色后会追加「角色视角」） |
board --out <路径> |
导出可读看板 markdown |
role [名称] |
查看/设置角色：executor 打工人 · owner 负责人 · manager 管理者 · boss 老板。角色决定对上口径，并影响提醒与复盘 |
stats |
概览（含当前角色） |
<编号> 支持数字（3）、标题关键词（验收报告，唯一匹配才生效）；匹配到多条会自动列出候选让你指定。
工作流
〇、先定角色（第一次用、或场景变化时）
同一个用户，在不同位置对上（老板/领导）的接口不一样——汇报说什么、什么该自己定、什么必须上报，全都不一样。所以先定角色，再谈口径。
- 用户明说了就照设：
role 负责人/role 打工人/role 管理者/role 老板 - 用户没说时，按场景匹配（拿不准就问一句，别默认）：
- 「领导让我去做…」→
executor - 「这事我负责 / 我要对结果交代 / 我离老板近」→
owner - 「我下面有几个项目 / 我要盘整条线」→
manager - 「我定方向 / 我批资源」→
boss
角色写入 <workspace>/.workbuddy/todo-flow/config.json，持久生效：digest/daily 会带上角色口径行，review 会追加「角色视角」自检。也可用 --role 临时覆盖一次。
四个角色的完整定义（位置 / 对上口径 / 老板要什么 / 忌讳 / 决策边界 / 汇报模板 / 复盘重点）见 references/roles.md。
一、整理（把散事变成条目）
- 先看现状：
list，必要时list --view overdue。 - 逐条
add。拆解要落到「下一步动作」：--step写 2–5 个可执行步骤，别写「推进项目」这种不可判定的短语。
标题写成要交的东西，不要写成对方问的问题——「给出方案B的结论与批复口径」优于「答复老板6问」；后者会让整件事沦为被动应答（见references/case-emotion-driven.md）。 - 归属用
--project，与用户目录分类保持一致（如8.项目/克东、9.供应链平台、5.工作安排），便于整批复盘。 - 来源能追溯就用
--source记原始文件路径——复盘要能回到出处。 - 从目录采集待办的判据：
- 文件名含待确认/待修改/待处理/修改清单/待定
- 周期性材料（周计划、月报、报销表）
- 采集完必须把「哪个文件 → 变成哪条待办」告诉用户，不要静默造条目。
二、轻提醒（每日/每周）
先说结论再给动作，一次最多点 3 件，语气陈述不催促。生成用 daily（含周期滚动）。
要「自动提醒」时，用 automation_update 建一条周期自动化，prompt 必须自包含：
> 执行工作待办流：运行 "<python绝对路径>" "<skill目录>/scripts/todo.py" --store "<workspace>/.workbuddy/todo-flow/todos.json" daily（Git Bash 下先 export PYTHONIOENCODING=utf-8），把输出作为提醒发给用户；若有逾期项，用一句话说明最该先收尾的是哪一件。
节奏按用户要求设定，默认建议工作日每天 09:30 一次（FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=9;BYMINUTE=30）。用户明确说「别天天提」时降到每周一次。
三、记录（完成即归档）
- 用户说「做完了/搞定了」→ 先
list定位编号再done，附--note写清「做了什么、卡过什么」。备注是复盘素材，别写「已完成」这种废话。 - 多步骤事项做到一半 →
done <编号> --step K，只推进该步，整件不结。 - 周期性事项完成后不要立刻手工建新条目：
daily会自动滚动出新一期并续上截止日。 - 新过程信息用
note追加，不要用edit --note反复覆盖。
四、整件事复盘
用户说「复盘」「这件怎么拖这么久」「这个项目干完总结一下」时：
review --id <编号>（单件）或review --project <项目>（整批）。- 把输出的步骤时间线和提醒次数读给用户——提醒次数偏高就是卡点信号（引擎会标出来）。
- 必须补上引擎给不了的判断：结合
notes与history指出真实卡点（等信息 / 等确认 / 没排期 / 步骤本身太粗），并给下一次的具体动作建议。详细话术与卡点分类见references/review-playbook.md。 - 识别「被动应答」：若整件事的步骤全是「回应/答复对方追问」而无产出物，按被动应答处理——根因是被情绪牵着走、漏掉诉求层，先修诉求识别再谈执行。判据与改法见
references/case-emotion-driven.md。 - 识别「情绪驱动」：若整件事的动作全是「澄清/解释/自证」而无推进，按情绪驱动处理——根因是把精力花在「证明我没错」而不是「把活干完」。判据、纠错边界与信源核实见
references/case-result-over-emotion.md。 - 复盘结论若形成可复用的检查项，写进工作区记忆（
.workbuddy/memory/MEMORY.md），下次同类事提前避坑。
五、沟通判断辅助（复盘之外的常用口径）
用户描述一次沟通冲突、问「我该怎么回」时，按这几条判：
- 三层拆解：先分情绪 / 诉求 / 事实，重点抓诉求。见
case-emotion-driven.md。 - 两问前置：①「这事谁定的？」——已拍板的方向不必向执行方重新论证；②「他说的和我说的是不是同一件事？」——口径冲突先拆范围再谈对错。
- 纠错边界：领导说错了，默认不主动纠正；但错误影响钱 / 合同 / 责任时必须当场说。判据一句话：这个错会不会影响钱/合同/责任？
- 信源核实：关键结论要双信源或书面确认；对外陈述标注来源（「据 XX 反馈」），冲突时是转述而非背书。
- 结果优先：你是做事的，情绪得放下，事情得做好，因为领导看的是结果，不是看你错没错。 见
case-result-over-emotion.md。 - 成体系，再迭代：不要每次只处理事情的一小节。 先立框架（方法 / 尺寸 / 章法），再往里填事，跑一轮再迭代。同一条线第二次出现时，先翻上一条同类事项的
steps与notes，能套就套——套用一次就是一次迭代。见roles.md。 - 正视问题，不逃避：卡住了就说卡在哪、卡在谁，这不是示弱，是负责人的本职。逃避的样子是「不报坏消息」「把再等等当动作」「用过程描述掩盖没进展」。判据：这句话发出去，对方能不能据此行动？ 不能就是还在绕。
六、与其他产物的配合
- 看板：
board --out "<workspace>/最近待办/待办看板.md"，让用户直接打开核对；工作区已有「最近待办」文件夹时就放那里。 - 周期归档：滚动出的旧期次留在库中（
status=archived），log里仍可见，便于月度回看。
注意事项
- 不编造：库里没有的完成记录不补写，日期以实际时间戳为准；补录历史事项时在
--note里注明是补录。 - 不擅自批量删改：
archived由周期滚动产生，不要手动清理；批量变更前先list --json给用户确认。 - 日期歧义：
10-08这类无年份写法按「已过半年算明年」处理；跨年任务写全2026-10-08。 - 数据只落在工作区
.workbuddy/下，不上传、不外发。
数据结构
字段含义见 references/data-schema.md（排查异常或做统计时查阅）。
参考文档
references/roles.md— 角色：打工人 / 负责人 / 管理者 / 老板的对上口径、边界，负责人的「方法·尺寸·章法」，成体系再迭代references/case-emotion-driven.md— 案例：被动应答（被情绪牵着走、接错层）references/case-result-over-emotion.md— 案例：情绪放下、事情做好（自证 vs 结果、纠错边界、信源核实）references/review-playbook.md— 卡点分类、汇报口径、情绪驱动与被动应答的识别references/data-schema.md— 数据字段说明（含config.json）
