diff --git a/plugins/brains/.claude-plugin/plugin.json b/plugins/brains/.claude-plugin/plugin.json
index a3ef14d..031fcbd 100644
--- a/plugins/brains/.claude-plugin/plugin.json
+++ b/plugins/brains/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "brains",
   "description": "Your memory layer: Gmail, Calendar, Drive, and prior Claude conversations as queryable pages, with reflexive recall, hook-driven turn-by-turn capture and inbox delivery, and boards/automations/workflows on top.",
-  "version": "2.7.1",
+  "version": "2.8.0",
   "author": {
     "name": "brains (ssvlabs)"
   },
diff --git a/plugins/brains/.codex-plugin/plugin.json b/plugins/brains/.codex-plugin/plugin.json
index fe6dfdf..9096243 100644
--- a/plugins/brains/.codex-plugin/plugin.json
+++ b/plugins/brains/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "brains",
-  "version": "2.7.1",
+  "version": "2.8.0",
   "description": "Your personal memory layer for Codex: query Gmail, Calendar, Drive, and prior conversations, then build boards, automations, and workflows.",
   "author": {
     "name": "brains (ssvlabs)",
diff --git a/plugins/brains/generated/capability-catalog.json b/plugins/brains/generated/capability-catalog.json
index fc9f966..4171ad4 100644
--- a/plugins/brains/generated/capability-catalog.json
+++ b/plugins/brains/generated/capability-catalog.json
@@ -7,16 +7,34 @@
   "artifacts": [
     {
       "capability_id": "integration-actions",
-      "catalog_sha256": "c46b9cf2f88ed3cefe0f5766665c12f06dafaa0e56dba1f5586ab9cd56c39ac2",
+      "catalog_sha256": "29f58ddc5dab294814934fe7af0d808f4b7dc441e3c3d29bb0e67fa705d7add4",
       "artifact_path": "plugins/brains/skills/brains-write/SKILL.md",
-      "artifact_sha256": "f14839e4ed852771fc8dd91b0196f9caeeb63ce56dead747a53d83fd83dd9475"
+      "artifact_sha256": "b27acd2ffc1ba4914890a88dba00e71f7052bd738369f28f9d86a1566bd2f548"
     },
     {
       "capability_id": "brains-features",
-      "catalog_sha256": "03c153311f597a651c9719dc17229e6677b4c2b2823458b0b50c12617146a5bd",
+      "catalog_sha256": "6086cbe9877b2005b3cea06611ba74ab7b527eaed04af39e5a815c94c8806b37",
       "artifact_path": "plugins/brains/skills/brains-build/SKILL.md",
-      "artifact_sha256": "8e377f866efdbf6653cda64fcc44cef6a8038e1d74dfd2311af4a0ded434c237"
+      "artifact_sha256": "753afa4d8b4833b91622fa8c55d2bc76304e9a9170faed3365c7febd53836ae0"
+    },
+    {
+      "capability_id": "procedure:board",
+      "catalog_sha256": "d9242158554683b1b18ac2f26ebfecf6c0d42c00e480524be2e6ee35df1fb879",
+      "artifact_path": "plugins/brains/skills/brains-board/SKILL.md",
+      "artifact_sha256": "bfc28da5ef20ec559fe10bd9b21d2d7ca673de5533f012bd9cfaa3947241cf6f"
+    },
+    {
+      "capability_id": "procedure:automation",
+      "catalog_sha256": "ea1e883788e138e39b80627e5a14d6ac35dc7f658b4628e7e32084bb6620fe8b",
+      "artifact_path": "plugins/brains/skills/brains-automation/SKILL.md",
+      "artifact_sha256": "e71b5648d93e611de49fd81549217db8232427262e282af6d1c1d70c9c2e17c9"
+    },
+    {
+      "capability_id": "procedure:workflow",
+      "catalog_sha256": "ec1f5989adae2630f16879299f05cc79c6aabfd9897c968c69618882b35f1278",
+      "artifact_path": "plugins/brains/skills/brains-workflow/SKILL.md",
+      "artifact_sha256": "b22814fd630ed78964d54440ec327e3aebcde8c812aaa9985fff9c4d345d3f09"
     }
   ],
-  "source_commit": "9888bc944d0a3e5d2c178eaaf8b23811364457d9"
+  "source_commit": "864c45fa7e1c4b4d60116b6697abc596a272fbff"
 }
diff --git a/plugins/brains/skills/brains-automation/SKILL.md b/plugins/brains/skills/brains-automation/SKILL.md
new file mode 100644
index 0000000..c536dbf
--- /dev/null
+++ b/plugins/brains/skills/brains-automation/SKILL.md
@@ -0,0 +1,623 @@
+---
+name: "brains-automation"
+description: "Scaffold a new sandboxed agent — a script on a trigger with scoped grants, caps and a smoke test. Use when the user wants something to happen without them: \"automate this\", \"every morning do…\", \"run this nightly\", \"auto-draft when…\", \"when an email from X arrives…\". Not for editing an agent they already own."
+---
+
+<!-- Generated by ssvlabs/brains apps/mcp/scripts/generate-capability-catalog.ts.
+     Source: the authoring procedure catalog. Do not hand-edit. -->
+
+# Create-agent flow — run this with the user
+
+You're guiding the user through scaffolding a sandboxed agent: a Deno-runtime user-authored script that fires on a trigger, gets a scoped MCP token, and runs in the background. Your job is to translate the user's "I want X to happen automatically" into a clean source + trigger + grants + caps without making them think about runtime details — and to bake in the patterns (idempotency, error handling, page-type guards) that hand-written agents forget.
+
+## Flow state — one line, every turn
+
+End EVERY message in this flow with a checkpoint (last line, above any chips), so a later turn
+can pick up where you left off:
+
+`FLOW automation · step 1/13 purpose · done: (none) · facts: (none) · next: the user's answer to the question above`
+
+Steps in order: `purpose`, `trigger`, `reads`, `writes`, `conflict_check`, `grants`, `egress_check`, `secrets`, `caps`, `confirm`, `save`, `smoke_test`, `handoff`. Write `(none)` in a segment that has nothing yet.
+When the flow is finished emit `FLOW automation · done` instead, or
+`FLOW automation · cancelled` if the user drops it — without that,
+the flow looks live forever.
+
+`done:` records what you have already CREATED, with the id the call returned — `automation_id=…`. Write it there the moment the call comes back. It is the only record that survives: a confirmation means the user said yes, not that the write happened.
+
+`facts:` carries the decisions you cannot re-read from the conversation — `trigger`, `dedupe_key`, `hosts_approved`, `idem`. Keep each one short.
+
+**Picking up a flow already in progress:**
+
+1. **Before creating anything, check whether you already did.** If the last checkpoint names an
+   effect for the step you are about to run, that artifact exists — look it up by its id, tell the
+   user, and continue from the next step. Never create a second one.
+2. Checkpoint present and readable → carry on from the step it names.
+3. Checkpoint garbled → re-emit a corrected one from what you can see, then carry on.
+4. No checkpoint but you still have this procedure → work out where you are from the
+   conversation, say in one line where you are resuming, and confirm before any write.
+5. No checkpoint and no procedure → do not improvise the steps; the gates in here are not
+   optional. The one exception: if the user asks to pick a flow back up and you no longer have its procedure in front of you, reload it once — then continue from the last checkpoint rather than starting over. Never re-fetch one you can still see.
+6. Nothing recoverable → start over, but collect everything in ONE question instead of walking
+   the whole interview again.
+
+## Hard rules
+
+- **Do not re-call `create_automation_flow` in this conversation.** Once you have this playbook in context, refer to the copy you already have — re-fetching it wastes tokens, resets your state in the user's eyes, and produces a worse experience. The flow is one playbook per session, not one per step. The one exception: if the user asks to pick a flow back up and you no longer have its procedure in front of you, reload it once — then continue from the last checkpoint rather than starting over. Never re-fetch one you can still see.
+- **One question per turn.** Never ask multiple questions in a single message.
+- **Propose, don't interrogate.** After Steps 1–4 you draft the full source from a template (see Skeletons below) and show it for review. Don't ask "what tool grants?" or "how should it dedupe?" — that's your job once you know the trigger and write target.
+- **The dedupe-key question is mandatory at Step 4.** If the agent appends to a shared collection (`board.updates`, page timeline, etc.) you MUST ask for or infer the dedupe key (`postId` = page slug for emails, `event_id` for calendar events, etc.) and the skeleton MUST include a "skip if already present" check. Do not draft source without it.
+- **`http_fetch` is a high-risk grant; explicit user approval is mandatory at Step 5.5.** Granting `http_fetch` lets the agent send any data the script reads from the brain (emails, board rows, calendar, search results) to any host on the runtime allowlist. The Deno sandbox does NOT block exfiltration — the egress happens from the MCP server in the stage VPC, not from the sandbox, so the host allowlist is the only gate. If `http_fetch` ends up in the proposed grants, you MUST run Step 5.5 verbatim and wait for an explicit "yes" before `save_automation_draft`. Do not soften the wording, do not batch it with other approvals, do not skip it because the hosts "look fine" to you.
+- **Never ask the user to paste a secret value into the conversation.** If the source references `{{secret_name}}`, run Step 5.7: names in chat, values in the vault. A missing value never blocks the flow — save + smoke test proceed and fail cleanly until the user stores it.
+- **Use the same MCP namespace that returned this playbook.** If you called this as `mcp__brains__create_automation_flow`, every downstream call (`save_automation_draft`, `get_board`, `search`, etc.) uses `mcp__brains__*`. If you called it under a different namespace, use that one throughout. **Don't mix namespaces.**
+- **Narrate one short line between steps** so the user knows what just happened and what's next.
+
+## The sandbox authoring contract — read this BEFORE drafting source
+
+This is the **complete** surface a sandboxed automation can call. Do NOT guess at it, do NOT probe by trial-and-error, and do NOT assume a capability is missing because you can't see it — it's all listed here. Inside the script, everything hangs off the injected `brains` global (Style A) or `ctx.brains` (Style B).
+
+**Reads (brain pages & boards):**
+- `brains.search({text, type?, limit?})`, `brains.query({text, type?, limit?})`, `brains.discover({text, limit?})` (semantic board/mini-site hits), `brains.discoverRows({text, limit?})` (semantic board-ROW hits), `brains.list_pages({type?, since?, until?, limit?})`, `brains.get_page(slug)` (returns `{...page, markdown, body}`), `brains.list_calendar_events({start, end, limit?})`. **`discover` and `discoverRows` both call the `query` tool — they need the `query` grant, not `search`.**
+- Boards: `brains.boards.get(id, {dataset, offset, limit})` (rows are `[]` unless you pass `dataset`), `brains.boards.list()`, `brains.boards.append(id, rows)`, `brains.boards.update_row(id, row_id, patch)` (**patch ONLY the fields you are changing** — see gotchas), `brains.boards.delete(id, row_id)` (SOFT delete — the row keeps its id and is undoable), `brains.boards.restore(id, row_id)`, `brains.boards.list_skills(id)`, `brains.boards.run_skill(id, name, inputs)`. Flat aliases exist (`brains.get_board`, `brains.append_board_rows`, `brains.update_board_row`, …).
+
+**Integrations — there are TWO distinct paths. Pick by integration class (confirm with `list_integrations`, see below):**
+
+| Integration class | Reachable HOW from the sandbox | Grant to add |
+|---|---|---|
+| **gmail / calendar / drive** (and other codex installs with declared actions) | **Writes:** `brains.act({install_id, action_name, input})` — resolve the action first, pass all 3 fields together, and follow the generated action contract below. **Reads/refresh:** `brains.fetch({source, input})` (a.k.a. `fetch_from_integration`). | `act_on_integration` and/or `fetch_from_integration` |
+| **adapter integrations — github, monday, …** | `brains.call("adapter_query", {kind, op, ref?, params?})` — ad-hoc mode against the user's stored OAuth token. E.g. `brains.call("adapter_query", {kind:"github", op:"list_open_prs", ref:{owner:"ssvlabs", name:"brains"}})` or `{kind:"monday", op:"list_boards"}`. There is **no** `brains.adapter_query()` helper — go through `brains.call`. These are NOT reachable via `act_on_integration` or `fetch_from_integration`. | `adapter_query` |
+| **telegram** | `brains.telegram_push({text})` — delivers immediately, no draft. | `telegram_push` |
+| **write a memory page** | `brains.create_page({slug, title, body})` — idempotent on (brain_id, slug); overwrites on re-run. Use type `'derived'` or any custom label (reserved types like `email` are rejected). | `create_page` |
+
+**Other sandbox capabilities:**
+- **Per-automation K/V** (cursors, watermarks, last-seen ids): `brains.kv.get(k)` / `set(k,v)` / `list()` / `delete(k)`. **No grant needed** — it's auto-scoped to this automation.
+- **Secrets vault:** reference `{{secret_name}}` inside `http` `url`/`headers`/`query` values — the MCP server substitutes the decrypted value before egress. `brains.call("automation_secret_list")` reads the key names (never values). Grant `automation_secret_list` to enumerate keys; the substitution itself rides on the `http_fetch` grant. Keys are set out-of-band, and the sandbox cannot write secrets, only reference them. During authoring you work with secret NAMES only — **never solicit the value in chat**; run Step 5.7 for the name-confirm / existence-check / missing-value handling.
+- **LLM from the sandbox:** `brains.llm({...})` (grant `automation_complete`). **If you feed it bytes fetched from outside brains** (`brains.http`, a third-party API), wrap them first with `brains.wrapUntrusted(text)` / `brains.untrustedClause()` — the prompt-injection guard. Any flow that grants both `http_fetch` and `automation_complete` must do this.
+- **Owner identity / timezone:** `brains.whoami()` (grant `whoami`) — the supported way to get the owner's tz, which you need whenever a cron is expressed in local time. `brains.user` / `brains.profile` are injected directly (no grant, no call).
+- **Self-diagnosis:** `brains.automation_recent_failures({limit?})` (grant `automation_recent_failures`) — this automation's recent failed runs.
+- **Outbound HTTP:** `brains.http({url, method?, headers?, query?, timeout_ms?})` (grant `http_fetch` — see Step 5.5; egress is host-pinned). **Request body — name the field explicitly, never leave it implied:** `body_json` (any JSON value; sends it as JSON and sets Content-Type for you), `body_text` (a string, sent verbatim — set your own Content-Type), or `body` (fetch-style alias: a string goes verbatim, anything else is serialized as JSON). Precedence is `body_json`, then `body_text`, then `body`. **Binary must be base64-encoded into a string first** — a `Uint8Array`/`Blob`/`FormData`/`URLSearchParams` cannot cross to the server and is rejected. `GET`/`DELETE` never send a body. Note `{{secret}}` substitution does **not** apply to the body (url/headers/query only), so a body cannot reference the vault. Max request body 200 KB.
+- **Escape hatch:** `brains.call("<any_mcp_tool>", {...})` invokes any granted MCP tool by bare name. This is how `adapter_query` (and any tool with no dedicated helper) is reached. It is **still grant-gated** — the bare tool name must be in `tool_grants`.
+
+**Grant rule (load-bearing):** every tool the source calls must be listed in `tool_grants` by its **bare MCP tool name** (`get_page`, `adapter_query`, `act_on_integration`, …). A missing grant fails at runtime with `tool "X" not in automation grants`. The **only** exception is the `automation_state_*` family (no grant required). Reaching a tool through `brains.call(...)` does **not** bypass the allowlist.
+
+**Bad grants are refused at SAVE time, not at runtime.** `save_automation_draft` / `update_automation` reject the whole call if a grant is an unknown tool name (typo), is bot-only, requires admin, or requires a human-only account capability — the error names the offending grant. So a typo'd grant costs you a rejected save, not a mysterious failed run. Note `get_insights` is admin-only and `get_perf_insights` requires a human performance entitlement; neither can **ever** be granted to an automation.
+
+## Step 1 — Purpose
+
+If a non-empty `purpose_hint` was passed in, skip the cold-ask and confirm it back: *"So you want an agent that <restates hint> — got it."* Then go to Step 2.
+
+Otherwise ask, verbatim:
+
+> "What should this agent do? One sentence — e.g. *'log every email from a CRM lead onto their company in the Ethera CRM'*, *'every weekday at 9am summarize my unread emails'*, *'when a candidate row's status changes to offer, draft an offer email'*."
+
+Wait for the answer.
+
+## Step 2 — Trigger
+
+Pick exactly one. Ask, verbatim:
+
+> "When should this fire?
+> - **On every new <something>** — email arriving, calendar event ingested, doc landing in Drive, a new chat session ending. (`page_ingested`, with a type filter)
+> - **On a schedule** — every 15 min / hourly / daily at <time> / weekly on Mondays. (`cron`)
+> - **When a board changes** — rows added or edited on a specific board. (`board_change`)
+>
+> Which one? If schedule, give the cadence; if page-ingested, tell me which page types (email / calendar_event / gdrive_file / chat_session); if board_change, tell me which board."
+
+Wait for the answer. Save: `triggerKind`, plus the relevant filter (`types` for page_ingested, `cron` + `tz` for cron, `board_id` for board_change).
+
+## Step 3 — Reads
+
+Ask, verbatim:
+
+> "What does the agent need to look up before it acts? Common patterns: a board's rows (e.g. CRM leads), the full page body of the triggering email, recent calendar events for context. Anything in particular for yours, or just the trigger payload?"
+
+Wait. From the answer derive which read tools the source will call: `get_board` (paginate over `{dataset, offset, limit}` if the board is large), `get_page`, `search`, `query`, `list_calendar_events`, etc. You'll bake these into the skeleton.
+
+**If the read involves an integration** (e.g. "open GitHub PRs", "this Monday board's items", "refresh my Gmail first"), pick the path from **the sandbox authoring contract above** — don't guess:
+- gmail / calendar / drive data the cron hasn't ingested yet → `brains.fetch({source, input})`.
+- **github / monday and other adapter integrations** → `brains.call("adapter_query", {kind, op, ref?})` (ad-hoc mode). These are NOT reachable via `act_on_integration`/`fetch_from_integration`.
+- **When unsure which integrations the user has connected and how each is reachable, call `list_integrations` and read the `supports {fetch, act, adapter}` flags** — `adapter:true` means use `adapter_query`; `fetch`/`act` mean `fetch_from_integration`/`act_on_integration`. Read capabilities; do not probe by trial-and-error.
+- **If this agent requires an integration the user has NOT connected, surface the connect affordance FIRST — don't scaffold an agent that will fail at runtime for missing auth.** The surface renders its own connect UI (a chat client shows an integration-connect card/bar; plain text gives the connect link). Note that connecting the integration is separate from the `http_fetch` grant below — an adapter/OAuth integration must be connected by the user, not just granted.
+
+## Step 4 — Writes (and dedupe)
+
+Ask, verbatim:
+
+> "Where does it write? Common shapes:
+> - **Append to a board's `updates` log on a row** — *(this is the duplicate-prone case — see follow-up)*
+> - **Patch a board row** (e.g. set `status` = closed, fill in an empty `email` field)
+> - **Create a new board row**
+> - **Retire a board row** (e.g. drop a lead that went cold) — this is a SOFT delete: the row keeps its id and can be restored
+> - **Send an email / calendar invite via `act_on_integration`, or a Telegram nudge via `telegram_push`**
+> - **Nothing** — read-only summary written to stdout for the run log
+>
+> Which fits yours?"
+
+Wait for the answer.
+
+**If the user picks any of the first three** (anything that touches a shared board), follow up immediately:
+
+> "What's the natural unique id for one event of this kind? For an email, that's the page slug (`postId`). For a calendar event, the event_id. The skeleton uses this to skip rows we already logged so the same email doesn't appear twice — including across teammates running similar agents or replays."
+
+Wait. Save `dedupeField` (e.g. `updates`) and `dedupeKey` (e.g. `postId`).
+
+**If they say "I don't know"**, propose: *"For emails I'd use the page slug as `postId`. Can do that?"* and confirm.
+
+**If the write target is `act_on_integration`, use this generated contract:**
+
+Discover with `query type=integration_action text="<intent>"`.
+It returns slug/title/snippet, so call `get_page` on the selected
+slug to read frontmatter. Use its `install_id`, `action_name`, and structured
+`input` in `brains.act`; this tuple is the only call
+shape. Partial tuples error; only bare legacy `source` returns `clarification`.
+`requires_confirmation:true` drafts for out-of-band approval;
+`requires_confirmation:false` runs inline. If
+`requires_confirmation` is absent, the page predates the field: treat whether
+it drafts or runs as unknown. `side_effect` says where it writes
+(`external` = the provider, visible outside brains;
+`null` or absent = undeclared, treat as external). Inline external writes
+include `rsvp_event`,
+`create_draft`, and `add_labels`; do not infer safety from read vs write.
+Cap: 30 auto-executions/install/60s.
+Automation `dry_run` suppresses external writes to no-call `[DRY RUN]` drafts.
+
+| `kind` | What happened | What you do |
+|---|---|---|
+| `draft` | Nothing sent; it carries `preview`, `confirm_hint`, and `expires_at`. | Relay the preview and hint, then stop; only `draft` carries `confirm_hint`. |
+| `auto_executed` | It already ran; it carries `result` and `action_record_id`. | Report what happened, past tense; never say it is awaiting approval. |
+| `auto_failed` | It was attempted; whether an outbound write reached the provider is **unknown**. | Don't blind-retry. Read provider state or `/inbox` before re-sending; retry only when the action is idempotent or the error proves nothing was sent. A pure read is safe to retry. |
+| `rate_limited` | Nothing ran and no upstream call occurred. | Retry after `retry_after_seconds`. |
+| `clarification` | A `source`-only legacy call reached the shim; no action ran. | Answer its `question`, then resend the full tuple. |
+| `noop` | The integration is unavailable, or the action was suppressed because an automation is running in verify mode. | Relay its `reason`. If it starts with `verify_mode:`, report that the action was safely suppressed; otherwise point to `/integrations`. |
+
+You can't confirm a draft from this loop. Only the user's out-of-band
+`/inbox` or Telegram surface has the confirmation secret. So never call `confirm_action` yourself.
+After one hour a draft moves to the `/inbox` Expired tab but remains
+approvable. There is no edit-at-confirm step: call
+`discard_action` before re-drafting corrected input.
+
+Automation tokens cannot self-confirm. A confirmation-required action therefore waits for the human at `/inbox`, but a `requires_confirmation:false` action still executes inline for any caller granted `act_on_integration`. Get explicit agreement before saving an automation that performs an unattended external write. New automations default to `write_policy:'always_draft'`; only `update_automation` can switch to `auto_confirm_safe`, and that policy does not override an action whose recipe already auto-executes.
+
+**For "notify me" / "ping me" / "DM me" asks**, default to `telegram_push` when the user has Telegram connected — it's the user's primary notification surface. Reach for `act_on_integration` only when the notification belongs in a specific channel (email thread, calendar invite, Drive doc). `telegram_push` bypasses the draft/confirm step and sends immediately, so the user must have opted in by connecting the bot.
+
+Before adding `telegram_push` to the plan, **verify the user has a Telegram bot set up**. Call `list_integrations` and check the row where `name === "telegram"`. If `connected` is false (or no such row exists), stop here and tell the user verbatim:
+
+> *"You don't have a Telegram bot wired up yet. Go to `/integrations/telegram`, register one with @BotFather, paste the token, then DM the claim code your new bot shows in the dashboard. Once that's done, come back and I'll finish this agent."*
+
+Do NOT proceed past this point until the user confirms the bot is set up. **Never ask the user to paste a Telegram bot token as a secret** — the integration owns the token, the agent runtime never sees it. If the LLM is about to suggest `automation_secret_set` with a Telegram-shaped key, stop and use `telegram_push` instead.
+
+## Step 4.5 — Conflict check (mandatory if writing to a board)
+
+Before drafting source, call **`find_overlapping_automations`** with the board ids the user just chose plus `dedupe_target_field` (e.g. `"updates"`) and `trigger_kind`. The tool returns every existing agent across all users whose `writes_to_boards` overlap.
+
+**If `count === 0`**, narrate one short line and continue:
+> *"Nothing else writes to that board — clear runway."*
+Then go to Step 5.
+
+**If `count > 0`**, you are NOT free to draft a source that blindly mirrors an existing agent. Walk through the matches and present a diff-shaped summary, owner-scoped:
+
+> *"Heads-up — found N agent(s) already pointed at this board:*
+> - **`<owner_email>` / `<name>`** *(`<state>`, last fired <relative time>) — fires on `<trigger_kinds.join(",")>:[ `<trigger_types.join(",")>` ]`, appends to `<dedupe_target_field>` deduped on `<dedupe_key_field || "(no dedupe key)">`*"*
+
+Then **diff your proposed agent against each existing one** and surface concrete mitigations the user can pick:
+
+| What overlaps | Mitigation to bake into THIS agent |
+|---|---|
+| Same trigger kind + types + same write field, your dedupe key matches theirs (e.g. both `postId` = page slug) | **Note for the user:** your run will dedupe against theirs *only* when both runs see the same upstream id. For Gmail, `page.slug` is per-mailbox — same email in two inboxes has two slugs and dedupe DOES NOT cross-converge. Either narrow your trigger so your inbox is disjoint from theirs, or add a stronger key (e.g. `frontmatter.from + frontmatter.received_at`) to the entry and dedupe on that. |
+| Same trigger + write field, dedupe keys differ | **Strong recommendation:** match their `dedupe_key_field` so at least within the same mailbox/replay, runs converge. Otherwise your entries and theirs never collide. |
+| Same trigger + same board but different write field | **Lowest risk.** Different fields don't collide. Note this to the user; no source change needed. |
+| Trigger overlaps but you can scope yours down | **Suggest:** narrow your `page_ingested` types or filter to a brain the existing agent can't see. Bake the filter into Step 2's trigger config. |
+| Their agent is a strict superset of what you'd build (same trigger, same field, broader scope) | **Recommend skipping**: *"`<owner>`'s agent already covers this. Want me to skip creating yours and instead share the board with you (or have them broaden their grants) so you see their output?"* |
+
+Then ask the user verbatim:
+
+> *"Pick one: (a) carry on as-is — risks duplicates, (b) apply mitigation X — I'll bake it into the source, (c) skip creating this — `<owner>`'s already covers it."*
+
+Wait for the answer.
+
+**If the user picks (a) carry-on or (b) apply mitigation X**, you MUST capture a one-sentence `coexistence_note` from their reasoning — this becomes a required argument at Step 8 (the server hard-rejects coexistence saves without it). Phrase it from their words, e.g.:
+
+- *"Shared mailbox X is invisible to alon's inbox; emails arriving there need their own logger."*
+- *"Different write field (`updates_eylon`) so entries don't collide with alon's `updates`."*
+- *"Dedupe key swapped from `page.slug` to `(from + received_at)` so cross-mailbox runs converge."*
+
+If the user gave only vague approval ("yeah just save it"), ask once more — verbatim:
+
+> *"Quick one-liner — what makes your version different from `<owner>`'s? E.g. 'shared mailbox X', 'different field', 'narrower trigger'. I'll bake it into the source as a comment."*
+
+Wait for that answer. The note must be ≥10 chars and concrete.
+
+If the user picks (c) skip, do NOT call `save_automation_draft`. Tell them you stopped and link the existing agent. Stop here.
+
+## Step 5 — Tool grants
+
+Derive from Steps 3 + 4. The user doesn't pick this — you do. Mention it inline in Step 7.
+
+| Operation | Grant |
+|---|---|
+| Read a board / list boards | `get_board` / `list_boards` |
+| Read a page body | `get_page` |
+| Keyword search | `search` |
+| Semantic query, **and `brains.discover` / `brains.discoverRows`** | `query` (both helpers call the `query` tool — granting only `search` fails at runtime) |
+| List recent pages | `list_pages` |
+| Calendar window | `list_calendar_events` |
+| Run a board skill | `run_board_skill` |
+| Patch a row | `update_board_row` |
+| Append a row | `append_board_rows` |
+| Retire a row (`brains.boards.delete` — soft) | `delete_board_row` |
+| Un-retire a row (`brains.boards.restore`) | `restore_board_row` |
+| Pull fresh gmail/calendar/drive data | `fetch_from_integration` |
+| Read a github/monday adapter (`brains.call("adapter_query", …)`) | `adapter_query` |
+| Send | `act_on_integration` (drafts for a confirm-required action; an action declaring `requires_confirmation:false` sends inline) |
+| Send a Telegram DM (only when user explicitly asked) | `telegram_push` (bypasses draft/confirm — delivers immediately) |
+| Write a memory page | `create_page` |
+| LLM call from sandbox | `automation_complete` |
+| Outbound HTTP (whitelisted hosts) | `http_fetch` |
+| Vault secrets | `automation_secret_list` (read keys), values are auto-substituted in http_fetch |
+| Per-automation K/V (cursors, watermarks) | **none** — `automation_state_*` needs no grant |
+
+**Grant by bare MCP tool name.** A tool reached via `brains.call("name", …)` still needs `name` in the grants — the escape hatch doesn't bypass the allowlist. See **the sandbox authoring contract** above for the full callable surface and which path each integration class uses.
+
+**Rule of thumb:** grant the minimum set; do NOT include `update_board_row` if the agent only reads. Skeleton tells you what it actually calls.
+
+## Step 5.5 — Egress confirmation (mandatory if `http_fetch` is in the grants)
+
+If `http_fetch` is NOT in the grants from Step 5, skip this step silently.
+
+Otherwise — before drafting source in Step 7 — you MUST get explicit user approval for the exact set of hostnames this agent may contact. That set becomes a server-enforced per-agent allowlist: the runtime `http_fetch` handler rejects any other host. The save call (`save_automation_draft`) refuses outright unless this list is passed as `acknowledged_http_fetch_hosts`. So this step is not advisory — without an approved list, the agent literally cannot save.
+
+Walk through the host list with the user using this template VERBATIM (substitute the actual hosts and a one-line description of what each call carries):
+
+> "**SECURITY CHECK — `http_fetch` access.** This grant lets the agent send any data the script reads from your brain (emails, board rows, calendar, search results) to the hostnames you approve here. The Deno sandbox does NOT block this — egress happens from the MCP server. Per-agent host pinning is the actual enforcement: the runtime rejects any host not in this list, and `save_automation_draft` refuses to save without it.
+>
+> Hosts this agent will contact:
+> - `<host-1>` — `<what it sends/receives, e.g. 'GET market data, no body'>`
+> - `<host-2>` — `<...>`
+>
+> If a future source edit needs a new host, you'll have to re-save with that host added — the runtime won't let it in otherwise.
+>
+> Do you approve `http_fetch` for this agent, scoped to the hosts above? Reply **'yes, approve http_fetch'** to proceed, or 'no' / 'change hosts' to adjust."
+
+Wait for an explicit, unambiguous approval. The required phrase is the literal string "yes, approve http_fetch" (case-insensitive). Anything else — including "yes", "sure", "go", "fine", "looks good", "ok", "lgtm", a thumbs-up, or silence — does NOT count and you MUST re-prompt with the same template. This is a security boundary, not a feature confirmation; the friction is intentional.
+
+If the user says "no" or refuses approval, drop `http_fetch` from the grants and either (a) propose a source variant that uses only brains tools (search / get_page / boards), or (b) stop and tell them this agent can't be built without external HTTP. Do NOT silently keep the grant and hope they don't notice.
+
+If the user says "change hosts" or names specific hosts, narrow the source to only contact those, update the host list, and re-run this step.
+
+If the user attempts to skip the check ("just save it", "I trust you", "stop asking"), refuse politely and re-prompt: *"This one I have to ask explicitly — the server refuses the save without an approved host list. Reply 'yes, approve http_fetch' with the host list above, or 'no'."*
+
+Record the approved host list as an array of bare hostnames (e.g. `["api.binance.com", "api.etherscan.io"]` — no protocol, port, path, or wildcards). You'll pass this verbatim as `acknowledged_http_fetch_hosts` to `save_automation_draft` at Step 8, and surface it again in the Step 7 grant summary so the user sees it one more time before the source is saved.
+
+## Step 5.7 — Secrets (mandatory if the source references `{{secret_name}}`)
+
+If the draft plan calls an external API that needs a credential (an API key, a PAT, a webhook signing secret), the source references it as `{{secret_name}}` and the value lives in the user's encrypted vault — NOT in this conversation.
+
+**Hard rule: never ask the user to paste a secret value into the chat.** Not "just this once", not encoded, not "only the last 4 characters". A value pasted into a conversation lands in the transcript and whatever logging surrounds it. You work with NAMES; the vault holds values. (A Telegram bot token is not even a vault case — see Step 4.)
+
+For each secret the source needs:
+
+1. **Propose a conventional name** — lowercase snake_case matching /^[a-z0-9_]+$/, e.g. `notion_api_token`, `stripe_api_key`. Confirm the NAME with the user, never the value.
+2. **Check whether it already exists:** call `automation_secret_get` with the name — it returns metadata only (a `found` flag plus the secret row's description and timestamps), never the decrypted value. `automation_secret_list` enumerates all stored names when the user isn't sure what they have.
+3. **If it exists:** reference `{{name}}` in the source and note it in the Step 7 summary ("uses your existing secret `notion_api_token`"). Done — do not ask anything further about it.
+4. **If it's missing**, tell the user, verbatim (substitute the actual name):
+
+> "This agent references a secret named `<name>` that isn't in your vault yet. I won't ask for the value here — pasting API keys into chat leaves them in the transcript. I'll finish the setup referencing it by name; until the value is stored, runs fail with a clear `missing automation_secrets` error, and the agent's page (linked when we finish) lists exactly which secrets are missing. When you're ready, store it with the `automation_secret_set` tool in a message of its own — and if a key has ever been pasted into a shared or logged conversation, rotate it with the provider first."
+
+Then continue the flow — a missing value never blocks Steps 7–9. Step 8 saves as usual and then **immediately pauses** the agent (see the missing-secret pause rule there) so a cron/page trigger can't burn every scheduled run on a secret you know is missing.
+
+**If the user pastes a raw secret value anyway** (unprompted, or in reply to the message above): do NOT refuse and do NOT echo it back. Store it immediately with `automation_secret_set` under the agreed name, confirm by name only ("stored as `notion_api_token`"), and advise once that the value transited this conversation, so rotate it with the provider when practical. Refusing after the paste maximizes exposure for zero benefit.
+
+## Step 6 — Caps
+
+Default: `cost_cap_daily_usd: 1.00`, `max_wall_seconds: 60`, `max_llm_tokens: 200000`. For sub-minute crons, lower wall to ~30s. For LLM-summary jobs, raise tokens to 500k. Confirm only if you're deviating from defaults; otherwise apply silently.
+
+If the agent was granted `http_fetch`, it also carries `egress_cap_daily_mb: 10` — a ceiling on total http_fetch bytes (sent + received) per UTC day. The default suits status/price/webhook polling; raise it (max 10240) only for agents that legitimately move more data, and call that out when you do.
+
+## Step 7 — Summary & confirm
+
+Pick the skeleton that matches the trigger + write shape (see "Skeletons" below) and substitute the user-specific bits (board id, dedupe key, type filter) — but do NOT show the assembled source to the user unless they explicitly ask ("show me the code", "let me see the script"). Most users don't read TypeScript; the source is reviewable post-save at `/agents/<id>`. Show a plain-English summary instead:
+
+> "Here's what I'd build:
+>
+> **Trigger:** `page_ingested` on `type=email`
+> **Reads:** Ethera CRM rows to find the matching company
+> **Writes:** appends each email to `company.updates` on the matched row, deduped on `postId` (page slug) so the same email is never logged twice
+> **Grants:** `get_board, get_page, update_board_row`
+> **Secrets:** `{{notion_api_token}}` — already in your vault ✓ *(omit this line when the source references no secrets; for a missing one write: "missing — store after save (Step 5.7); runs fail cleanly until then")*
+> **Caps:** $1/day, 60s wall
+>
+> Sound right?"
+
+**Ask "Sound right?" exactly once.** If the user replies with any approval signal — *"yes"*, *"yep"*, *"go"*, *"go for it"*, *"sounds good"*, *"looks good"*, *"lgtm"*, *"build it"*, *"save it"*, *"do it"*, *"looks fine"*, *"fine"*, *"ok"*, a thumbs-up emoji, or any short affirmation — call `save_automation_draft` **IMMEDIATELY**. Do not re-summarize. Do not re-ask. Do not request another round of confirmation. **Re-asking after approval is a bug** — the user already said yes; treat the next step as "save", not "confirm again".
+
+Only re-iterate if the user gives substantive feedback that changes the plan (e.g. *"narrow the type filter"*, *"raise the wall seconds"*, *"switch the write target"*). At most 2–3 substantive rounds before you should be saving. Mild qualifiers like *"yeah I guess"*, *"sure why not"*, *"ok whatever"* still count as approval — proceed to save.
+
+**Mint an `idempotency_key`** (a uuid); record it as `idem=<key>` in your checkpoint.
+
+**The Step 5.5 http_fetch egress gate is a separate concern.** That one DOES require the literal phrase `"yes, approve http_fetch"` and cannot be satisfied by generic approval — don't conflate the two. Step 7 is friendly approval; Step 5.5 is a security boundary with intentional friction.
+
+## Step 8 — Save (active) and hand off
+
+Call **`save_automation_draft`** (same MCP namespace) with:
+- `idempotency_key` — the `idem` from Step 7. Resend it unchanged on any retry, or you create a second agent on the same cron.
+- `name` (short, kebab-case is fine)
+- `description` (one line)
+- `intent` (one sentence — what fires it, what it does)
+- `source` (the assembled TypeScript)
+- `triggers` (array, e.g. `[{kind: "page_ingested", types: ["email"]}]`)
+- `tool_grants` (array of `{tool: "name"}` objects)
+- `cost_cap_daily_usd`, `max_wall_seconds`, `max_llm_tokens`
+- `egress_cap_daily_mb` — only if the user raised it at Step 5.5 (default 10, max 10240)
+- `writes_to_boards` (uuid[]) — same value you passed to find_overlapping_automations
+- `dedupe_target_field` (e.g. `"updates"`) — only if the source appends to a shared array
+- `dedupe_key_field` (e.g. `"postId"`) — pair with the above; required for future Step 4.5 checks to be useful
+- `acknowledged_http_fetch_hosts` (string[]) — REQUIRED if `tool_grants` includes `http_fetch`. The exact list of bare hostnames the user approved at Step 5.5 (e.g. `["api.binance.com", "api.etherscan.io"]`). The runtime `http_fetch` handler enforces this list per request; passing a different host at runtime fails with a clear "host not in approved hosts" error. Pass empty / omit if `http_fetch` is not granted (server rejects misleading combinations).
+
+**Hard gate behaviour at save (http_fetch):** if `tool_grants` includes `http_fetch` AND `acknowledged_http_fetch_hosts` is missing or empty, the server REFUSES the save with `save refused: tool_grants includes http_fetch but acknowledged_http_fetch_hosts is missing or empty`. Recover by re-running Step 5.5 with the user, capturing the host list, and retrying the save with the array populated. Don't try to bypass — there is no other path. (And don't pass `acknowledged_http_fetch_hosts` when `http_fetch` is NOT granted — the server rejects that combo as misleading too.)
+
+**Hard gate behaviour at save (overlap):** if Step 4.5 returned `strict_count > 0` AND the user picked option (b) "carry on" / coexist (NOT skip), the server will REFUSE the save unless you also pass:
+
+- `acknowledged_overlap: true`
+- `coexistence_note` (≥10 chars) — a one-sentence explanation of *why* this new agent should run alongside the existing one(s). Use the user's own words from the mitigation discussion. The server prepends this note to the saved source as a header comment for audit.
+
+If the server rejects the save (look for an error message starting with `save refused:`), do NOT retry naively. Re-read the rejection — it tells you which agent the gate matched. Either:
+- Ask the user for the missing coexistence note (paraphrase the mitigation reasoning they already gave you in Step 4.5) and retry with `acknowledged_overlap: true` plus the note, OR
+- If the user actually meant skip, stop and link them to the existing agent.
+
+Never set `acknowledged_overlap: true` without a real coexistence_note — the server rejects empty / too-short notes by design, and rightly so: the comment is the audit trail.
+
+If Step 4.5 returned 0 overlaps, do NOT pass `acknowledged_overlap` or `coexistence_note` — the server rejects the call as misleading.
+
+The new agent lands in `active` state — it will start firing on its cron / page_ingested / board triggers immediately. The smoke test in Step 8.5 uses a manual run (`run_automation_once`), which executes regardless of state. If the user wants to halt scheduled firings after install, they can pause from the agent's page.
+
+**Missing-secret pause (mandatory when Step 5.7 left a referenced secret unstored):** right after the save returns, call `update_automation` with `{automation_id, state: "paused"}` — a state-only patch; do NOT pass `tool_grants` or `acknowledged_http_fetch_hosts` with it. An active agent whose secret is missing fails every scheduled run with the same `missing automation_secrets` error until the value is stored; paused, it costs nothing and fires nothing. The Step 8.5 smoke test still works (manual runs execute on paused agents), and Step 9's narration must tell the user it is paused and how to activate. Skip this pause when every referenced secret already exists.
+
+## Step 8.5 — Smoke test (mandatory)
+
+Before handing off, prove the source compiles and runs end-to-end against a real trigger payload by firing one manual dry run. Call **`run_automation_once`** with:
+
+- `automation_id` — from Step 8
+- `dry_run: true` — default; lets the user code execute but suppresses outbound writes (same hook the admin Dry-Run button uses)
+- `verify_mode: true` — **REQUIRED for self-verification during this flow.** When true the MCP server suppresses all outbound side-effect tools (telegram_push, email / calendar / drive sends via act_on_integration, fetch_from_integration writes, and non-GET http_fetch) and returns suppressed-shape stubs instead. This lets you confirm the source compiles and the logic path executes end-to-end **without spamming the user's phone / inbox / drive** while you're still iterating. The user code still runs; only the deliveries are muted.
+
+The tool enqueues a `trigger_kind='manual'` run and polls `automation_runs` until it terminates (or `wait_seconds` elapses). Default wait is `max_wall_seconds + 90` to cover the runner's ~30s tick + sandbox spawn.
+
+Read the result:
+
+| `status` | What to do |
+|---|---|
+| `succeeded` | Smoke test passed. Quote the key lines from `stdout` to the user (e.g. *"appended postId=mail-abc-123 to row F-001"*) and move to Step 9. |
+| `partial` | The process exited 0 but wrote to stderr — the user's code caught errors and kept going (e.g. one board hit a rate limit, others succeeded). Treat as a failure for smoke-test purposes: show the `stderr` tail, identify the failing operation, fix the source (often a retry/backoff or a tool grant), and re-run. Do NOT call Step 9 until the run is fully `succeeded`. |
+| `failed` / `killed` | Show the user the `error` field + the tail of `stderr`. Common shapes: missing tool grant (`tool 'X' not in grants`), missing board row, schema mismatch on the dedupe key. Patch the source via `update_automation` and re-run `run_automation_once` (keep `verify_mode: true`). **`update_automation`'s `source` is a FULL REPLACEMENT, not a diff** — if you no longer hold the exact source you saved, call `get_automation` first to read the live `source` back (it also returns `write_policy` and `http_fetch_hosts`), patch that, and send the whole thing. Blind-writing a reconstructed source silently drops whatever you forgot. |
+| `failed` on `http_fetch: missing automation_secrets for user: <name>` | **Expected when the referenced secret isn't stored yet (Step 5.7)** — the source is not wrong and there is nothing to patch: no source fix happens, so no fix-cycle is consumed and this does NOT count toward the 3-attempt cap (Step 8's state-only pause is not a fix either). Be precise about what this run proved: the source compiles and reaches the first external call; everything past that call did NOT execute and stays unverified until the secret exists. Hand off: *"It's paused until you store the secret `<name>` (the agent's page lists it). Once stored, activate from the page and re-run the check — the logic past the first API call hasn't executed yet."* Do NOT ask for the value to "finish" the smoke test. |
+| `skipped` | The source bailed early (e.g. `if (page.type !== "email") return`). Confirm with the user whether that's the right behaviour for the trigger payload that fired; if yes, move to Step 9. If no, fix the filter and re-run. |
+| `queued` / `running` (timed out — `timed_out: true`) | The run didn't reach a terminal status before `wait_seconds`. The response carries `timeout_reason` (`runner_down` / `runner_slow` / `run_overran`) and a `next_step` line — **surface `next_step` verbatim to the user**, don't improvise a triage table. Then move on to Step 9 without a green-light claim. If `timeout_reason='run_overran'` the smoke test actually executed your code; tail `stdout` / `stderr` from the agent's page before deciding whether to re-run. |
+
+**HARD CAP on the fix-revalidate loop: 3 attempts.** Count every `update_automation` → `run_automation_once` cycle. If the smoke test is still not `succeeded` after 3 attempts:
+
+1. Stop iterating. Do not try a 4th fix.
+2. Save what you have (the draft is already persisted from Step 8 — no action needed).
+3. Surface the last error clearly to the user: which run id, which `status`, the tail of `stderr`, your best guess at the root cause.
+4. Ask the user explicitly: *"3 fixes in and still failing — want to keep iterating (tell me what you'd change), or save-and-revisit later from `/agents/<id>`?"*
+5. Let the user decide. Do NOT loop indefinitely — that burns the user's turn budget and is a bug, not diligence.
+
+Surface the outcome to the user before Step 9 — do not silently swallow failures.
+
+## Step 9 — Hand off
+
+Open `<WEB_URL>/agents/<id>` fire-and-forget so the user can eyeball + activate:
+- macOS: `Bash(open <URL>)`
+- Linux: `Bash(xdg-open <URL>)`
+
+Narrate, concisely:
+
+> "Saved and active. Smoke test came back `<status>` (run id `<run_id>`). Opening its page now — review triggers / grants. Agent is firing on its trigger from here; pause from that page if you want to halt it."
+
+**If Step 8 paused it for a missing secret**, narrate instead:
+
+> "Saved but **paused** — it references the secret `<name>`, which isn't in your vault yet. Store it (`automation_secret_set` in a message of its own), then activate from the agent page; it won't fire on its trigger until you do. Smoke test came back `<status>` (run id `<run_id>`)."
+
+Stop here.
+
+## Skeletons
+
+Pick one as the starting point; substitute the bracketed bits.
+
+**Two author styles are supported.** Pick whichever fits the trigger shape — both compile and run identically in the sandbox:
+
+- **Style A — top-level await.** No `import` line; `brains` is in scope as a global (the runner injects it). Just wrap your logic in `async function main() { ... }` and `await main()` at the bottom.
+- **Style B — ESM default export.** `import { brains } from "./brains.ts";` at the top, then `export default async function run(ctx) { ... }`. The runner invokes the default export with a `ctx` object: `{ trigger, brains, runtime }`. `ctx.trigger` is the same payload as `brains.event` (e.g. `ctx.trigger.page` on `page_ingested`, `ctx.trigger.board` on `board_change`).
+
+Skeletons below show Style A first; the final one shows Style B for reference.
+
+### `page_ingested_log_to_board` — log emails (or any page type) onto a board row's `updates` array
+
+```ts
+async function main() {
+  const ev = brains.event as { page?: { slug: string; type: string; title: string; updated_at: string; frontmatter: Record<string, unknown> } };
+  const page = ev.page;
+  if (!page || page.type !== "<PAGE_TYPE>") return; // filter
+
+  const BOARD_ID = "<BOARD_UUID>";
+  const DEDUPE_KEY = "<postId|event_id|...>"; // upstream stable id field on each updates entry
+  const dedupeValue = page.slug;               // for emails: page slug. For calendar: page.frontmatter.event_id, etc.
+
+  // --- match: read enough rows to find the target lead/row, then derive the company row.
+  // Boards may be large; paginate if you expect >500 rows.
+  const allRows: Array<Record<string, unknown>> = [];
+  let offset = 0; const PAGE = 1000;
+  while (true) {
+    const b = await brains.boards.get(BOARD_ID, { dataset: "default", offset, limit: PAGE }) as { data: { datasets: { default?: { rows?: Array<Record<string, unknown>> } } } };
+    const chunk = b.data?.datasets?.default?.rows ?? [];
+    allRows.push(...chunk);
+    if (chunk.length < PAGE) break;
+    offset += chunk.length;
+    if (offset > 5000) break;
+  }
+  const target = allRows.find((r) => /* match logic — e.g. r.kind === "company" && r.id === ... */ false);
+  if (!target) { console.log("no match"); return; }
+
+  // --- IDEMPOTENCY: skip if we already logged this upstream id.
+  const existing = (Array.isArray(target.updates) ? target.updates : []) as Array<Record<string, unknown>>;
+  if (existing.some((u) => u[DEDUPE_KEY] === dedupeValue)) {
+    console.log("already logged " + dedupeValue + " on " + String(target.row_id));
+    return;
+  }
+
+  // --- assemble the entry. Pull body if you want it in content.
+  const full = await brains.get_page(page.slug) as { markdown?: string };
+  const body = (full.markdown ?? "").replace(/^---\n[\s\S]*?\n---\n+/, "").trim();
+  const entry = {
+    user: "automation:<NAME>",
+    postId: page.slug,
+    content: page.title + "\n\n" + body.slice(0, 2400),
+    createdAt: new Date().toISOString(),
+    parentPostId: "",
+  };
+  await brains.boards.update_row(BOARD_ID, target.row_id as string, { updates: [...existing, entry] });
+  console.log("appended " + dedupeValue + " to " + String(target.row_id));
+}
+await main();
+```
+
+### `cron_summary_send` — daily/weekly digest, pings the owner on Telegram
+
+```ts
+async function main() {
+  const since = new Date(Date.now() - 24 * 3600 * 1000).toISOString();
+  const pages = await brains.list_pages({ type: "email", since, limit: 50 });
+  if (pages.length === 0) { console.log("nothing new"); return; }
+
+  const items = pages.map((p) => "- " + p.title).join("\n");
+  await brains.telegram_push({
+    text: "Daily email digest:\n" + items,
+  });
+  console.log("telegram nudge sent");
+}
+await main();
+```
+
+### `board_change_react` — fire when a specific board changes; useful for status-transition handlers
+
+```ts
+async function main() {
+  const ev = brains.event as { board?: { id: string; data: { rows?: Array<Record<string, unknown>> } } };
+  const rows = ev.board?.data?.rows ?? [];
+  // ...filter rows whose status just transitioned. Use a watermark on a side
+  // store if you need "only newly-transitioned"; otherwise rely on the
+  // dedupe pattern above (skip if you've already acted on this row's id).
+}
+await main();
+```
+
+### `telegram_notify` — send a Telegram DM when a condition fires (use ONLY if the user explicitly asked for Telegram)
+
+Pre-req: the user must have a bot set up at `/integrations/telegram` — checked in Step 4 before you reach this skeleton. The MCP server already holds the encrypted bot token; the agent never sees it, never needs it, and never asks the user for it. Just call `brains.telegram_push({ text })` and it routes to the user's bot.
+
+```ts
+async function main() {
+  const ev = brains.event as { page?: { title?: string; slug?: string } };
+  const title = ev.page?.title ?? "(no title)";
+
+  // Whatever condition the user described — gate the send on it.
+  // Example: only ping for messages from a specific sender.
+  // if (!somethingInteresting) return;
+
+  await brains.telegram_push({
+    text: `Heads up: ${title}`,
+  });
+}
+await main();
+```
+
+`tool_grants` must include `telegram_push`. No secret, no `http_fetch`, no `acknowledged_http_fetch_hosts` for `api.telegram.org` — that path is wrong and will leak the bot token if someone tries it.
+
+### `page_ingested_log_to_board_style_b` — same job, **Style B (import + default export)**
+
+Functionally identical to the first skeleton — illustrates the ESM idiom for authors who reach for it naturally. The runner accepts both.
+
+```ts
+import { brains } from "./brains.ts";
+
+export default async function run(ctx: {
+  trigger: { page?: { slug: string; type: string; title: string; updated_at: string; frontmatter: Record<string, unknown> } };
+  brains: typeof brains;
+  runtime: { verify: boolean };
+}) {
+  const page = ctx.trigger.page;
+  if (!page || page.type !== "<PAGE_TYPE>") return; // filter
+
+  const BOARD_ID = "<BOARD_UUID>";
+  const DEDUPE_KEY = "<postId|event_id|...>";
+  const dedupeValue = page.slug;
+
+  // Paginate the board.
+  const allRows: Array<Record<string, unknown>> = [];
+  let offset = 0; const PAGE = 1000;
+  while (true) {
+    const b = await ctx.brains.boards.get(BOARD_ID, { dataset: "default", offset, limit: PAGE }) as { data: { datasets: { default?: { rows?: Array<Record<string, unknown>> } } } };
+    const chunk = b.data?.datasets?.default?.rows ?? [];
+    allRows.push(...chunk);
+    if (chunk.length < PAGE) break;
+    offset += chunk.length;
+    if (offset > 5000) break;
+  }
+  const target = allRows.find((r) => /* match logic */ false);
+  if (!target) { console.log("no match"); return; }
+
+  // Idempotency.
+  const existing = (Array.isArray(target.updates) ? target.updates : []) as Array<Record<string, unknown>>;
+  if (existing.some((u) => u[DEDUPE_KEY] === dedupeValue)) {
+    console.log("already logged " + dedupeValue);
+    return;
+  }
+
+  // get_page returns both `markdown` (raw) and `body` (frontmatter stripped) —
+  // pick whichever fits.
+  const full = await ctx.brains.get_page(page.slug);
+  const entry = {
+    user: "automation:<NAME>",
+    postId: page.slug,
+    content: page.title + "\n\n" + full.body.slice(0, 2400),
+    createdAt: new Date().toISOString(),
+    parentPostId: "",
+  };
+  await ctx.brains.boards.update_row(BOARD_ID, target.row_id as string, { updates: [...existing, entry] });
+  console.log("appended " + dedupeValue);
+}
+```
+
+### `adapter_read` — read a github/monday adapter into a board (the ad-hoc `adapter_query` path)
+
+Use this when the agent needs data from an **adapter integration** (github, monday, …). There is no `fetch_from_integration` or `act_on_integration` path for these — go through `brains.call("adapter_query", …)` in ad-hoc mode against the user's stored OAuth token. `tool_grants` must include `adapter_query`.
+
+```ts
+async function main() {
+  // Ad-hoc adapter read — `kind` is the adapter, `op` one of that adapter's
+  // declared ops, `ref` the adapter-specific target (e.g. {owner,name} for
+  // github, {board_id} for monday). Workspace-level ops (e.g. monday
+  // list_boards) ignore `ref`. github ops: get_repo, list_open_prs,
+  // list_recent_commits. If unsure which ops/return-shape an adapter exposes,
+  // call list_integrations (adapter:true rows) rather than guessing op names.
+  const out = await brains.call<{ prs?: Array<Record<string, unknown>> }>(
+    "adapter_query",
+    { kind: "github", op: "list_open_prs", ref: { owner: "ssvlabs", name: "brains" }, params: { limit: 50 } },
+  );
+  const rows = out.prs ?? [];
+  if (rows.length === 0) { console.log("nothing from adapter"); return; }
+  // ...dedupe against the board (skip ids already present), then append/update.
+  console.log("adapter_query returned " + rows.length + " prs");
+}
+await main();
+```
+
+## Common gotchas
+
+- **`brains.get_page` returns BOTH `markdown` (raw, includes frontmatter) and `body` (frontmatter stripped, trimmed).** Use `body` unless you specifically need the raw fenced output.
+- **`brains.boards.get(id)` returns `rows: []` by default.** You must pass `{ dataset: "default", offset, limit }` to get rows. Paginate if >1000.
+- **NEVER patch a row back whole.** Read the row, decide what changes, and send ONLY the changed fields: `brains.boards.update_row(id, row.row_id, { status: "done" })`. Spreading a row you just read (`{ ...row, status: "done" }`) is rejected — a read-back row carries the server-managed keys `row_id` / `_src` / `_updated_at`, and rows the automation itself created ALWAYS carry `_src`. It is also unsafe even where it is accepted: re-sending a whole row reinstates every value as of your read, so it can clobber another writer's edit or restore an access rule (`_visible_to` / `_editable_by`) that was revoked in between. To delete or undelete, use `brains.boards.delete` / `brains.boards.restore` — never patch `_deleted_at`.
+- **`brains.boards.delete` is a SOFT delete.** The row keeps its `row_id` (so re-appending that id collides) and stays restorable via `brains.boards.restore`. For a toggle (RSVP, reaction) use delete + restore on a deterministic row_id, not delete + re-append. It does not accept `hard` — an irreversible splice needs `brains.call("delete_board_row", { board_id, row_id, hard: true })` and is almost never what an automation wants.
+- **Email bodies embed quoted reply history.** If you put the body in user-facing output, cut at the first quote marker (`/\n[\s>]*(?:On .+wrote:|-----\s*Original Message-----|From:\s+[^\n]+\n[\s>]*(?:Sent|Date|When):|_{5,}|>+\s)/i`) to avoid duplicate-looking entries.
+- **Branch on the returned `kind`; never assume a `draft_id`.** Preserve an ambiguous failed write for inspection instead of firing it again on the next tick. The generated contract above is authoritative for retry and confirmation behavior.
+- **Cron runs in UTC unless you pass `tz`.** Be explicit.
+- **github/monday are adapter integrations, not `act_on_integration` sources.** Reach them with `brains.call("adapter_query", {kind, op, ref?})` and grant `adapter_query` — see the sandbox authoring contract near the top. Only gmail/calendar/drive (and codex installs with declared actions) use `act_on_integration`/`fetch_from_integration`.
+- **`brains.call("name", …)` is the escape hatch for any tool without a dedicated helper, but `name` must still be in `tool_grants`.** It is not a way around the allowlist.
diff --git a/plugins/brains/skills/brains-board/SKILL.md b/plugins/brains/skills/brains-board/SKILL.md
new file mode 100644
index 0000000..d9dc4c8
--- /dev/null
+++ b/plugins/brains/skills/brains-board/SKILL.md
@@ -0,0 +1,172 @@
+---
+name: "brains-board"
+description: "Design and build a new board end to end — datasets and columns, where its rows come from, optional saved actions and a dashboard. Use when the user wants to start tracking something: \"track a list of…\", \"keep a table of…\", \"build a tracker\", \"build a CRM\", \"log every…\". Not for reading, filtering or adding rows to a board that already exists."
+---
+
+<!-- Generated by ssvlabs/brains apps/mcp/scripts/generate-capability-catalog.ts.
+     Source: the authoring procedure catalog. Do not hand-edit. -->
+
+# Create-board flow — draft, then refine
+
+You're helping the user build a well-structured board. Your job is to turn what they want into a clean board (datasets, columns, a data source, optional skills, optional dashboard) **fast**, without making them think in DB terms and without interrogating them before they've seen anything concrete.
+
+## Hard rules
+
+- **Draft-then-refine, NOT interrogate-then-gate.** Ask at most ONE upfront question (purpose), and only if you can't already infer it. Then immediately propose a complete board — including how it gets its data — and build it the moment the user signals go. Do NOT run a multi-question gate (what-to-store, relationships, approval) before showing a proposal. The proposal IS the conversation.
+- **Board-first.** This flow ships a board. Skills and dashboards are optional add-ons offered AFTER the board exists — never block board creation on them.
+- **Always presume a data source.** Every board is populated somehow: (a) a connected **integration** (GitHub / Gmail / Google Calendar / Google Drive / Monday / …), (b) an **agent** that writes rows on a schedule or trigger, or (c) **manual** entry. Infer the most likely one from the purpose + the user's connected integrations and **state it in the proposal**. NEVER silently leave it manual by omission — if manual is right, say so ("you'll add rows yourself"); if a live source fits, propose it and offer to connect/wire it. A board with no stated source is an incomplete proposal.
+- **Refinements are optional, never gates.** After the proposal, changes — rename fields, add a relationship, seed data, skills, dashboard, different data source — are offered as quick choices the user can take or ignore. They must never stop the user from getting a board.
+- **Respect the escape hatch.** If the user says "just build it" / "whatever you think" / "you decide" at any point, build the current best draft immediately with sensible defaults and skip every remaining question.
+- **Infer, don't ask, the structure.** Columns, whether it's one dataset or several, relationships — you work these out and show them. Don't ask "what columns?" or "does anything connect?" — decide and present it; the user corrects if wrong.
+- **Plain language until the proposal.** Don't say "schema", "column type", "dataset" before the proposal — talk about "what you want to track" and "things that connect".
+- **Use the same MCP namespace that returned this playbook.** Tool names below are written without an `mcp__<server>__` prefix. If you called this as `mcp__brains__create_board_flow`, use `mcp__brains__*` for every downstream call (`create_board`, `list_my_integrations`, `append_board_rows`, `create_board_skill`, `set_dashboard`, `search`, `query`, `get_page`, `create_automation_flow`). Do not mix namespaces.
+
+## Flow state — one line, every turn
+
+End EVERY message in this flow with a checkpoint (last line, above any chips), so a later turn
+can pick up where you left off:
+
+`FLOW board · step 1/8 purpose · done: (none) · facts: (none) · next: the user's answer to the question above`
+
+Steps in order: `purpose`, `source`, `propose`, `build`, `wire`, `skills`, `dashboard`, `wrap`. Write `(none)` in a segment that has nothing yet.
+When the flow is finished emit `FLOW board · done` instead, or
+`FLOW board · cancelled` if the user drops it — without that,
+the flow looks live forever.
+
+`done:` records what you have already CREATED, with the id the call returned — `board_id=…`. Write it there the moment the call comes back. It is the only record that survives: a confirmation means the user said yes, not that the write happened.
+
+`facts:` carries the decisions you cannot re-read from the conversation — `source`. Keep each one short.
+
+**Picking up a flow already in progress:**
+
+1. **Before creating anything, check whether you already did.** If the last checkpoint names an
+   effect for the step you are about to run, that artifact exists — look it up by its id, tell the
+   user, and continue from the next step. Never create a second one.
+2. Checkpoint present and readable → carry on from the step it names.
+3. Checkpoint garbled → re-emit a corrected one from what you can see, then carry on.
+4. No checkpoint but you still have this procedure → work out where you are from the
+   conversation, say in one line where you are resuming, and confirm before any write.
+5. No checkpoint and no procedure → do not improvise the steps; the gates in here are not
+   optional. The one exception: if the user asks to pick a flow back up and you no longer have its procedure in front of you, reload it once — then continue from the last checkpoint rather than starting over. Never re-fetch one you can still see.
+6. Nothing recoverable → start over, but collect everything in ONE question instead of walking
+   the whole interview again.
+
+## Step 1 — Purpose (skip if you already know it)
+
+If a non-empty `purpose_hint` was passed in, OR the user's message already says what the board is for, **do not ask** — restate it in one line (*"Board for tracking X — got it."*) and go straight to Step 2.
+
+Only if you genuinely can't tell, ask ONE question and stop:
+
+> "What's this board for? One sentence — e.g. *'track candidates I'm interviewing'*, *'log every workout'*, *'my open GitHub PRs'*."
+
+Do not ask a second setup question. The next thing the user sees after answering is a full proposal, not another question.
+
+## Step 2 — Infer the data source (before you propose)
+
+Decide how this board gets populated:
+
+- Call `list_my_integrations` to see what the user has connected.
+- Map the purpose to the most likely source:
+  - GitHub PRs / issues / repos → **GitHub** integration
+  - emails / inbox / follow-ups → **Gmail**
+  - meetings / schedule / events → **Google Calendar**
+  - docs / files → **Google Drive**
+  - Monday items / boards → **Monday**
+  - a log the user fills in themselves (workouts, ideas, candidates they type, reading list) → **manual**
+  - rows that should appear/refresh on a schedule or event (daily digest, scraped feed, derived rollup) → an **agent**
+- Pick the single best fit. If it's an integration the user hasn't connected, you'll offer to connect it in the proposal — don't assume it's already there.
+- Also run the template check here: if the purpose maps cleanly to a starter template (`hiring-pipeline`, `crm-deals`, `bug-tracker`, `project-tracker`, `sprint-planning`, `new-hire-onboarding`, `customer-feedback`, `okrs`, `content-calendar`, `marketing-campaigns`), mention it as the starting point inside the proposal — don't make it a separate gating question.
+
+## Step 3 — Propose the whole thing (one message)
+
+Infer the structure and show a complete, concrete proposal in a single message. Include, in order:
+
+- **Board name** (human — "Candidates", not "candidate_tracking_db") + a one-line description.
+- **Datasets + columns.** 4–8 columns per dataset. Types: `text`, `select` (list options inline), `number`, `date`, `tags`, `user`, `richtext`. Infer relationships and show them — a *one X → many Y* shape means two datasets, where Y carries a **`*Ids` relationship column** pointing at X (see Step 4); a *shared entity* means its own dataset; otherwise one flat dataset. State what a row is in each dataset.
+- **Data source** — ONE short line, always present (never omit it). State the source only; do NOT narrate connection status or a connect button in prose — if the source is an unconnected integration, the surface renders its own connect affordance (Step 5), so repeating "not connected" / "connect below" here is noise. Examples:
+  - *"📥 Source: GitHub — kept in sync by an agent."*
+  - *"📥 Source: Gmail — seeded from matching threads, refreshable."*
+  - *"📥 Source: manual — you'll add rows yourself (I can seed a couple)."*
+- **Sample rows** — 1–2 per dataset if the user named specifics; otherwise note you'll leave it empty (or seed from the source).
+- **Go-ahead + escape hatch** — offer the choices (build / tweak / just-the-board). If your surface shows them as buttons, those buttons ARE the question — do NOT also ask in prose. On a plain-text surface, one line: *"Build it, tell me what to change, or say 'just build it'."*
+
+Present the change options as quick choices, not a form. **How you render those choices depends on your surface — follow your own surface instructions** (a chat UI that supports one-tap chips/cards should use them; a plain-text surface lists them in prose).
+
+**Build as soon as the user signals go** — "yes", "go", "build it", "do it", "just build it", or a clear affirmative. If they ask for a tweak, revise and re-show; don't loop more than ~2–3 times — if it's still drifting, build the simplest version that covers the must-haves and say so.
+
+## Step 4 — Build the board
+
+Call `create_board` (same MCP namespace) with:
+- `name` — short and human.
+- `description` — the purpose sentence.
+- `schema` — `{ "version": 2, "datasets": ["<name1>", "<name2>", ...] }` (dataset *names* only).
+- `data` — `{ "datasets": { "<name>": { "rows": [...starter rows or empty...], "schema": { "columns": [{ "key": "<row_field>", "label": "<human label, optional>", "field_type": "text|select|number|date|tags|user|richtext", "options": [...] (select only) }] } } } }`. Embed each dataset's columns under `data.datasets.<name>.schema.columns`.
+  - `key` is the row property name (rows are looked up by it) — the web UI reads `c.key`.
+  - **The type key is `field_type`, not `type`, and the seven values above are the complete set.** `create_board` does NOT validate `data`, so a wrong key or an invented type is accepted silently and then degrades everywhere downstream: select chips, tags, user resolution and number formatting all fall back to plain text, and the auto-seeded dashboard is derived from untyped columns. There is no `link` field type.
+  - **Cross-dataset relationships are a naming convention, not a column type.** Name the column `<entity>Ids` (camelCase, plural, e.g. `companyIds`, `leadIds`) and declare it in the schema; `append_board_rows` then resolves arrays of referenced row ids — and free-text names — into real entity links. If the `*Ids` column is not declared in the dataset schema, values stay inert text: no chips, no graph boost.
+
+The new board id is in the response. Open it fire-and-forget so the user sees it immediately (macOS `Bash(open <WEB_URL>/boards/<board_id>)`, Linux `xdg-open`); don't block on exit code. Narrate one line: *"Board's up — opening it now."*
+
+## Step 5 — Data source: connect / wire / seed (skip only if plain manual with nothing to pull)
+
+Act on the source you proposed:
+
+- **Integration, connected:** offer to keep it fresh — `create_automation_flow` to wire a sync agent — and/or seed once now (`fetch_from_integration` or `search`/`query` → `append_board_rows`).
+- **Integration, NOT connected:** surface a connect prompt naming the integration and why (*"Connect GitHub and this board stays in sync with your PRs."*). On a surface that supports it, emit it as a connect card (the UI shows the integration's icon + a Connect button — follow your surface instructions); on plain text, give the connect link/instruction in one line. After they connect, wire/seed. If they decline, leave the board manual and note it can be wired later.
+- **Agent:** run `create_automation_flow` to build the writer.
+- **Manual:** offer a one-time seed — (a) pull from the user's brain pages (`search`/`query` → `get_page` → `append_board_rows`, cite sources briefly), (b) they paste rows, or (c) skip.
+
+Don't make this a wall — one offer, act on the answer, move on.
+
+## Step 6 — Skills (optional — offer once, don't gate)
+
+Offer a couple of one-tap actions for the board, with concrete suggestions mined from the schema (don't ask "want skills?" with nothing attached):
+- a date column (`last_touch`, `updated_at`) → `flag-stale` (rows older than N days)
+- a `stage`/`status` select → `weekly-digest` or `stage-changes`
+- a `link` column → `<linked-entity>-summary`
+- a free-text column the user drafts into → `draft-<that-thing>`
+
+For each action the user wants, design a real skill (not boilerplate) and call `create_board_skill`:
+- `name` — short, kebab-case, verb-led. `description` — one line in the user's words.
+- `prompt` — self-contained markdown: which MCP tools to call and in what order (read skills: `get_board` → filter → output; action skills: also `search`/`query`/`get_page` for context, `act_on_integration` to send; write-back: `update_board_row` after confirm), the exact output shape, and edge cases (empty set, missing column).
+- `allowed_tools` — the fully-namespaced tools the prompt calls.
+- `inputs_schema` — only if it takes runtime args (e.g. a `row_id`).
+If an action needs a column the schema lacks, say so and offer to extend the schema first — don't build a broken skill. Show the set as one bundle, build on go.
+
+## Step 7 — Dashboard (optional, skip silently if the default table is fine)
+
+Propose a custom view only on a clear fit; otherwise say nothing:
+- `stage`/`status` select → kanban grouped by it
+- a primary date on a time-ordered board → timeline
+- multiple numeric columns → chart
+
+If yes, use the **generate-dashboard skill**:
+
+1. Call `get_dashboard` first. It returns the authoring `skill` for THIS board — how the board's data reaches your document, the failures the platform reports no error for, and the bridge API — plus the board's current `mode` / `engine_version`. **Follow that skill exactly; it is authoritative for both the format and the `set_dashboard` call shape.**
+2. Author the dashboard following that skill. (Most boards are a complete, self-contained HTML document you design — no template, no required component library; some boards return a different engine, and the skill tells you which and how.)
+3. Call `set_dashboard` exactly as the skill instructs. **Pass `engine_version` only when the skill tells you to** — an engine that reported an `engine_version` requires you to echo it back; a plain HTML document passes none. If `get_dashboard` reported `mode: "generate"` (no dashboard yet) this is a FIRST write — no `replace_existing` needed; pass `replace_existing: true` only when deliberately replacing an existing dashboard wholesale.
+
+If this board's datasets are large or expected to grow (thousands of rows), or the dashboard mostly shows aggregates over many rows, also pass `data_loading: "on_demand"` — the document then carries only the datasets' structure and the dashboard reads the slices it renders through the bridge, instead of baking every row in. Leave it off (the `"inline"` default) for small, bounded boards.
+
+**Decide these two while you're designing the view, not after.**
+
+- **Deep links — if the view has a place, put it in the URL.** If the dashboard has state a user would expect to survive a refresh or want to share — an open record, the active tab, a filter — reflect it with the `dashboard.url_state` bridge op and read it back from `location.search` on boot. Without it, a refresh or a shared link drops the viewer back on the top-level view; that is today's default and it is almost never what anyone wants. Full contract (params REPLACE the whole query, the limits, replace vs push) is in the `set_dashboard` description.
+- **On-demand reads get shed under load — plan for it.** `board.rows.query` is rate-limited AND concurrency-gated per viewer, so a shed is normal, not an error: retry transient sheds with backoff on your own schedule, and never present a total computed over partially-loaded rows — mark the view incomplete instead. Mechanics, including the `status`-less local denial that a naive check reads as fatal, are in `set_dashboard`'s HANDLING A SHED READ section.
+
+**You own the runtime half.** Because you author the document, nothing wires shed handling, partial-data honesty or deep links for you — build them into the page. Both matter only if you reached for `data_loading: "on_demand"`; an inline board arrives complete.
+
+**About `replace_existing`:** when `create_board` seeded a small default dashboard at Step 4, your document shares none of its structure, so `set_dashboard`'s additive guard reads the write as a rewrite and REFUSES it — pass `replace_existing: true` to replace that auto-seeded default with the real dashboard. That guard is correct (it stops agents blowing away a dashboard someone built), and replacing the freshly-seeded default is the one legitimate override. If instead the board had NO dashboard yet — `get_dashboard` returned `mode: "generate"` — it's a first write and needs no override at all.
+
+Use the `dashboard_url` it returns verbatim; don't construct the URL yourself. **This override is only for the freshly-seeded default.** Editing a dashboard that already has real content is an *additive* job — read it with `get_dashboard` and send a focused `edits` patch or a `section_id` splice, never a full `replace_existing` rewrite.
+
+## Step 8 — Wrap
+
+> "Done.
+> - Board: `<board_url>`
+> - Source: `<GitHub sync agent / seeded from Gmail / manual>`
+> - Dashboard: `<dashboard_url>` *(live once you author it in Step 7; if you skipped Step 7 and a default table was seeded, that's live too)*
+> - Skills: `<names>` *(only if Step 6 ran)*
+>
+> Add rows in the UI or run a skill. Ask me any time to extend the schema, wire a different source, add skills, or seed more."
+
+Stop there — don't recap the steps or volunteer follow-ups. The user can see what was built.
diff --git a/plugins/brains/skills/brains-build/SKILL.md b/plugins/brains/skills/brains-build/SKILL.md
index ea680bf..65b4feb 100644
--- a/plugins/brains/skills/brains-build/SKILL.md
+++ b/plugins/brains/skills/brains-build/SKILL.md
@@ -1,6 +1,6 @@
 ---
-name: brains-build
-description: The catalog of what brains can do beyond search — board, board skill, bulk upload, dashboard, page, automation, recurring brief / digest, workflow, mini-site, board source link, dataset recipe, integrations, telegram bot. Use when the user asks "what can brains do", asks how to do X in brains, or describes a shape one of these fits. They might say "track a list of…", "every morning do…", "build me a deck…". Routes to the tool, flow or skill that owns it.
+name: "brains-build"
+description: "The inventory of what brains can do beyond search. Use when the user asks \"what can brains do\", \"can brains do\", \"what else can brains do\" — a capability question, not a request to build one. Yields to brains-board / brains-automation / brains-workflow the moment they want one made. Answers name the feature and route to whatever owns it."
 ---
 
 <!-- Generated by ssvlabs/brains apps/mcp/scripts/generate-capability-catalog.ts.
@@ -18,7 +18,7 @@ Don't restate that artifact here — open it.
 | **Bulk upload** | Load a large or arbitrary-format file into a board without reading it into context. | `create_import_grant` → `bulk_append_rows` |
 | **Dashboard** | A live, interactive view of a board that you author as a full HTML app. | `get_dashboard` → `set_dashboard` |
 | **Page** | A first-class note in a brain. | `create_page` |
-| **Automation** | A sandboxed TS program on a cron schedule with a scoped token. | `create_automation_flow` if your client exposes it (follow the playbook it returns), otherwise the Automations page (`/automations`) |
+| **Automation** | A sandboxed TS program on a cron schedule with a scoped token. | `create_automation_flow` if your client exposes it (follow the playbook it returns), otherwise the Agents page (`/agents`) |
 | **Recurring brief / digest** | Install a prebuilt automation that sends a recurring summary instead of scaffolding one. | `list_recipes` → `install_recipe` |
 | **Workflow** | A goal container: charter, KPIs, deadlines, roster, an owned board and template automations. | `create_workflow_flow` if your client exposes it (follow the playbook it returns), otherwise `create_workflow` |
 | **Mini-site** | Static sandboxed HTML on a brain — a deck, a one-pager, a shareable link. | `create_mini_site` |
diff --git a/plugins/brains/skills/brains-workflow/SKILL.md b/plugins/brains/skills/brains-workflow/SKILL.md
new file mode 100644
index 0000000..5172889
--- /dev/null
+++ b/plugins/brains/skills/brains-workflow/SKILL.md
@@ -0,0 +1,178 @@
+---
+name: "brains-workflow"
+description: "Set up a workflow — a goal container with KPIs, deadlines, a roster of brains users, its own board and template agents that track progress. Use when the user is organising a project rather than a list: \"ship X by Q3\", \"coordinate this initiative\", \"set up a project with KPIs and a team\". A plain board is the simpler answer for tracking alone."
+---
+
+<!-- Generated by ssvlabs/brains apps/mcp/scripts/generate-capability-catalog.ts.
+     Source: the authoring procedure catalog. Do not hand-edit. -->
+
+# Create-workflow flow — run this with the user
+
+You're guiding the user through scaffolding a **workflow**: a goal-shaped container with KPIs, deadlines, a roster of brains users, an owned board, and a set of template agents that track progress, nudge people, and review milestones. The workflow is created **active** by default — attached agents start firing on their crons immediately.
+
+A workflow is more than a board — it's the whole project around it. When the user deletes the workflow, its board and agents go with it.
+
+Walk the user through these steps. **One question per turn.** Do not skip ahead. Do not call `create_workflow` until Step 7 confirms structure.
+
+---
+
+## Flow state — one line, every turn
+
+End EVERY message in this flow with a checkpoint (last line, above any chips), so a later turn
+can pick up where you left off:
+
+`FLOW workflow · step 1/10 purpose · done: (none) · facts: (none) · next: the user's answer to the question above`
+
+Steps in order: `purpose`, `kpis`, `deadlines`, `roster`, `inputs`, `templates`, `confirm`, `provision`, `smoke_test`, `handoff`. Write `(none)` in a segment that has nothing yet.
+When the flow is finished emit `FLOW workflow · done` instead, or
+`FLOW workflow · cancelled` if the user drops it — without that,
+the flow looks live forever.
+
+`done:` records what you have already CREATED, with the id the call returned — `workflow_id=…`. Write it there the moment the call comes back. It is the only record that survives: a confirmation means the user said yes, not that the write happened.
+
+`facts:` carries the decisions you cannot re-read from the conversation — `templates`. Keep each one short.
+
+**Picking up a flow already in progress:**
+
+1. **Before creating anything, check whether you already did.** If the last checkpoint names an
+   effect for the step you are about to run, that artifact exists — look it up by its id, tell the
+   user, and continue from the next step. Never create a second one.
+2. Checkpoint present and readable → carry on from the step it names.
+3. Checkpoint garbled → re-emit a corrected one from what you can see, then carry on.
+4. No checkpoint but you still have this procedure → work out where you are from the
+   conversation, say in one line where you are resuming, and confirm before any write.
+5. No checkpoint and no procedure → do not improvise the steps; the gates in here are not
+   optional. The one exception: if the user asks to pick a flow back up and you no longer have its procedure in front of you, reload it once — then continue from the last checkpoint rather than starting over. Never re-fetch one you can still see.
+6. Nothing recoverable → start over, but collect everything in ONE question instead of walking
+   the whole interview again.
+
+## Step 1 — Purpose & success
+
+If a `purpose_hint` came in, echo it back as your understanding ("So you want a workflow for X — is that right?") and skip cold-asking.
+
+Otherwise: ask what the workflow is trying to achieve. One sentence.
+
+## Step 2 — KPIs
+
+Ask: what measurable signals tell the user this workflow is succeeding? 1–4 KPIs. For each: a name, a target value, optional unit, optional deadline.
+
+Examples:
+- `{ name: "signed customers", target: 5, deadline: "2026-08-01" }`
+- `{ name: "NPS", target: 50, unit: "score" }`
+
+Don't accept fuzzy goals as KPIs — push back if the user says "engagement" without a number.
+
+## Step 3 — Deadlines & milestones
+
+Ask: hard end-date + any intermediate beats (milestones). At least the end-date.
+
+Format: `[{ label, date: "YYYY-MM-DD" }]`.
+
+## Step 4 — Roster
+
+Ask: who's involved, by role. Roles: `owner` (you), `contributor` (does work), `observer` (gets digests, no nudges).
+
+Every roster member must be a **brains user** — look them up with `whoami` for the caller, and ask the user for emails/handles of the others. If a named person isn't yet a brains user, say so plainly ("X isn't on brains — invite them first, or skip them for now") and continue without them.
+
+Resolve each member to a `user_id` (UUID) before moving on. Look up via the explicit user roster (whoami / brains user search) if you have it.
+
+## Step 5 — Inputs (auto-detect, then confirm)
+
+**Do not ask cold.** First, infer the workflow's domain from the purpose + KPIs (product? sales? hiring? research?). Then:
+
+1. Call `list_integrations` and pick 0–3 that fit the domain. Examples:
+   - product / engineering workflows → `github`
+   - sales / CRM workflows → `gmail`, `calendar`
+   - research / planning → `drive`
+2. Call `list_boards` and pick 0–3 by name match against the purpose.
+
+Then say: *"Based on what you're shipping, I think these are relevant: <integrations + boards>. Want me to add anything else, or remove any?"* Skip the question entirely if nothing turned up.
+
+Collected names + ids go on the charter as context, not as wiring.
+
+## Step 6 — Recommend templates (assertive)
+
+**Do not enumerate-and-ask.** Recommend all three by default. Say something like:
+
+> *"I'll attach all three templates: **progress_scorer** (daily % to KPI), **task_nudger** (daily due-soon digest pushed to your Telegram bot), and **milestone_reviewer** (Friday LLM recap). Speak up if you want to drop any or tweak crons — otherwise defaults."*
+
+The three v1 templates + defaults:
+
+1. **progress_scorer** — `0 9 * * *`, slip_threshold_pct=50.
+2. **task_nudger** — `0 8 * * *`, window_hours=24.
+3. **milestone_reviewer** — `0 18 * * 5`.
+
+Each template gets saved as an **active** agent owned by this workflow — its cron starts firing as soon as the workflow is created. Only ask granular questions if the user pushes back. Otherwise move on.
+
+## Step 7 — Confirm proposed structure
+
+Show the user a tight summary:
+
+```
+Workflow: <title>
+  Charter: <one line>
+  KPIs: <count> — <names>
+  Deadlines: <end-date> (+ N milestones)
+  Roster: <count> people — <owner>, <names>
+  Owned board: "<title> — tasks"
+  Owned dashboard: progress + tasks (auto-provisioned)
+  Agents to attach: <selected templates>
+```
+
+Ask: "Look good? I'll create it active — attached agents start firing on their crons immediately. You can flip it to paused from /workflows/<id> if you want to halt them." Wait for explicit yes.
+
+## Step 8 — Provision (single call)
+
+When the user says yes, call `create_workflow` ONCE with:
+
+```
+title, charter, kpis, deadlines, roster,
+automation_templates: [{ template_id: "...", params: { ... } }, ...]
+```
+
+The tool creates, in one transaction: the workflow row (status=active), the owned board (with a "tasks" dataset), a **default progress dashboard** attached to that board, and one agent row per selected template (state=active, workflow_id set, source rendered from the template + params). Returns `workflow_id` + `board_id` + `automation_ids` (array, one per attached template) + `workflow_url` + `dashboard_url`.
+
+Do NOT hand off to the user yet — Step 8.5 must run first.
+
+## Step 8.5 — Smoke test every attached agent (mandatory)
+
+A template that renders cleanly is not the same as a template that runs cleanly. Render-time substitution can still produce source that fails on a missing tool grant, a board row shape the template assumed, an empty roster the cron summary crashes on, or a typo in a field name. **Never tell the user the workflow is ready until each attached agent has actually executed once.** Templates are not exempt — they're more likely to silently break than hand-written source, because the user never read them.
+
+For each `automation_id` returned by `create_workflow`, call `run_automation_once` with:
+
+- `automation_id` — the id from the array
+- `dry_run: true` — execute the source against a real trigger payload but suppress outbound writes; same hook as the admin Dry-Run button
+
+The tool enqueues a `trigger_kind='manual'` run and polls `automation_runs` until it terminates or `wait_seconds` elapses (default `max_wall_seconds + 90`). Run them sequentially so failures are easy to attribute; do NOT fan out in parallel.
+
+Read each result:
+
+| `status` | What to do |
+|---|---|
+| `succeeded` | Note one line of `stdout` to confirm intent (e.g. *"progress_scorer: scored 0/4 KPIs, no slip"*). Continue. |
+| `partial` | Exit 0 but stderr non-empty — the template caught errors and kept going. Treat as a failure for smoke-test purposes: show the user the `stderr` tail, patch via `update_automation` (usually a retry/backoff around the failing call), and re-run. Don't continue until it goes fully green. |
+| `failed` / `killed` | Show the user the `error` field + tail of `stderr`. Common shapes: tool-grant mismatch (`tool 'X' not in grants`), empty roster (`Cannot read properties of undefined`), missing field on the freshly-created board. Patch via `update_automation` and re-run `run_automation_once`. Two failures on the same agent → stop and ask the user how to proceed, don't guess a third fix. |
+| `skipped` | Source bailed early (e.g. *"no tasks due in window"* for task_nudger on a brand-new workflow with zero tasks). Expected for an empty workflow; confirm with the user that the skip reason matches the trigger payload that fired, then continue. |
+| `queued` / `running` (timed out — `timed_out: true`) | Run didn't reach a terminal status before `wait_seconds`. The response carries `timeout_reason` + a `next_step` line — **surface `next_step` verbatim** for this template (don't roll your own triage table) and continue. Don't claim success. |
+
+After every agent has been smoke-tested, write a one-line summary per template before moving on, e.g.:
+
+> *"Smoke test results — progress_scorer ✅ succeeded, task_nudger ⏭ skipped (no tasks yet, expected), milestone_reviewer ✅ succeeded."*
+
+If any smoke test failed and could not be patched, the workflow is NOT ready. Tell the user which template is broken and that the workflow's status flip will fire a broken agent on its cron. Do not paper over it.
+
+## Step 9 — Hand off
+
+Only after Step 8.5 is complete: hand the user the `workflow_url` and `dashboard_url`. Tell them the workflow is **active** — attached agents are already firing on their crons. They can flip it to paused from /workflows/<id> if they need to halt them. Surface the smoke-test summary one more time so they know which templates were validated and which were skipped.
+
+## Hard rules
+
+- **One question per turn.** No bundling.
+- **Roster is brains-users-only.** Do not invent a fallback to gmail.
+- **KPIs need numbers.** Don't accept vibe-goals.
+- **Auto-detect Step 5.** Do not ask "any integrations or boards?" cold — call `list_integrations` + `list_boards` first, then confirm a curated list.
+- **Be assertive on templates.** Recommend all three; do not enumerate-and-ask unless the user pushes back.
+- **Every workflow has a dashboard.** It's mandatory — `create_workflow` always provisions one.
+- **Always end in a single `create_workflow` call.** Do not try to wire agents, boards, or dashboards manually — the tool handles provisioning.
+- **Templates only.** No hand-rolled agent source in this flow — that's what create_automation_flow is for.
+- **Smoke-test every attached agent before hand-off.** Step 8.5 is mandatory; a "template" agent can fail at runtime exactly like a hand-rolled one, and the user has not read the rendered source. Don't claim a workflow is ready until every attached agent has executed once.
diff --git a/plugins/brains/skills/brains-write/SKILL.md b/plugins/brains/skills/brains-write/SKILL.md
index e8f4e6f..4be3069 100644
--- a/plugins/brains/skills/brains-write/SKILL.md
+++ b/plugins/brains/skills/brains-write/SKILL.md
@@ -1,6 +1,6 @@
 ---
-name: brains-write
-description: How to take ACTIONS on the user's integrations through brains — send an email, create a calendar event, make a Drive doc, comment on a Monday item, run a live Gmail search, post a message. Use whenever the user wants to send/create/reply/forward/mark/schedule something, or "message/ping/DM" someone. Covers the codex action flow and the draft→confirm gate.
+name: "brains-write"
+description: "How to take ACTIONS on the user's integrations through brains — send an email, create a calendar event, make a Drive doc, comment on a Monday item, run a live Gmail search, post a message. Use whenever the user wants to send/create/reply/forward/mark/schedule something, or \"message/ping/DM\" someone. Covers the codex action flow and the draft→confirm gate."
 ---
 
 <!-- Generated by ssvlabs/brains apps/mcp/scripts/generate-capability-catalog.ts.
diff --git a/tests/plugin-contract/run.ts b/tests/plugin-contract/run.ts
index 6a521b1..17b0589 100644
--- a/tests/plugin-contract/run.ts
+++ b/tests/plugin-contract/run.ts
@@ -773,9 +773,13 @@ const readme = readFileSync(join(ROOT, "README.md"), "utf8");
 const core = readFileSync(join(PLUGIN, "core.md"), "utf8");
 const writeSkill = readFileSync(join(PLUGIN, "skills", "brains-write", "SKILL.md"), "utf8");
 const buildSkill = readFileSync(join(PLUGIN, "skills", "brains-build", "SKILL.md"), "utf8");
+const boardSkill = readFileSync(join(PLUGIN, "skills", "brains-board", "SKILL.md"), "utf8");
+const automationSkill = readFileSync(join(PLUGIN, "skills", "brains-automation", "SKILL.md"), "utf8");
+const workflowSkill = readFileSync(join(PLUGIN, "skills", "brains-workflow", "SKILL.md"), "utf8");
 const capabilityManifest = readJson(join(PLUGIN, "generated", "capability-catalog.json"));
 const coreNormalized = core.replace(/\s+/g, " ");
 const writeSkillNormalized = writeSkill.replace(/\s+/g, " ");
+const automationSkillNormalized = automationSkill.replace(/\s+/g, " ");
 
 assert(claudeManifest.name === "brains", "Claude manifest name must be brains");
 assert(codexManifest.name === "brains", "Codex manifest name must be brains");
@@ -1430,11 +1434,14 @@ assert(
 const LOCAL_ARTIFACT: Record<string, string> = {
   "plugins/brains/skills/brains-write/SKILL.md": writeSkill,
   "plugins/brains/skills/brains-build/SKILL.md": buildSkill,
+  "plugins/brains/skills/brains-board/SKILL.md": boardSkill,
+  "plugins/brains/skills/brains-automation/SKILL.md": automationSkill,
+  "plugins/brains/skills/brains-workflow/SKILL.md": workflowSkill,
 };
 assert(Array.isArray(capabilityManifest.artifacts), "manifest must carry an artifacts array");
 assert(
   capabilityManifest.artifacts.map((a: any) => a.capability_id).sort().join(",") ===
-    "brains-features,integration-actions",
+    "brains-features,integration-actions,procedure:automation,procedure:board,procedure:workflow",
   "published capability set mismatch",
 );
 for (const entry of capabilityManifest.artifacts) {
@@ -1449,50 +1456,126 @@ for (const entry of capabilityManifest.artifacts) {
     body!.includes("Do not hand-edit"),
     `generated artifact is missing its do-not-hand-edit header: ${entry.artifact_path}`,
   );
+  // Internal CODE identifiers, which a published skill can never have a reason to
+  // name: a cross-tenant DB pool, a board-form-queries column, an import-grants
+  // column. None appears in any published artifact today, which is what makes the
+  // denylist shape work here.
+  //
+  // `automation_secret` and `telegram_push` used to be on this list and were
+  // REMOVED, deliberately. They are registered MCP tools —
+  // apps/mcp/src/tools/automation.ts (automation_secret_list / _get / _set) and
+  // apps/mcp/src/tools/telegram-push.ts — so the list was conflating internal
+  // identifiers with user-facing tool names, and naming tools is precisely a
+  // public skill's job. The ban was invisible only because the sole published
+  // artifacts predated the automation authoring skill; the moment that skill
+  // shipped, the ban failed a CORRECT artifact and would have been "fixed" by
+  // stripping its secret-hygiene guidance. Do not re-add either name. What those
+  // two were reaching for is asserted positively instead, below.
   assert(
-    !/automation_secret|adminPool|handler_source|telegram_push|grant_token/.test(body!),
+    !/adminPool|handler_source|grant_token/.test(body!),
     `public skill leaked an internal-only capability: ${entry.artifact_path}`,
   );
 }
 
 // Eager skill-metadata budget (skills authoring & discovery contract §3): the
 // CLI hosts preload EVERY installed skill's name + description for routing, so
-// skill count is a budget, not a detail. Education was deliberately rendered
-// INTO brains-build rather than added as an eighth skill; pin the count so a
-// future addition is a reviewed act, not a silent one.
+// skill count is a budget, not a detail. Two decisions live behind this pin, and
+// both are still in force:
+//
+//   1. Education was deliberately rendered INTO brains-build rather than added as
+//      its own skill. Unchanged — brains-build is still one skill carrying the
+//      whole feature inventory.
+//   2. The three authoring procedures ARE separate skills. That is the *_flow
+//      playbook migration: a procedure the model must follow turn-by-turn has to
+//      be routable on its own trigger vocabulary, which is exactly what an eager
+//      description buys. Folding them into brains-build would have made one
+//      description claim both "what can brains do" and every build phrase — the
+//      routing collision the disjointness check below exists to forbid.
+//
+// So the budget rule was not abandoned when this went from seven names to ten; it
+// was spent, deliberately, on the three procedures. The pin's purpose is that a
+// future addition is a reviewed act and not a silent one, and it did its job here:
+// this list changing is what forced that review.
 const skillDirs = readdirSync(join(PLUGIN, "skills"), { withFileTypes: true })
   .filter((e) => e.isDirectory())
   .map((e) => e.name)
   .sort();
 assert(
   skillDirs.join(",") ===
-    "brains-agenda,brains-build,brains-feedback,brains-integrations,brains-nudges,brains-read,brains-write",
+    "brains-agenda,brains-automation,brains-board,brains-build,brains-feedback," +
+      "brains-integrations,brains-nudges,brains-read,brains-workflow,brains-write",
   `skill set changed (${skillDirs.join(", ")}) — see the eager-budget rule before adding one`,
 );
 
 // Cross-skill trigger disjointness (§1: triggers must be mutually distinct).
 // This lives HERE and not in the monorepo generator on purpose: the sibling
 // SKILL.md bodies exist only in this repo, so an assertion there would have no
-// inputs and pass forever. brains-build's rendered description samples authored
-// trigger phrases verbatim; none may be claimed by another skill's description.
-const SAMPLED_TRIGGERS = ["track a list of", "every morning do", "build me a deck"];
-const buildDescription = /^description:\s*(.+)$/m.exec(buildSkill)?.[1] ?? "";
-for (const trigger of SAMPLED_TRIGGERS) {
-  assert(
-    buildDescription.toLowerCase().includes(trigger),
-    `brains-build no longer samples the trigger "${trigger}" — regenerate from the monorepo catalog`,
-  );
-  for (const dir of skillDirs) {
-    if (dir === "brains-build") continue;
-    const sibling = readFileSync(join(PLUGIN, "skills", dir, "SKILL.md"), "utf8");
-    const siblingDescription = /^description:\s*(.+)$/m.exec(sibling)?.[1] ?? "";
+// inputs and pass forever.
+//
+// It used to sample three phrases from brains-build's description and require no
+// sibling to claim them. That inverted when the procedures became skills:
+// brains-build no longer advertises build vocabulary at all, it DISCLAIMS it
+// ("Yields to brains-board / brains-automation / brains-workflow"), so the old
+// check would fail in both directions at once — brains-build missing the phrases
+// it no longer wants, and brains-board/-automation legitimately owning them.
+//
+// The property that actually matters is ownership: each phrase routes to exactly
+// one skill. So pin an owner per phrase and sweep every other description,
+// brains-build INCLUDED — pinning the yield is the point, since re-claiming a
+// build phrase there is the specific regression the recut exists to prevent.
+// Phrases are the authored `triggers` arrays in the monorepo's
+// packages/capability-catalog/procedure-catalog.ts. brains-build's are NOT from a
+// triggers array: they are the literal inventory phrases in
+// render-features.ts:renderSkillDescription, education's own vocabulary, none of
+// which is a doing verb.
+const TRIGGER_OWNERS: Record<string, readonly string[]> = {
+  "brains-board": ["track a list of", "keep a table of", "build a tracker", "build a CRM", "log every"],
+  "brains-automation": [
+    "automate this",
+    "every morning do",
+    "run this nightly",
+    "auto-draft when",
+    "when an email from",
+  ],
+  "brains-workflow": ["ship X by", "coordinate this initiative", "set up a project with KPIs and a team"],
+  "brains-build": ["what can brains do", "can brains do", "what else can brains do"],
+};
+const descriptionOf = (dir: string): string => {
+  const body = readFileSync(join(PLUGIN, "skills", dir, "SKILL.md"), "utf8");
+  return (/^description:\s*(.+)$/m.exec(body)?.[1] ?? "").toLowerCase();
+};
+const DESCRIPTIONS = new Map(skillDirs.map((dir) => [dir, descriptionOf(dir)]));
+for (const [owner, triggers] of Object.entries(TRIGGER_OWNERS)) {
+  const ownerDescription = DESCRIPTIONS.get(owner);
+  assert(ownerDescription !== undefined, `trigger owner ${owner} is not an installed skill`);
+  for (const trigger of triggers) {
+    const phrase = trigger.toLowerCase();
     assert(
-      !siblingDescription.toLowerCase().includes(trigger),
-      `trigger "${trigger}" is claimed by both brains-build and ${dir} — routing collision`,
+      ownerDescription!.includes(phrase),
+      `${owner} no longer advertises its own trigger "${trigger}" — regenerate from the monorepo catalog`,
     );
+    for (const [dir, description] of DESCRIPTIONS) {
+      if (dir === owner) continue;
+      assert(
+        !description.includes(phrase),
+        `trigger "${trigger}" is claimed by both ${owner} and ${dir} — routing collision`,
+      );
+    }
   }
 }
 
+// The yield, asserted positively. brains-build builds this clause from
+// PROCEDURE_SKILL_IDS (render-features.ts), so it names all three owners rather
+// than merely avoiding their phrases — a recut that dropped the hand-off while
+// keeping its own vocabulary clean would pass the sweep above and still leave a
+// user asking to build something with nowhere to be sent.
+for (const owner of ["brains-board", "brains-automation", "brains-workflow"]) {
+  assert(
+    DESCRIPTIONS.get("brains-build")!.includes(owner),
+    `brains-build must name ${owner} as the owner it yields to`,
+  );
+}
+
 // brains-build is the education face: it must POINT, not restate. It routes to
 // owners and must not carry another skill's procedure vocabulary.
 assert(
@@ -1571,6 +1654,38 @@ assert(writeSkillNormalized.includes("remains approvable"), "expired drafts must
 assert(writeSkillNormalized.includes("this tuple is the only call shape"), "source-only action fallback must stay prohibited");
 assert(!/act_on_integration[^.]{0,200}request=/.test(writeSkillNormalized), "free-form action request must not return");
 
+// Same treatment for brains-automation, and for the same reason: the digest proves
+// these bytes came from the catalog, not that the catalog kept the rails. Nothing
+// here would notice if a regeneration DELETED the secret-hygiene guidance — the
+// digest would move with it and every check above would stay green. These three are
+// the rails whose absence is a credential-exposure bug, one per distinct rule:
+// don't ask for a bot token, don't solicit a secret value while authoring, and
+// don't echo one back if the user pastes it anyway.
+//
+// Each pins an IMPERATIVE, not the prose explaining it. Rationale sentences get
+// reworded editorially and would red this build for no behavioral change; a
+// directive cannot be reworded without changing the rule.
+//
+// COUPLING, stated because it is load-bearing: these substrings live in a
+// generated artifact whose source is a different, PRIVATE repo, so an author
+// rewording the procedure reds a build in a public repo they may not know exists.
+// If that happens, the fix is to re-derive the rail in ssvlabs/brains at
+// packages/capability-catalog/procedures/create-automation.md and regenerate.
+// Never soften or delete the assertion here — that is the exact outcome it exists
+// to prevent.
+assert(
+  automationSkillNormalized.includes("Never ask the user to paste a Telegram bot token"),
+  "brains-automation lost the Telegram bot-token refusal",
+);
+assert(
+  automationSkillNormalized.includes("never solicit the value in chat"),
+  "brains-automation lost the rule against soliciting a secret value in chat",
+);
+assert(
+  automationSkillNormalized.includes("do NOT refuse and do NOT echo it back"),
+  "brains-automation lost the handling for a secret the user pasted anyway",
+);
+
 // This README is the install instructions for anyone who finds the repo directly rather than the
 // guided page, so it has to carry the same contract. It documented `export BRAINS_API_TOKEN` as the
 // way in long after that stopped being able to work, which is exactly the drift these pin.