基于 TASKS.md 的轻量任务管理knowledge-work-plugins 任务管理技能实战指南【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins导读本文围绕 knowledge-work-plugins 仓库中 productivity 插件的核心技能之一 —— task-management 技能 —— 展开深入讲解如何用一份可被人类与 AI Agent 共同编辑的TASKS.md纯文本文件搭建一套零依赖、可版本控制、随时可迁移的任务管理系统。读完本文你将掌握TASKS.md的标准格式与模板、与 Agent 交互的四类核心请求协议查看 / 添加 / 完成 / 等待项、可视化看板 dashboard.html 与文本文件之间的双向同步原理以及它与/start、/update、memory-management 技能协同工作的完整闭环。一、设计理念为什么选择一份纯文本文件task-management 技能的核心设计只有一个任务全部记录在名为TASKS.md的 Markdown 文件中Agent 与用户都可以直接编辑它。这个选择并非偶然而是有意为之单一事实来源不需要数据库、不需要服务端任务状态只存在于一份可读的文本文件中任何一方都不会看到另一个版本人与 Agent 平等协作用户可以用任意编辑器修改TASKS.mdAgent 通过读写同一路径感知变化双方编辑的是同一个文件天然可版本控制TASKS.md是普通文本可以直接纳入 Git 管理历史记录、回滚、多人评审都无障碍零依赖可迁移不绑定任何特定任务管理 SaaS即使更换工具链任务数据也始终以人类可读的 Markdown 形式存在。从 productivity/README.md 的描述看该插件面向 Claude Cowork 设计任务管理是三大能力之一另两个是工作场所记忆与可视化看板而TASKS.md正是整个任务子系统的数据枢纽。二、文件位置约定始终使用当前工作目录下的 TASKS.md技能对文件位置有明确且强制的约定始终使用当前工作目录current working directory中的TASKS.md。具体规则如果TASKS.md已存在则读取/写入该文件如果不存在则按下文的标准模板新建一个。将任务文件放在工作目录而非某个隐藏的配置目录是为了让任务列表与当前项目/工作上下文保持同址方便用户随手打开、随手修改也便于纳入项目本身的版本控制。配套的 start 技能 在初始化时会检查工作目录中的TASKS.md、CLAUDE.md、memory/、dashboard.html四项资产缺失即创建保持任务与记忆都在手边的工作形态。三、首次运行Dashboard 引导与可视化看板3.1 首次交互的引导流程该技能只在第一次与任务交互时执行一次引导检查当前工作目录是否存在dashboard.html如果不存在从${CLAUDE_PLUGIN_ROOT}/skills/dashboard.html仓库中即 productivity/skills/dashboard.html复制到当前工作目录告知用户Ive added the dashboard. Run/productivity:startto set up the full system.已添加看板运行/productivity:start完成整套系统初始化。注意第 3 步提到的/productivity:start会进一步补齐CLAUDE.md与memory/目录并引导记忆系统初始化详见 start 技能。3.2 看板Dashboard的核心能力从 dashboard.html 的源码可以确认看板具备以下能力且每一项都与TASKS.md文件严格绑定能力源码依据说明读写同一个TASKS.mdparseTaskMarkdown()L1337 起与toMarkdown()L1399 起打开文件时解析 Markdown 渲染成卡片保存时把看板状态序列化回 Markdown自动保存markChanged()autoSave()L1845-L1869任何修改触发 500ms 防抖后自动写回文件监视外部更改checkForExternalChanges()startWatching()L1871-L1894每 1 秒轮询文件的lastModified检测到外部如 CLI 编辑改动即重新解析并重渲染拖拽排序moveTask()/moveSection()L1795-L1827支持任务跨分区拖拽、分区重排排序结果序列化回 Markdown看板通过 File System Access API 的showOpenFilePicker()见openTaskFile()L2436 起让用户选择TASKS.md随后便可持续写入与监听——这就是从看板编辑或从文件编辑两边保持同步的技术实现看板是文件的可视化外壳文件才是唯一事实来源。3.3 在 Cowork 中打开看板的注意事项start 技能特别强调Agent 运行在虚拟环境中不要使用open或xdg-open这类 shell 命令去打开看板——它们无法触达用户的浏览器。正确做法是告知用户Dashboard is ready atdashboard.html. Open it from your file browser to get started.由用户从文件浏览器自行打开。四、TASKS.md 格式与模板4.1 标准模板新建TASKS.md时必须使用以下精确模板不含示例任务# Tasks ## Active ## Waiting On ## Someday ## Done模板定义了四个分区语义清晰Active当前进行中的任务Waiting On等待他人或外部条件的事项Someday暂不排期的想法型任务Done已完成任务的归档区。看板渲染时正是按##二级标题解析分区parseTaskMarkdown()中line.match(/^## \*{0,2}(.?)\*{0,2}$/)因此分区名可以自定义、可增删解析器会动态重建分区列表。4.2 任务行的书写格式任务行的规范格式为- [ ] **任务标题** - 上下文为谁截止日期要点以- [ ]开头表示未完成- [x]大小写均可表示已完成任务标题用加粗便于快速扫读标题后的-分隔符后接上下文说明为谁、截止日期等子细节用缩进的两空格子项目符号- ...逐条补充已完成的任务- [x] ~~任务~~ (完成日期)同时加删除线与完成日期。4.3 看板与格式的双向映射源码印证看板的序列化逻辑toMarkdown()与解析逻辑parseTaskMarkdown()精确对应解析时- [xX]开头的行识别为任务行内**加粗**部分拆分为标题其后内容拆分为备注note缩进两空格的- [ ]识别为子任务序列化时卡片重新拼回- [ ] **标题** - 备注子任务还原为缩进行保证看板上的任何操作——勾选、改标题、加备注、增删子任务——都能无损写回 Markdown 文件。这意味着用户既可以在看板上用鼠标操作也可以直接编辑文本两种方式产生的文件格式完全互通。五、与 Agent 的交互协议task-management 技能为 Agent 定义了四类典型请求的标准响应协议这也是整个技能可被可靠调用的行为契约5.1 查看任务当用户问 whats on my plate / my tasks我手头有什么任务时读取TASKS.md总结Active与Waiting On两个分区的内容特别标出任何已逾期或紧急的任务。5.2 添加任务当用户说 add a task / remind me to添加任务/提醒我时以- [ ] **任务**格式加入Active分区用户提供了上下文为谁、截止日期则一并写入。5.3 完成任务当用户说 done with X / finished XX 做完了时Agent 执行标准四步在文件中定位该任务将[ ]改为[x]给任务标题加删除线~~task~~追加完成日期将该行移动到Done分区。5.4 查看等待项当用户问 what am I waiting on我在等什么时读取Waiting On分区注明每一项已等待了多长时间依赖约定中的 since [date] 标注。这套协议的价值在于确定性无论任务文件被如何编辑Agent 面对同一类请求都执行同一套动作用户可以预期地依赖这个行为。六、书写约定与维护规则为保证TASKS.md长期可读、可扫视、可被 Agent 稳定解析技能规定了如下约定任务标题加粗便于快速扫读若是对某人的承诺注明for [person]为谁有截止日期时注明due [date]等待类事项注明since [date]自何时起等待附加上下文用子项目符号逐条展开Done 分区保留约一周之后清理旧条目保持文件精简。这些约定看似简单却是人机可共同编辑的关键加粗让人类扫读舒服[ ]/[x]与日期让 Agent 解析稳定而 Done 分区的定期清理则防止文件无限膨胀、失去可读性。七、从会议与对话中提取任务在总结会议或对话时技能要求 Agent主动提议将其中隐藏的任务提取出来用户做出的承诺如 Ill send that over分配给用户的行动项被提及的跟进事项。但有一条硬性边界必须先询问用户得到确认后再添加绝不自动写入。这一原则与 update 技能 中的 Never auto-add tasks or memories without user confirmation未经确认绝不自动添加任务或记忆一脉相承——AI 可以敏锐地发现候选任务但写入决策权始终在用户手中。八、与周边技能的协同工作流task-management 并非孤立存在它在 productivity 插件中与另外三个组件形成闭环组件作用与任务管理的关系start 技能首次初始化创建/补齐TASKS.md、dashboard.html、CLAUDE.md、memory/并引导记忆引导流程update 技能日常同步从外部工具Asana/Linear/Jira 等 MCP 源或gh issue list拉取任务做差异对比清理过期项扫描聊天/邮件/日历挖掘遗漏的待办memory-management 技能记忆解码任务里出现的昵称、缩写、项目代号如 PSR、Phoenix通过双层记忆CLAUDE.md热缓存 memory/深存储解码成完整上下文典型闭环/start初始化 → 日常对话中添加任务 →/update与外部追踪器同步并清理过期项 → 任务中出现生僻缩写时由记忆系统解码或向用户提问补齐。三者的关系在 productivity/README.md 的示例工作流中有完整演示。九、从零开始的完整实战流程综合上述所有内容一个完整的落地流程如下初始化首次交互时 Agent 检查并复制 dashboard.html提示运行/productivity:start补齐TASKS.md若无与记忆系统建文件按第四节模板创建TASKS.md四个分区就位日常添加随时对 Agent 说加一个任务周三前给 Sarah 发预算评审Agent 按- [ ] **...** - for Sarah, due ...格式写入 Active可视化操作用户从文件浏览器打开dashboard.html通过 File System Access API 选中TASKS.md即可在看板上拖拽排序、勾选完成、编辑备注500ms 后自动保存回文件若用户同时在编辑器里改文件看板 1 秒内感知外部变化并重载完成与归档向 Agent 说预算评审做完了Agent 执行勾选、删除线、加日期并移入 DoneDone 保留约一周后清理周期性同步运行/productivity:update从外部任务源同步差异、清理 30 天以上的 Active 项、补齐记忆缺口需要深度扫描时运行/productivity:update --comprehensive。十、适用边界与注意事项依赖浏览器能力看板的自动保存与外部变更监视依赖 File System Access APIshowOpenFilePicker在 Chrome/Edge 等支持的浏览器中可完整工作不支持该 API 的环境只能手动选择文件体验会受限。Agent 行为约束任务提取、外部任务同步均以先询问、后写入为原则用户无需担心被静默修改文件。文件即权威任何一方看板或编辑器的修改最终都要落回TASKS.md保持该文件的格式规范[ ]/[x]、加粗标题、##分区是两端同步不出错的前提。纯文本的天花板它不具备原生任务管理 SaaS 的通知推送、依赖关系图等能力但换来的是零依赖、可版本控制与极低迁移成本——对于以人机协作、文件为本为目标的场景这是最合适的复杂度。如需了解可接入的外部工具与 MCP 连接器可查看 productivity/CONNECTORS.md完整技能定义与模板请参阅 task-management/SKILL.md。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 TASKS.md 的轻量任务管理：knowledge-work-plugins 任务管理技能实战指南
基于 TASKS.md 的轻量任务管理knowledge-work-plugins 任务管理技能实战指南【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins导读本文围绕 knowledge-work-plugins 仓库中 productivity 插件的核心技能之一 —— task-management 技能 —— 展开深入讲解如何用一份可被人类与 AI Agent 共同编辑的TASKS.md纯文本文件搭建一套零依赖、可版本控制、随时可迁移的任务管理系统。读完本文你将掌握TASKS.md的标准格式与模板、与 Agent 交互的四类核心请求协议查看 / 添加 / 完成 / 等待项、可视化看板 dashboard.html 与文本文件之间的双向同步原理以及它与/start、/update、memory-management 技能协同工作的完整闭环。一、设计理念为什么选择一份纯文本文件task-management 技能的核心设计只有一个任务全部记录在名为TASKS.md的 Markdown 文件中Agent 与用户都可以直接编辑它。这个选择并非偶然而是有意为之单一事实来源不需要数据库、不需要服务端任务状态只存在于一份可读的文本文件中任何一方都不会看到另一个版本人与 Agent 平等协作用户可以用任意编辑器修改TASKS.mdAgent 通过读写同一路径感知变化双方编辑的是同一个文件天然可版本控制TASKS.md是普通文本可以直接纳入 Git 管理历史记录、回滚、多人评审都无障碍零依赖可迁移不绑定任何特定任务管理 SaaS即使更换工具链任务数据也始终以人类可读的 Markdown 形式存在。从 productivity/README.md 的描述看该插件面向 Claude Cowork 设计任务管理是三大能力之一另两个是工作场所记忆与可视化看板而TASKS.md正是整个任务子系统的数据枢纽。二、文件位置约定始终使用当前工作目录下的 TASKS.md技能对文件位置有明确且强制的约定始终使用当前工作目录current working directory中的TASKS.md。具体规则如果TASKS.md已存在则读取/写入该文件如果不存在则按下文的标准模板新建一个。将任务文件放在工作目录而非某个隐藏的配置目录是为了让任务列表与当前项目/工作上下文保持同址方便用户随手打开、随手修改也便于纳入项目本身的版本控制。配套的 start 技能 在初始化时会检查工作目录中的TASKS.md、CLAUDE.md、memory/、dashboard.html四项资产缺失即创建保持任务与记忆都在手边的工作形态。三、首次运行Dashboard 引导与可视化看板3.1 首次交互的引导流程该技能只在第一次与任务交互时执行一次引导检查当前工作目录是否存在dashboard.html如果不存在从${CLAUDE_PLUGIN_ROOT}/skills/dashboard.html仓库中即 productivity/skills/dashboard.html复制到当前工作目录告知用户Ive added the dashboard. Run/productivity:startto set up the full system.已添加看板运行/productivity:start完成整套系统初始化。注意第 3 步提到的/productivity:start会进一步补齐CLAUDE.md与memory/目录并引导记忆系统初始化详见 start 技能。3.2 看板Dashboard的核心能力从 dashboard.html 的源码可以确认看板具备以下能力且每一项都与TASKS.md文件严格绑定能力源码依据说明读写同一个TASKS.mdparseTaskMarkdown()L1337 起与toMarkdown()L1399 起打开文件时解析 Markdown 渲染成卡片保存时把看板状态序列化回 Markdown自动保存markChanged()autoSave()L1845-L1869任何修改触发 500ms 防抖后自动写回文件监视外部更改checkForExternalChanges()startWatching()L1871-L1894每 1 秒轮询文件的lastModified检测到外部如 CLI 编辑改动即重新解析并重渲染拖拽排序moveTask()/moveSection()L1795-L1827支持任务跨分区拖拽、分区重排排序结果序列化回 Markdown看板通过 File System Access API 的showOpenFilePicker()见openTaskFile()L2436 起让用户选择TASKS.md随后便可持续写入与监听——这就是从看板编辑或从文件编辑两边保持同步的技术实现看板是文件的可视化外壳文件才是唯一事实来源。3.3 在 Cowork 中打开看板的注意事项start 技能特别强调Agent 运行在虚拟环境中不要使用open或xdg-open这类 shell 命令去打开看板——它们无法触达用户的浏览器。正确做法是告知用户Dashboard is ready atdashboard.html. Open it from your file browser to get started.由用户从文件浏览器自行打开。四、TASKS.md 格式与模板4.1 标准模板新建TASKS.md时必须使用以下精确模板不含示例任务# Tasks ## Active ## Waiting On ## Someday ## Done模板定义了四个分区语义清晰Active当前进行中的任务Waiting On等待他人或外部条件的事项Someday暂不排期的想法型任务Done已完成任务的归档区。看板渲染时正是按##二级标题解析分区parseTaskMarkdown()中line.match(/^## \*{0,2}(.?)\*{0,2}$/)因此分区名可以自定义、可增删解析器会动态重建分区列表。4.2 任务行的书写格式任务行的规范格式为- [ ] **任务标题** - 上下文为谁截止日期要点以- [ ]开头表示未完成- [x]大小写均可表示已完成任务标题用加粗便于快速扫读标题后的-分隔符后接上下文说明为谁、截止日期等子细节用缩进的两空格子项目符号- ...逐条补充已完成的任务- [x] ~~任务~~ (完成日期)同时加删除线与完成日期。4.3 看板与格式的双向映射源码印证看板的序列化逻辑toMarkdown()与解析逻辑parseTaskMarkdown()精确对应解析时- [xX]开头的行识别为任务行内**加粗**部分拆分为标题其后内容拆分为备注note缩进两空格的- [ ]识别为子任务序列化时卡片重新拼回- [ ] **标题** - 备注子任务还原为缩进行保证看板上的任何操作——勾选、改标题、加备注、增删子任务——都能无损写回 Markdown 文件。这意味着用户既可以在看板上用鼠标操作也可以直接编辑文本两种方式产生的文件格式完全互通。五、与 Agent 的交互协议task-management 技能为 Agent 定义了四类典型请求的标准响应协议这也是整个技能可被可靠调用的行为契约5.1 查看任务当用户问 whats on my plate / my tasks我手头有什么任务时读取TASKS.md总结Active与Waiting On两个分区的内容特别标出任何已逾期或紧急的任务。5.2 添加任务当用户说 add a task / remind me to添加任务/提醒我时以- [ ] **任务**格式加入Active分区用户提供了上下文为谁、截止日期则一并写入。5.3 完成任务当用户说 done with X / finished XX 做完了时Agent 执行标准四步在文件中定位该任务将[ ]改为[x]给任务标题加删除线~~task~~追加完成日期将该行移动到Done分区。5.4 查看等待项当用户问 what am I waiting on我在等什么时读取Waiting On分区注明每一项已等待了多长时间依赖约定中的 since [date] 标注。这套协议的价值在于确定性无论任务文件被如何编辑Agent 面对同一类请求都执行同一套动作用户可以预期地依赖这个行为。六、书写约定与维护规则为保证TASKS.md长期可读、可扫视、可被 Agent 稳定解析技能规定了如下约定任务标题加粗便于快速扫读若是对某人的承诺注明for [person]为谁有截止日期时注明due [date]等待类事项注明since [date]自何时起等待附加上下文用子项目符号逐条展开Done 分区保留约一周之后清理旧条目保持文件精简。这些约定看似简单却是人机可共同编辑的关键加粗让人类扫读舒服[ ]/[x]与日期让 Agent 解析稳定而 Done 分区的定期清理则防止文件无限膨胀、失去可读性。七、从会议与对话中提取任务在总结会议或对话时技能要求 Agent主动提议将其中隐藏的任务提取出来用户做出的承诺如 Ill send that over分配给用户的行动项被提及的跟进事项。但有一条硬性边界必须先询问用户得到确认后再添加绝不自动写入。这一原则与 update 技能 中的 Never auto-add tasks or memories without user confirmation未经确认绝不自动添加任务或记忆一脉相承——AI 可以敏锐地发现候选任务但写入决策权始终在用户手中。八、与周边技能的协同工作流task-management 并非孤立存在它在 productivity 插件中与另外三个组件形成闭环组件作用与任务管理的关系start 技能首次初始化创建/补齐TASKS.md、dashboard.html、CLAUDE.md、memory/并引导记忆引导流程update 技能日常同步从外部工具Asana/Linear/Jira 等 MCP 源或gh issue list拉取任务做差异对比清理过期项扫描聊天/邮件/日历挖掘遗漏的待办memory-management 技能记忆解码任务里出现的昵称、缩写、项目代号如 PSR、Phoenix通过双层记忆CLAUDE.md热缓存 memory/深存储解码成完整上下文典型闭环/start初始化 → 日常对话中添加任务 →/update与外部追踪器同步并清理过期项 → 任务中出现生僻缩写时由记忆系统解码或向用户提问补齐。三者的关系在 productivity/README.md 的示例工作流中有完整演示。九、从零开始的完整实战流程综合上述所有内容一个完整的落地流程如下初始化首次交互时 Agent 检查并复制 dashboard.html提示运行/productivity:start补齐TASKS.md若无与记忆系统建文件按第四节模板创建TASKS.md四个分区就位日常添加随时对 Agent 说加一个任务周三前给 Sarah 发预算评审Agent 按- [ ] **...** - for Sarah, due ...格式写入 Active可视化操作用户从文件浏览器打开dashboard.html通过 File System Access API 选中TASKS.md即可在看板上拖拽排序、勾选完成、编辑备注500ms 后自动保存回文件若用户同时在编辑器里改文件看板 1 秒内感知外部变化并重载完成与归档向 Agent 说预算评审做完了Agent 执行勾选、删除线、加日期并移入 DoneDone 保留约一周后清理周期性同步运行/productivity:update从外部任务源同步差异、清理 30 天以上的 Active 项、补齐记忆缺口需要深度扫描时运行/productivity:update --comprehensive。十、适用边界与注意事项依赖浏览器能力看板的自动保存与外部变更监视依赖 File System Access APIshowOpenFilePicker在 Chrome/Edge 等支持的浏览器中可完整工作不支持该 API 的环境只能手动选择文件体验会受限。Agent 行为约束任务提取、外部任务同步均以先询问、后写入为原则用户无需担心被静默修改文件。文件即权威任何一方看板或编辑器的修改最终都要落回TASKS.md保持该文件的格式规范[ ]/[x]、加粗标题、##分区是两端同步不出错的前提。纯文本的天花板它不具备原生任务管理 SaaS 的通知推送、依赖关系图等能力但换来的是零依赖、可版本控制与极低迁移成本——对于以人机协作、文件为本为目标的场景这是最合适的复杂度。如需了解可接入的外部工具与 MCP 连接器可查看 productivity/CONNECTORS.md完整技能定义与模板请参阅 task-management/SKILL.md。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考