pullboard - 让多个编码智能体按规格协作的协调队列

pullboard 是一个面向长期软件构建的智能体协调队列。按项目自述的说法，它要解决的是「智能体擅长完成任务，却不擅长推进项目」这个问题：每开一个新会话，之前定下的决策就丢了，人于是变成了智能体之间的粘合剂。pullboard 的做法是把计划、规则、任务和验证记录都放进 git 仓库，让多个智能体围绕同一份规格分工协作，而人只负责那些只有人能做的判断。它适合已经在用编码智能体做真实项目、但被反复重述上下文和人工串联拖慢节奏的开发者与小团队。

维护者与状态

项目由 pullboard-dev 维护，仓库创建于 2026-10-07，最后提交时间为 2026-10-21。最新正式版本为 v0.9.1，发布于 2026-10-19。截至 2026-10-21，仓库星标数为 246。项目另有一个官网，用于介绍其方法论与使用方式。

主要能力

以下能力均据项目 README 自述整理，未经独立验证。

• 规格即合同：需求以一行一条的形式写在 SPEC.md 中，每条带 id、状态（如 approved / draft）、优先级和对应的验证门槛（gate）。只有被批准的条目才算数，智能体认领任务时该条目的验收标准会被冻结。
• 规则文件 Doctrine：DOCTORINE.md（README 中写作 DOCTRINE.md）存放仓库的开发规则，每条规则配有执行者，从 git hook 到人工评审不等；项目自带一套标准规则，可以追加、覆盖或拒绝其中任何部分。
• 独立工作道（Lanes）：每个智能体在自己的 git worktree 中工作，任务认领是原子的，条目之间可以设置依赖等待，避免多个智能体互相踩踏。
• 提交需通过验证：提交前必须通过门槛检查，随后由另一个智能体针对该确切 commit 进行复核，通过才接受，否则带理由驳回。
• Shouts 沟通机制：智能体之间通过 Shouts 提问与引用条目、代码，协调者能自行处理的就处理，只有需要人拍板的决策才上报。
• Activity 记录：每一次认领、提交、驳回和接受都按顺序留痕，README 称「没有任何事情发生在记录之外」。
• 看板 Pullboard View：运行 pullboard view 可在单页查看本机所有项目，包括需要人处理的决策、时间线与可执行操作；提供本地 API v1 供自写脚本调用，view --export 可导出静态可回放快照。
• 蓝图（Blueprints）：据 README，0.8.29 版本引入，内置十种项目类型的规格规则与起始条目，覆盖 Web 应用、库、iOS 应用、数据管道等，可用 npx pullboard init --blueprint web-app 从蓝图建板，也可用 pullboard blueprint save 把已批准的规则存成蓝图。

使用入口

仓库地址：pullboard-dev/pullboard；官网：pullboard.dev。

据项目说明，运行需要 git 与 Node 22.13 或更新版本。全局安装并跑一遍演示：

npm i -g pullboard
pullboard tour

在空仓库或已有 git 仓库中初始化，会写入规格、规则与智能体指令，并安装 hooks 与看板：

pullboard init
git add -A && git commit -m "chore(repo): set up pullboard"

README 也给出了手动流程：先在 SPEC.md 写规格，在 pullboard.json 配置门槛与工作道，然后用 pullboard add 建条目，用 pullboard worktree 开工作道，用 pullboard next 认领、pullboard submit 提交、pullboard verify 复核。另有 pullboard resume 在重启后把智能体带回原任务，pullboard run 允许较轻量的模型无人值守地构建简单条目。

许可与限制

项目采用 MIT 许可证。据 README，运行环境要求 git 与 Node 22.13 及以上；项目强调「住在你的 git 仓库里、无需账号、无依赖、从不调用模型」，模型由使用者自己的智能体提供，README 建议把 PULLBOARD_MODEL 设为实际使用的模型。README 还提到，项目自身用这套流程开发，近三分之一的条目会被退回，说明驳回与返工是流程的常态而非异常。需要留意的是，上述能力描述、版本特性与工作流细节均来自项目自述，实际效果需结合自身仓库与智能体配置评估。