Vibe Board VE
Vibe Board MCP (ve-vibe-board)
你的代理,但它拥有记忆。这是一个由 Firestore 支持的 MCP 服务器,为 Claude Code(以及任何支持 MCP 的代理)提供跨会话的持久化记忆——包括任务、进度、决策和交接笔记,这些内容在上下文压缩和会话结束时依然存在。
配套仓库:HuntsDesk/ve-kit — Vibe Coding 框架及 Claude Code 持久化记忆。ve-kit 捆绑了此 MCP 服务器、RIPER-CAT 工作流、审查门控钩子以及可选的 Docker 工作节点。
Vibe Entrepreneurs 的一部分 — 一个为所有使用 AI 进行实际工作的“氛围编码者”(vibe coders)提供的社区。欢迎加入:vibeentrepreneurs.com。
为什么存在这个工具
听起来熟悉吗?
你在重构过程中调用了六次工具。上下文被压缩了。代理回来时虽然很有“氛围”,但没有计划。
第二天开始新会话时。它重新读取相同的文件,重新问相同的问题,重新决定你已经决定过的事情。
你看着它写了一份完美的 TodoWrite 清单——然后对话结束了,清单也随之消失了。
你并行打开了三个代理。它们谁都不知道对方做了什么。
这就是无状态在实践中的感受。代理在一小时内表现出色,但之后就患上了健忘症。
Vibe Board 就是用来存储状态的地方。它是一个共享的任务+会话看板,存在于任何单一对话之外——在 Firestore 中,而不是在上下文中。
代理在规划期间创建任务——它们在会话结束后依然存在
进度在执行期间被跟踪——对下一次运行可见
会话结束时会编写交接笔记——并附带对仍处于打开状态的任务的引用
下一次会话调用
board_create_session,读取交接内容,并从上次停止的地方继续
你得到的是:一个周二出现时就知道周一在做什么的代理。无需重新解释。没有丢失的计划。没有 TodoWrite 坟场。
在 Firebase 的免费层上运行是免费的。
Related MCP server: backlog
14 个 MCP 工具
分类 | 工具 |
项目 |
|
任务 |
|
会话 |
|
活动 |
|
十四个工具,一个目标:给代理一个存放状态的地方,而不是对话本身。
安装
1. 克隆 + 构建
git clone https://github.com/HuntsDesk/ve-vibe-board.git
cd ve-vibe-board
npm install
npm run build2. 设置 Firebase
创建一个 Firebase 项目(免费层即可)。在原生模式下启用 Firestore。创建一个具有 roles/datastore.user 权限的服务账号并下载密钥 JSON。
GOOGLE_APPLICATION_CREDENTIALS 既接受密钥 JSON 的文件路径(规范做法),也接受原始 JSON 内容内联(适用于 Glama 的浏览器 MCP Inspector、CI 密钥或 Cloud Run 的内联密钥模式等沙盒环境)。
同时部署 Firestore 复合索引。仓库附带了 firestore.indexes.json,声明了所有 5 个必需的索引(sessions, tasks, projects, activity_log)。使用一条命令部署它们:
# From the ve-vibe-board repo root (contains firebase.json + firestore.indexes.json)
firebase use YOUR_PROJECT_ID
firebase deploy --only firestore:indexes需要安装 Firebase CLI (npm install -g firebase-tools),并使用在项目上具有 roles/datastore.indexAdmin 权限的账号进行身份验证。等待 1-5 分钟让索引构建完成。
gcloud firestore indexes composite create \
--project=YOUR_PROJECT_ID \
--collection-group=sessions \
--field-config field-path=project_id,order=ascending \
--field-config field-path=status,order=ascending \
--field-config field-path=ended_at,order=descending
gcloud firestore indexes composite create \
--project=YOUR_PROJECT_ID \
--collection-group=tasks \
--field-config field-path=project_id,order=ascending \
--field-config field-path=status,order=ascending
gcloud firestore indexes composite create \
--project=YOUR_PROJECT_ID \
--collection-group=tasks \
--field-config field-path=project_id,order=ascending \
--field-config field-path=assigned_agent,order=ascending \
--field-config field-path=status,order=ascending
gcloud firestore indexes composite create \
--project=YOUR_PROJECT_ID \
--collection-group=projects \
--field-config field-path=status,order=ascending \
--field-config field-path=updated_at,order=descending
gcloud firestore indexes composite create \
--project=YOUR_PROJECT_ID \
--collection-group=activity_log \
--field-config field-path=task_id,order=ascending \
--field-config field-path=created_at,order=descending3. 配置 Claude Code
添加到项目的 .mcp.json 中:
{
"mcpServers": {
"vibe-board": {
"command": "node",
"args": ["/absolute/path/to/ve-vibe-board/dist/index.js"],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "/absolute/path/to/your-key.json"
}
}
}
}在 .claude/settings.local.json 中允许这些工具:
{
"permissions": {
"allow": [
"mcp__vibe-board__board_get_projects",
"mcp__vibe-board__board_create_project",
"mcp__vibe-board__board_update_project",
"mcp__vibe-board__board_get_tasks",
"mcp__vibe-board__board_get_task",
"mcp__vibe-board__board_create_task",
"mcp__vibe-board__board_update_task",
"mcp__vibe-board__board_bulk_update_tasks",
"mcp__vibe-board__board_delete_task",
"mcp__vibe-board__board_create_session",
"mcp__vibe-board__board_end_session",
"mcp__vibe-board__board_get_handoff",
"mcp__vibe-board__board_log_activity",
"mcp__vibe-board__board_get_activity"
]
},
"enabledMcpjsonServers": ["vibe-board"]
}4. 验证
开始一个新的 Claude Code 会话并调用 board_get_projects。返回空数组即表示成功。
代理规则 (粘贴到 CLAUDE.md)
将其放入项目的 CLAUDE.md(或等效的代理指令文件)中。这是 ve-kit 框架所采用的相同协议,针对独立 MCP 安装进行了精简。MCP 服务器为代理提供了存放状态的地方——这些规则教它如何真正使用它。
## Vibe Board
Persistent task tracking across sessions via Firebase Firestore MCP tools (`board_*`).
**Mandatory for every substantive session** (any session where you read, write, plan, debug, or deploy code).
### Use Board Tasks, NOT TodoWrite
TodoWrite is ephemeral — it dies when the session ends. Board tasks persist forever and enable cross-session handoff. When you would reach for TodoWrite to track multi-step work, use `board_create_task` instead.
**Nothing exists unless it's on the board.** If an action item, future phase, recommendation, or follow-up is mentioned in conversation or discovered in a document but has no board task, it WILL be forgotten. The board is the single source of truth for "what needs to be done." Conversation text, plan docs, and strategy docs are reference material — the board is the task list. When in doubt, create the task. A redundant board task costs nothing; a forgotten action item costs real work.
### Proactive Triggers
These are condition → action pairs. When the condition is true, take the action immediately.
| Condition | Action |
|-----------|--------|
| Session starts (substantive work) | `board_create_session` before any other work |
| Context compacted / continuation session | `board_create_session` IMMEDIATELY — compaction loses the active session ID |
| Multi-step task (3+ steps) | `board_create_task` for each step |
| Batch of items (fix 5 bugs, review 3 files) | Parent task + subtask per item via `board_create_task` |
| New work discovered during execution | `board_create_task` immediately |
| Significant decision or blocker | `board_log_activity` |
| Start working on a task | `board_update_task` → `in_progress` + set `assigned_agent` to your name |
| Finish a task | `board_update_task` → `done` |
| Review/audit produces findings | Parent task per severity tier + subtask per finding |
| Deploying a new service for the first time | `board_create_task` for: verify deployment, create CI/CD trigger, push to prod |
| Committing + pushing code | `board_log_activity` with commit hash; update related tasks |
| Read a doc/plan with unbuilt phases or pending items | `board_create_task` for each actionable item not already on the board |
| Mention a future action item in conversation | `board_create_task` immediately — conversation text is ephemeral, board tasks are permanent |
| A sub-agent reports a finding or recommendation | `board_create_task` if it requires future work (don't let it exist only in conversation) |
| User says "handoff" or signals session end | Create board tasks for ALL pending next steps, THEN `board_end_session` |
| Session ending OR context getting long | `board_end_session` with handoff notes |
**The test**: If this session died right now, could the next session reconstruct what you were doing from the board alone? If not, you haven't been proactive enough.
**The second test**: If a documented plan has unchecked items, unbuilt phases, or "pending" status markers — and there's no corresponding board task — that's a gap. Every actionable item in every plan doc should have a board task. Plans without board tasks get forgotten.
### Session Lifecycle
**Starting a session** (before any other work — **including after context compaction**):
**Context compaction destroys the active session ID.** If you're continuing from a compacted conversation, you MUST call `board_create_session` before doing anything else. This is the #1 failure mode — compaction preserves your behavioral patterns but loses board state.
1. Call `board_get_projects` to see all active projects
2. **Match work to the correct project** — read project names/descriptions and pick the best fit. Do NOT default to one project for everything. Use a general catch-all project only when no specific project fits.
3. Call `board_create_session` with the matched `project_id`
- This auto-abandons any stale sessions and returns handoff context
- Read the handoff carefully — it contains what the last session accomplished and what's next
4. Review active tasks via the handoff response or `board_get_tasks`
**During a session:**
- **Planning**: Create all tasks on the board immediately with status `todo`. This ensures the plan survives even if the session crashes before execution.
- **Reviewing**: Review the *task list on the board*, not just prose. Call `board_get_tasks`, then use `board_log_activity` with `task_id` and `action: "commented"` to attach review comments to specific tasks. ALL review output MUST go through the board — conversation text disappears when sessions end.
- **Review findings → board tasks**: When a review produces findings, every finding must become a board task — not just an activity log comment. Create one parent task per severity tier (e.g., "Tier 1: BLOCKING items"), then subtasks for each finding using `parent_task_id`. Map priorities: BLOCKING/FAIL → `critical`, HIGH/WARN → `high`, LOW/INFO → `low`. Include enough context in each subtask's description to fix the issue without re-reading the review.
- **Executing**: Move tasks to `in_progress` as work begins, then `done` when complete. `started_at` is set automatically on first move to `in_progress` — work duration = `completed_at - started_at`.
- **Committing**: Log the commit hash via `board_log_activity` on related tasks. When deploying a new service for the first time, create follow-up tasks: (1) verify deployment, (2) create CI/CD trigger, (3) push to production. These are predictable follow-ups — don't wait for the user to ask.
- **Tracking your own work**: The board isn't just for project plans — it tracks what YOU are doing right now. When you receive a batch of items, create a **parent task** for the batch and **subtasks** for each item using `parent_task_id`. Move each subtask to `in_progress` → `done` as you work. This creates a recoverable checkpoint: if the session dies mid-batch, the next agent sees exactly which items are done and which remain.
- **Sub-agent delegation**: When spawning specialist sub-agents that produce detailed findings, instruct them to write results directly to the board. Include the `project_id` and parent task ID in the prompt. The sub-agent returns only a brief summary. This keeps the main agent's context lean while preserving full detail on the board. Pattern: `"Write all findings to the Vibe Board (project: PROJECT_ID, parent task: TASK_ID). Return only a 1-sentence summary to me."`
- **All modes**: Log notable events via `board_log_activity`. Create additional tasks as new work is discovered — the board should always reflect the current state of work.
**Ending a session** (before the session ends or when the user signals they're done):
1. **Scan your tasks**: Check for any tasks still `in_progress` that you own — mark them `done` if complete, or add a `board_log_activity` comment explaining what remains.
2. **Create tasks for all next steps**: Every pending follow-up must exist as a board task BEFORE ending. Do not list future work only in handoff prose — if it's worth mentioning as a next step, it's worth tracking as a task.
3. Call `board_end_session` with progress_summary, handoff_notes (referencing task IDs, not just prose), and context_artifacts.
**This is the most critical step.** A session without handoff notes is a session whose context is lost forever.
**Proactive ending**: If you sense the conversation is getting long or you are approaching context limits, call `board_end_session` immediately — even a partial handoff is infinitely better than an abandoned session with no notes.
### Task Status Flow
backlog → todo → in_progress → review → done
↓
blocked
### Priority Levels
- **critical**: Blocking other work, needs immediate attention
- **high**: Important, should be next
- **medium**: Standard priority (default)
- **low**: Nice to have, do when time allows想要更多?
以上是独立协议。如果你还需要更广泛的框架——RIPER-CAT 操作模式、用于委派多专家工作的 processor 代理、审查门控钩子、自主 Docker 工作节点——请参阅 HuntsDesk/ve-kit → docs/ve-kit/02-VIBE-BOARD.md 获取规范参考和工具包的其余部分。
许可证
MIT。请参阅 LICENSE。
相关
HuntsDesk/ve-kit— 完整的 Vibe Coding 框架,捆绑了此 MCP 服务器HuntsDesk/ve-gws— VE Google Workspace MCP (ve-* 系列的兄弟项目)
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseAqualityDmaintenanceCross-surface persistent memory for Claude. Bridges context between Claude Chat, Code, and Cowork via local SQLite with full-text search.6146MIT
- AlicenseAqualityCmaintenancePersistent, cross-session task management for Claude Code. 24 MCP tools for tasks, projects, dependencies, and docs. 7 skills for planning, standups, and handoffs. Event-sourced storage with per-project isolation.5MIT
- AlicenseAqualityCmaintenanceMost Google Workspace MCPs let you read. This one lets you write — 28 authoring tools on top of taylorwilsdon/google_workspace_mcp, including markdown-to-Docs, smart chips, and recursive Drive copy.1002MIT
- AlicenseAqualityFmaintenancePersistent memory and automatic git snapshots for Claude Code, capturing decisions, patterns, and architecture across sessions.105298MIT
Related MCP Connectors
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Hosted memory for AI agents that learns and forgets — one key across Claude, Cursor & ChatGPT.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HuntsDesk/ve-vibe-board'
If you have feedback or need assistance with the MCP directory API, please join our Discord server