---
name: briefing-board
description: Publish reports, research, summaries and digests as beautiful mobile-friendly web pages with a private share link, instead of long chat messages or PDFs. Use when the user asks to share, publish, send or "make readable" a briefing, report, newsletter, daily/weekly digest, research summary or any long-form output with charts or images, or when output is too long to read comfortably in chat. Returns an unguessable briefingboard.app link anyone can open on a phone, foldable, tablet or desktop.
version: 1.3.1
homepage: https://briefingboard.app
required_environment_variables:
  - name: BRIEFING_BOARD_API_KEY
    prompt: Briefing Board API key (starts with bb_)
    help: Get one free at https://briefingboard.app/get-key — it arrives by email.
    required_for: publishing and deleting briefings
metadata:
  openclaw:
    primaryEnv: BRIEFING_BOARD_API_KEY
    requires:
      env:
        - BRIEFING_BOARD_API_KEY
      anyBins:
        - curl
        - python3
        - node
    emoji: "📰"
    homepage: https://briefingboard.app/docs
  hermes:
    category: productivity
    tags: [publishing, reports, sharing, mobile, briefing]
---

# Briefing Board

Turn long-form output into a full-screen, mobile-first reading page and hand the user a link.
A briefing has a **title page** (cover image, title, subtitle, summary), a **markdown body**, and
**images** shown after the body. Readers swipe left/right through it as pages: the title page, each
`#`/`##` section, then one page per image. Pages never scroll: each section shows as one or more
**cards** in large type (long sections continue on "(continued)" cards), and readers double-tap a
card for the formatted full text, including tables and code. The returned link also lets its holder swipe up/down
through every briefing published with the same key; the reader's Share button makes a link to that
one briefing only. Readers need no account; the link is the access control.

## When to use

- The user asks to publish, share, send, or "make this readable" for a report, digest or summary.
- Your answer would be longer than a few screens in chat, or includes charts/images.
- Recurring outputs (daily news digest, weekly metrics, research roundups).

Do **not** use it for secrets, credentials, or personal data the user hasn't asked you to share:
anyone with the link can read the briefing.

## Setup (once)

1. If `BRIEFING_BOARD_API_KEY` is set, skip to Publishing.
2. Otherwise ask the user for their email and request a key:
   ```bash
   curl -s -X POST https://briefingboard.app/api/v1/keys \
     -H "Content-Type: application/json" -d '{"email":"USER_EMAIL"}'
   ```
   A `202` means the key is on its way. Ask the user to copy the `bb_…` key from the email and set
   it as `BRIEFING_BOARD_API_KEY` (never paste keys into briefings or logs).

## Publishing

1. Draft the content (see [the writing guide](references/writing-guide.md)):
   - `title` (required, ≤ 200 chars) — specific, not generic ("Q3 churn fell to 2.1%", not "Report").
   - `subtitle` (≤ 300) — the angle or time frame.
   - `summary` (≤ 1024) — the 2–4 sentence takeaway; it is shown on the title page and in link previews.
   - `body` (≤ 100,000, GitHub-flavored markdown) — headings, lists, tables, quotes, code. Raw HTML is
     shown as text, and markdown images are ignored: put images in `images`.
   - Make each `##` section a good card: open with 2–4 bullets like `- **Revenue** $4.2M` (they become
     stat tiles), keep sections short and focused, and prefer short sentences and bullets to long prose.
2. Add images (optional, ≤ 20). Each needs a `caption` and a `kind`:
   - `informational` — charts, diagrams, tables, screenshots. Never cropped; readers can tap to zoom.
   - `visual` — photos and decorative art. Cropped to fill the frame.
   - Mark **one** image `"cover": true` for the title page (prefer a `visual` photo).
   - Source: `"url": "https://…"` (preferred, any size) **or** `"data": "<base64>"` (PNG/JPEG/WebP/GIF,
     ≤ 3 MB decoded). The whole request must be ≤ 4 MB, so use URLs for large images.
3. Write the JSON to a file and POST it:
   ```bash
   curl -s -X POST https://briefingboard.app/api/v1/briefings \
     -H "Authorization: Bearer $BRIEFING_BOARD_API_KEY" \
     -H "Content-Type: application/json" \
     -d @briefing.json
   ```
4. On `201`, the response is `{"id": "...", "url": "https://briefingboard.app/b/...", "createdAt": "..."}`.
   Reply to the user with the `url` and a one-line description. Keep the `id` if they may want it
   deleted later.

Minimal payload:

```json
{
  "title": "Weekly market pulse",
  "subtitle": "What moved and why",
  "summary": "Equities rose 2% on easing rates; energy lagged on a supply glut.",
  "body": "## Highlights\n\n- **S&P 500** +2.1%\n- **Brent** −3.4%",
  "images": [
    { "caption": "City skyline", "kind": "visual", "cover": true, "url": "https://example.com/skyline.jpg" },
    { "caption": "S&P 500 daily closes", "kind": "informational", "url": "https://example.com/chart.png" }
  ]
}
```

## Deleting

If the user asks to take a briefing down:

```bash
curl -s -X DELETE https://briefingboard.app/api/v1/briefings/BRIEFING_ID \
  -H "Authorization: Bearer $BRIEFING_BOARD_API_KEY"
```

`204` means deleted. `404` means it doesn't exist or was published with a different email's key.

## Errors

| Status | `error.code` | What to do |
|---|---|---|
| 400 | `validation_error` | Fix each field listed in `error.details[].path`, then retry |
| 401 | `unauthorized` | Key missing, wrong, or revoked — run Setup again |
| 413 | `payload_too_large` | Switch base64 images to `url`s or shrink them |
| 429 | `rate_limited` | Wait for `Retry-After` seconds |

Full field rules and examples: [API reference](references/api.md).
An MCP server with the same operations is at `https://briefingboard.app/api/mcp`.