featureboard-mcp

# FeatureBoard — the board Claude actually runs

**A local, markdown-backed project board that lives inside Claude** — packaged as a
Claude Desktop / Cowork extension (`.mcpb`). Point it at a folder, and Claude plans,
logs, prioritizes, and *works* tickets in plain language — then renders the whole thing
as a live, interactive board artifact with a full analytics dashboard. No SaaS, no login,
no lock-in. Your boards are plain `featurelist.md` / `buglist.md` files you own forever.

It started as a hosted web app (OpenClaw). We rebuilt it as an MCP server by taking the
original app's file list and porting it, tool by tool, **while learning MCP from scratch** —
and it came together fast. What you get is ~213 tools spanning the entire product surface:
board and churn loop, analytics, testing, a media studio, CRM, leads, contracts, mail and
marketing, a website builder with git deploys, and per-ticket commits. The board is the
front door; everything the original app did is one sentence away in chat.

## Why it's good

- **It's the board Claude drives, not a database you poke.** Ask "what's on my plate,"
  "break FBF-300 into subtasks," or "ship the next ticket" — Claude pulls work, sets status,
  writes the code, logs the diff, and commits. The board stays honest because the agent keeps
  it honest.
- **One command opens the real UI.** `get_board` returns the shipped board as a Cowork
  artifact — Todo / In Progress / Done columns, filters, dark mode, click-to-move, and a 📊
  analytics dashboard (velocity, timeline, bug health, work-log feed) — all wired live to the
  server. No hand-rolled mockups.
- **Your files, your rules.** Boards are byte-compatible markdown. Existing FeatureBoard
  folders work with zero migration. Writes are atomic. Delete the extension tomorrow and your
  boards are still just markdown.
- **Depth when you want it.** The same server that tracks tickets also generates media, runs a
  CRM, drafts contracts and campaigns, builds and deploys a marketing site, and commits your
  code per ticket. Turn it down to the essentials with one toggle, or open the whole toolbox.

## Measured: what the board actually buys you

A paired agent trial (n=10, sonnet model tier) showed the work packet cuts diff churn **1.76x**
(837 vs 1,471 additions) with equal correctness (10/10 both). Token spend is 6–11% lower
(77.5k vs 83.2k median), secondary to the focus gain: less to review, maintain, and scope
drift on open-ended asks. See [docs/EVAL-BOARD-VS-CHAT.md](docs/EVAL-BOARD-VS-CHAT.md).

## Quickstart

1. Install the extension: double-click `featureboard-0.7.1.mcpb`, or Claude Desktop →
   **Settings → Extensions → Advanced → Install Extension**.
2. On first run it asks for your **Boards folder**. Each subfolder with a `featurelist.md` or
   `buglist.md` is a board.
3. Say **"open the FeatureBoard board"** — the live board opens as an artifact. Then just talk:
   - "Log a bug: gallery modal won't dismiss on mouse-out."
   - "Brainstorm five onboarding features and add them."
   - "Move FBF-207 to done — fixed the parser regex."
   - "How's velocity looking this week?"

> **First-run tip:** the extension defaults to **Essential tools only** (~34 core board tools)
> for a clean start. Turn that off in the extension settings to expose the full ~213-tool
> surface (CRM, media, website, marketing, and more). After installing or updating, fully
> **restart Claude Desktop** so new tools load.

> **Not using Claude?** Cursor, Grok Build, and any other MCP client can run the same server
> over stdio — see [docs/INSTALL-OTHER-IDES.md](docs/INSTALL-OTHER-IDES.md) for per-IDE config,
> tool-count limits, and the IDE-neutral instructions flag.


## Recipes

Automate your board's daily routines without a daemon. Copy-paste these prompts into **Claude Code → Scheduled tasks** to run nightly board health checks, weekly sprint close-outs, and daily standups. See [docs/RECIPES.md](docs/RECIPES.md) for three ready-to-use scheduled task recipes and tool reference.
## Everything it can do

**Board & tickets** — `list_projects` · `create_project` · `list_tasks` · `get_task` ·
`add_feature` · `log_bug` · `add_features_bulk` · `import_tasks` · `validate_feedback` ·
`plan_work` · `update_task` · `set_status` · `decompose_feature` · `link_tasks` ·
`add_attachment` · `remove_attachment` · `delete_task` · `add_product` · `remove_product` ·
`get_project_config` · `set_project_config` · `get_ticket_history`

**The live board** — `get_board` (returns `artifact/board.html`, ready to render as a Cowork
artifact — this is what "open/show the board" calls)

**Churn loop & orchestration** — `next_task` · `get_work_packet` · `log_work` ·
`get_agent_monitor` · `get_scratchpad` · `set_scratchpad` · `append_scratchpad`
(pull one ticket, assemble a focused brief, dispatch to a sub-agent, record the diff, repeat.
`get_agent_monitor` is the live view of what's In Progress right now: elapsed time since each
ticket started, its last event with age, token spend vs its `cap:<tokens>` label, and a stalled
flag — an inactivity threshold, 30min by default. Stalled tickets also surface as a warning banner
on the board, useful for keeping an eye on an unattended churn run. It also reports `costSoFar`/
`capCost` in dollars — see cost tracking below.)

**Knowledge base** — `add_kb_doc` · `list_kb_docs` · `get_kb_doc` · `search_kb` (a per-project
kb/ folder of markdown docs, beyond the scratchpad — keyword-matched into `get_work_packet`'s
`kbMatches` automatically). `rag_search` is the retrieval layer over kb + repo
docs + Done-ticket summaries: BM25 always, and HYBRID (BM25 + local MiniLM embeddings via the
optional `@xenova/transformers` dep, reciprocal-rank fusion) when installed — the ~25MB model
downloads once on first use then runs offline forever; without it, pure lexical, zero network.

**Audit timeline** — `get_ticket_history` (per-ticket chronological log: `set_status`/
`update_task`/`assign_sprint` append status, priority, label, sprint, and due-date change events
to `ticket_events.jsonl`; `get_ticket_history` merges those with the ticket's work-log entries
into one view. Tickets from before this existed just show their work-log history. The board's 🕘
button on each card renders the same timeline.)

**Code review** — `get_ticket_diff` captures the code a ticket produced (finds commits mentioning
the ticket id in the project's code repo and returns per-commit summaries plus size-capped unified
diffs from `git show`). `add_review_comment` leaves PR-style feedback on a ticket (optionally
anchored to a file/line); `list_review_comments` and `resolve_review_comment` manage it. Unresolved
comments surface in the ticket's next work packet (`get_work_packet.reviewComments`) so the next
agent acts on the feedback, and a comment on a ticket in **Review** sends it back into `next_task`'s
queue — otherwise tickets awaiting review are held out of `next_task` (they belong to the reviewer).
The board's 🕘 ticket panel lists review comments with their resolved state.

**Analytics & health** — `get_metrics` · `get_health` · `get_work_log` · `predict_due_dates`
(`get_metrics`'s velocity section rolls up `$` cost by model too, alongside tokens. Cost tracking
is model-aware: `server/pricing.js` ships defaults sourced from current Anthropic API pricing —
input/output $/MTok per model tier (fable/opus/sonnet/haiku) — and every rate is overridable per
project via `set_project_config`'s `pricing` key, so a stale default is harmless. Work-log entries
with an `inputTokens`/`outputTokens` split are priced exactly; older entries with only a `tokens`
total fall back to a blended rate. `get_agent_monitor` and `eval_report` roll up the same $ figures
per ticket/arm, and the board's metrics panel shows a cost line with a per-model breakdown.)

**Timeline (piano roll)** — `get_timeline_data` (FBMCPF-158). The board's 🎹 Timeline panel is an Ableton-style piano roll: every ticket is a clip on a horizontal lane, spanning its worked window (created → In Progress → completed, from `ticket_events.jsonl` with a completion-day fallback). Lanes group by product / model / type / sprint / status; a sticky time ruler adapts its granularity (hour / day / week / sprint); wheel zooms centred on the pointer, shift+wheel or grab-drag pans. A single datastream overlay (tokens / cost / additions+deletions) draws as a strip under the ruler. Hover a clip for a compact card (title, status, model, tokens); click to pin an expanded card that lazily pulls `get_ticket_history` for selectable cost / status-history / work-log fields.

**Sprint close-out reports** — `close_sprint` · `get_sprint_report` (FBMCPF-156)
(close a sprint and turn its tickets + work log + metrics into four audience-specific reports —
**marketing** (features shipped, positioning-ready copy), **sales** (customer-facing capabilities +
the CRM tickets they resolve), **technical** (per-ticket changes, commits, ADRs touched), and
**executive** (velocity, spend vs budget, health, risks). `close_sprint` refuses to close while a
sprint still has open tickets unless `force:true` (open ones are then reported as carryover), writes
deterministic `reports/<sprint>/<audience>.md` pads under the project (byte-stable, no model calls),
and also returns a per-audience LLM prompt — the report packet as JSON plus an audience brief — so an
agent can draft richer copy while staying grounded in real data. When the project has Slack
configured it posts a one-block summary on close (a Slack failure is reported, never fails the close).
`get_sprint_report` reads them back: no sprint → list sprints with reports; a sprint → its manifest
and which audiences exist; sprint + audience → that report's markdown. The board's 📄 Reports panel
lists every sprint with reports and renders each audience in its own tab.)

**Board hygiene** — `scan_board_cleanup` · `prune_board` (also lints open tickets missing a `model:`/`cap:` label — see intake orchestration guard below)

**