boardown：把任务板变成仓库里的 Markdown diff
很多团队说自己想要“项目状态跟代码一起走”，最后还是会落回两个分离世界：代码在 Git，任务在云端 issue 系统。切分本身没有问题，但当一个 feature branch 已经改了 12 个文件、任务板却只剩一句“in progress”时，reviewer 和 coding agent 都要从提交历史里重新推断上下文。真正麻烦的不是没有看板，而是看板不参与 diff、branch 和 review。
今天推荐的 grinev/boardown 走的是反方向：任务板直接住在仓库里的 .boardown/ 目录。release、epic、task 都是 Markdown 文件，随着分支切换、merge conflict、pull request diff 一起出现。它不是要替代 Jira 或 Linear，而是给小团队、个人项目和 agent-heavy workflow 一个更轻的选择：把“接下来做什么”也变成代码库的一部分。
按 GitHub repository page、README、Releases、Tags、LICENSE、package.json、CLI package.json 和公开 git history 在 2026-07-28 能核验的信息，grinev/boardown 当前有 26 stars、1 fork。GitHub 页面显示仓库创建时间为 2026-05-01 23:45:37 UTC；页面和源码结构指向主要语言为 TypeScript，许可证为 MIT。默认分支 main 的当前 HEAD 是 5a86af0，提交时间 2026-07-28 09:29:24 UTC；候选发现时看到的 latest push 是 2026-07-28 09:29:29 UTC。最新 GitHub Release 是 v0.5.2，release 页面显示发布时间为 2026-07-26 11:09:06 UTC；对应 tag 在公开 git history 中的时间是 2026-07-26 11:05:09 UTC。根 package.json 版本为 0.5.2，Node.js 要求 >=20，package manager 为 pnpm 10.33.3；CLI 包名是 @grinev/boardown-cli 0.5.2。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | grinev/boardown |
| 定位 | local-first、git-native 的 Markdown 任务板 |
| Stars | 26 |
| Forks | 1 |
| 主要语言 | TypeScript |
| 许可证 | MIT |
| GitHub 创建时间 | 2026-05-01 23:45:37 UTC |
| 当前默认分支提交 | 5a86af0，2026-07-28 09:29:24 UTC |
| 最新 push | 2026-07-28 09:29:29 UTC |
| 最新 GitHub Release | v0.5.2，2026-07-26 11:09:06 UTC |
| CLI 包 | @grinev/boardown-cli 0.5.2 |
| 运行要求 | Node.js >=20，pnpm 10.x |
| 关键词 | local-first、Markdown、Kanban、VS Code extension、desktop app、CLI、AI agents |
任务状态也应该能 code review
boardown 的核心设计很朴素：数据不是存在一个服务端数据库里，而是存在项目目录的 .boardown/ 下。README 里说 release、epic 和 task 都放在这里，跟代码一起 version、branch、diff。对开发者来说，这意味着任务变更可以像代码一样被 review；对 agent 来说，这意味着 backlog 就在它已经能看到的 workspace 里。
这个点比“又一个 Kanban UI”更重要。云端任务系统擅长跨团队排期、权限、报表和通知，但它们天然在仓库之外。你在 feature branch 上拆了 checklist、补了 caveat、把一个任务移到当前 release，PR reviewer 很可能看不到这些细节。boardown 把这些状态变化变成 Markdown diff，至少让小项目里的任务上下文不再丢到另一个工具里。
它也承认 Git 的代价。README 专门写了分支使用习惯：在 feature branch 上只改当前任务本身，不要顺手重排整块 board；创建任务、拖卡、release lifecycle 这类结构变化尽量在 main branch 上做。原因很实际：Markdown 可以 merge，但任务 ID、移动卡片和跨文件删除/插入仍然会产生冲突。这不是缺点被隐藏起来，而是工具把边界写清楚了。
三个入口读写同一套 .boardown/
boardown 不是只有一个 Web UI。它提供三个入口：VS Code extension、Electron desktop app、以及命令行工具。README 里的安装路径也比较完整：extension 已发布到 VS Code Marketplace 和 Open VSX；desktop app 的安装包挂在 GitHub Release assets 里；CLI 则通过 npm 包 @grinev/boardown-cli 发布。
最轻量的 agent 场景是 CLI。README 给出的例子是：
npm i -g @grinev/boardown-cli
boardown --help
npx @grinev/boardown-cli release currentCLI 会从当前目录向上寻找 .boardown/，也可以用 --data-dir 指定路径。输出在 pipe 或 --json 下是稳定的 JSON envelope，这一点对 agent 很关键。一个 coding agent 不需要猜 UI 状态，只要读取 backlog、查看当前 release、移动任务或追加 notes，最终结果仍然是可审查的 Markdown 改动。
VS Code extension 和 desktop app 则解决人类读写体验。两者复用同一套 board UI，读取同一套 Markdown 文件，并会在文件变化时自动刷新。也就是说，agent 用 CLI 移动了任务，人类在 editor 或桌面 app 里能看到同一个 board 更新；人类拖动卡片，agent 后续读取的也是同一份 .boardown/。
有趣的是它把 agent 当成一等用户
很多 local-first 工具只是在 README 里顺手说一句“AI-friendly”。boardown 的设计更具体：任务文件在仓库里，agent 天然能读；CLI 以 JSON 为主要机器接口；README 明确提到 Claude Code、Cursor 这类 agent 可以读 backlog、选当前 release、移动任务，并让你在 UI 里实时看到变化。
这能解决一个常见摩擦：agent 生成计划后，计划经常只留在 chat transcript 里。下一次换 session，计划就断了。把 task board 放进 repo 后，agent 的计划和执行状态至少有了一个可持久化的位置，而且这个位置会进入 Git 历史。对需要多次运行 Codex、Claude Code 或 Cursor agent 的项目来说，这比“请记住上次的计划”可靠。
另一个细节是可审查性。agent 更新任务状态时，结果不是写到一个你没看见的远端服务，而是修改 .boardown/ 中的 Markdown。reviewer 可以在 PR 里看到 agent 是否把任务描述改偏、是否移动到了错误 release、是否遗漏 checklist。这和代码审查的工作方式一致。
v0.5.2 的维护信号
截至这次核验，GitHub 页面显示项目有 7 个 releases 和 7 个 tags，公开 git history 显示约 135 个 commits。最新 release v0.5.2 的 release note 主要提到文档引用可以在弹窗中打开，并带有 “View in docs” 入口；这不是大功能，但说明作者还在围绕日常使用细节打磨。
源码层面，根 package.json 标明项目是 MIT、ES module、Node >=20，并用 pnpm workspace 管理 packages/*。CLI 包的 package.json 明确描述为 “Command-line and agent-facing interface for boardown task boards”，bin 名称是 boardown，关键词包含 kanban、markdown、tasks、scrum、agent。这些信息和 README 的定位是一致的。
项目规模还很小，26 stars 也说明它远没有被主流采用。但对 Gumi 来说，小众不是问题；真正重要的是它是否有明确工作流价值。boardown 的价值点很具体：任务状态、agent 操作和 Git review 放在同一个表面上。
适合哪些场景
第一类是个人项目和小团队。你可能不想为了一个开源库或内部工具维护完整的项目管理系统，但又希望 release、epic、task 不只是 README 里的 todo list。boardown 给了一个介于 Markdown checklist 和云端 issue tracker 之间的形态。
第二类是经常按 branch 工作的项目。任务跟着 branch 走，reviewer 可以看到任务描述、notes 和 checklist 的变化。对需要解释“为什么改这些文件”的 PR，这种上下文很有用。
第三类是 agent-heavy workflow。如果你让 AI agent 参与规划、拆任务、更新状态，那么 CLI + JSON + Markdown diff 的组合比截图式看板更适合自动化。agent 写完代码后同步任务，或先从当前 release 里挑下一个 task，都能落在仓库里。
第四类是对外部 SaaS 敏感的环境。boardown 不需要云端账号、服务端或远程数据库，README 也强调 no cloud、no server、no account。任务数据是否进入远端，取决于你怎么 push 这个 Git 仓库。
需要注意的地方
第一，Git-native 不等于冲突自动消失。多个分支同时创建任务、移动任务或重排 release，仍然可能产生难看的 Markdown conflict。README 已经给出使用建议：feature branch 只改跟本分支相关的 task，结构调整放到 main。
第二，它不适合替代大型团队的 issue 系统。权限、跨项目报表、自动化通知、客服入口、产品路线图治理，这些不是 boardown 当前要解决的问题。它更像 repo-local planning surface。
第三，desktop app 还没有 code signing。README 明确写到 Windows SmartScreen、macOS quarantine 可能会提示，需要手动确认运行。对企业设备来说，这是 adoption 上的现实门槛。
第四，项目仍年轻。2026-05-01 创建，到现在只有几个月历史，star 和 fork 都少。可以试用，但不应把它当成已经被大规模验证的基础设施。
总结
grinev/boardown 的吸引力在于它没有把 project management 做大，而是把范围压得很窄：任务板就是仓库里的 Markdown，UI、desktop app 和 CLI 都围着同一份 .boardown/ 转。这个设计让任务状态能参与 branch、diff、review，也让 AI agent 有一个稳定的、可版本化的工作面。
如果你已经在小项目里用 Markdown 管任务，但又想要一个真正的 board UI；或者你正在让 coding agent 参与多轮开发，希望任务状态不要散落在聊天记录里，boardown 值得试一次。它不是 Jira，也不是 Linear；它更像是把项目板拉回 Git 工作流的一次小而实用的尝试。