vibe-kanban

Vibe Kanban

vibe-kanban 是编码看板／工作区／评审控制面技能。

当难点在于通过可视化看板、隔离的工作区、人工评审、重试和 PR 交接来协调范围明确的编码任务时，请使用此技能。

选择工作流形式前，请先阅读以下支持文档：

• references/modes-and-routing.md
• references/board-packets-and-surface-selection.md
• references/review-and-cleanup.md
• references/tracker-and-non-code-boundaries.md
• references/environment-variables.md
• references/mcp-api.md

何时使用此技能

符合以下一项或多项情况时，请使用 vibe-kanban：

• 用户需要用于编码任务的可视化看板或工作区队列。
• 工作流需要使用并行工作区／工作树，而非一个持续很久的 Agent 会话。
• 人员必须跨多个编码卡片评审差异、重试或 PR 交接。
• 操作者希望使用一个控制面来管理分支隔离、Agent 分配、评审和清理。
• 看板需要关联现有跟踪工具，但不取代其作为项目管理唯一事实来源的地位。
• 请求中提到看板、评审队列、工作树看板、编码跟踪同步、并行编码 Agent 或 vibe-kanban。

何时不使用此技能

• 先进行规划、任务拆解或签核，再使用任何编码看板 → 使用 task-planning、survey、jeo 或 plannotator
• 任务是由单个 Agent 执行的编码任务，不需要看板／评审／工作区 → 直接使用相关的编码／编排技能
• 真正的需求是浏览器评审或复用已认证的浏览器 → 使用 agentation、browser-harness 或 playwriter
• 工作主要是项目管理／运营协调，不涉及编码工作区、差异或 PR → 使用项目管理工作流技能，例如 task-planning、standup-meeting 或 sprint-retrospective
• 工作主要是营销／内容运营 → 使用 marketing-automation 或相关的 GTM／内容技能
• 工作是游戏制作规划，不涉及编码看板执行 → 使用 bmad-gds 或其他游戏制作技能

快速路由规则

如果任务需要……	使用
用于范围明确的编码任务，并支持工作树、评审、重试和 PR 交接的看板	vibe-kanban
在开始编码前评审计划或批准制品	plannotator
不需要看板／工作区控制面的单个 Agent 任务	直接使用编码／编排技能
精确评审渲染后的 UI 或复用浏览器状态	agentation / playwriter / browser-harness
非编码工作协调（项目管理、营销、游戏运营）	相应领域的工作流技能

说明

第 1 步：确认看板是否确实是所需工具

在打开看板或配置 MCP 前，先明确请求的范围。

vibe_kanban_mode:
  board_need: coding-board | tracker-sync | review-queue | compare-agents | unknown
  task_shape: single-bounded-task | several-independent-tasks | epic-needs-splitting | unknown
  review_surface: board-review | PR-review | board-then-PR | unknown
  repo_scope: one-repo | several-repos | no-repo | unknown
  agent_mix: claude | codex | gemini | opencode | mixed | unknown
  cleanup_need: low | medium | high | unknown

只有当工作流确实需要编码看板时，才选择 vibe-kanban。如果任务仍是模糊的史诗级需求，应先拆分，避免看板沦为噪音。

第 2 步：每张卡片只安排一个范围明确的编码任务

好的卡片都有一个可供评审的结果：

• 一个 API 端点
• 一组失败的测试
• 一个隔离的 UI 组件
• 两个 Agent 针对同一任务进行的一次比较

不好的卡片是“完成迁移”之类的庞大史诗级任务，或混合了非编码与编码工作的工作流。

第 3 步：选择看板数据包和评审界面

使用 references/board-packets-and-surface-selection.md，从以下选项中进行选择：

• 并行编码卡片
• Agent 比较
• 评审队列
• 跟踪工具同步

如果快速本地迭代很重要，但最终评审仍应在 GitHub 中进行，默认采用先看板，后 PR。

第 4 步：将每张卡片视为工作区契约

每张卡片都应记录：

• 明确的目标和验收检查项
• 仓库 + 基础分支
• 选定的 Agent
• 审查范围
• 清理负责人
• 如果外部看板仍是权威来源，则附上跟踪器链接

最简卡片示例：

Title: Fix signup validation regression
Goal: Restore server-side validation for missing email/phone on /signup
Acceptance: failing tests pass, new regression test added, PR ready for review
Agent: Claude Code
Review: board-then-PR

第 5 步：运行看板循环

1. 创建或完善一张范围明确的卡片
2. 为该卡片启动一个隔离的工作区
3. 检查日志和差异
4. 按照卡片契约进行审查
5. 重试、拆分、批准，或移交给 PR 审查
6. 明确清理分支、工作树和服务

第 6 步：如实进行审查和清理

使用 references/review-and-cleanup.md 进行验收。简要规则如下：

• 将输出与卡片契约进行比较，而不只是看文件是否发生了变化
• 与其让一个工作区无限期偏离目标，不如优先重试或拆分
• 不要把看板状态视为工作已完成的证明
• 有意关闭过期卡片并清理过期工作树

第 7 步：只有在有助于共享看板控制时才使用 MCP

先从 UI 或本地工作流开始。当另一个编排器需要以编程方式创建卡片、检查状态或推进工作时，再引入 MCP。

第 8 步：如实转交给其他工具

保持 vibe-kanban 的范围足够明确，确保它持续发挥作用。

• 创建或审批计划 → task-planning、survey、plannotator、jeo
• 不涉及看板/工作区循环的代码审查 → code-review
• 浏览器审查或 QA 证据 → agentation、browser-harness、playwriter
• 仅限 PM 的例行工作或路线图协调 → PM 技能
• 不涉及编码工作区的营销/内容流程协调 → marketing-automation
• 不涉及编码看板控制的游戏制作规划 → bmad-gds

高价值命令模式

# start local board on a safe port
PORT=3001 npx vibe-kanban --port 3001

# run MCP server for orchestrators
npx vibe-kanban --mcp

# inspect worktree cleanup state
git worktree list
git worktree prune

示例

示例 1：并行编码看板

• 提示词：“设置一个看板，让 Claude 和 Codex 各自处理这三个相互独立的 Bug 修复之一，并让我能在创建 PR 前审查差异。”
• 预期行为：使用 vibe-kanban，创建范围明确的卡片，保持工作区隔离，并采用“看板审查 → PR 移交”循环。

示例 2：Agent 对比

• 提示词：“让两个 Agent 针对同一个 API Bug 开展工作，以便我比较它们的差异，并决定保留哪个 PR。”
• 预期行为：使用 vibe-kanban，保留相互隔离的尝试，并明确做出审查决定。

示例 3：仅规划

• 提示词：“帮我把这次迁移拆分为几个阶段，并在编写任何代码之前获得批准。”
• 预期行为：转交给 task-planning 或 plannotator，因为此时使用看板为时过早。

示例 4：营销看板

• 提示词：“我需要一个看板，用于审批内容日历和修改发布文案。”
• 预期行为：转交给 marketing-automation 或 PM/内容工作流技能，因为 vibe-kanban 面向编码工作区、差异和 PR 移交。

示例 5：关联跟踪器的编码看板

• 提示词：“将 GitHub Projects 保留为权威来源，同时为三个使用隔离工作树的功能卡片创建编码看板，并在每张卡片完成后移交给 PR 审查。”
• 预期行为：将跟踪器保留为权威来源，使用 vibe-kanban 管理编码执行状态，并明确处理清理和 PR 移交。

最佳实践

1. 每张卡片只对应一个范围明确的编码成果。
2. 将 GitHub Projects / Linear / Jira 视为外部跟踪器，而不是不需要编码看板的证明。
3. 将进行中的卡片数量限制在一位审查者能够实际处理的范围内。
4. 在持久的地方保留重试决定和评论。
5. 在共享仓库中快速迭代时，优先采用“先看板，再 PR”的方式。
6. 将清理工作树、分支和预览服务纳入工作流。
7. 尽早将 PM、营销和非代码类游戏制作看板转交给其他工具。

参考资料

• BloopAI/vibe-kanban
• Git worktree 文档
• Claude Code 常见工作流
• GitHub Projects 文档
• GitHub 合并队列文档