--- name: stadium-channel-routing description: Routing rules for Jim's and Pam's notifications — picks the right destination per project, decides when to @mention reviewers, formats deal-stage updates. Works over Slack OR the NeboLoop, chosen by the comm_backend setting. Use whenever a Stadium agent is about to post a notification. triggers: - slack routing - which channel - notify - notify slack - notify loop - per-project channel - reviewer mention metadata: version: "2.0.0" plugins: - name: slack version: ">=0.1.0" optional: true --- # Stadium Channel Routing Stadium uses a per-project channel pattern alongside a few firm-wide channels. Pick the right destination so each project has its own thread of history without spamming the firm-wide channels. ## Comm backend (Slack or NeboLoop) — read this first The destination platform is controlled by the **`comm_backend`** input (a setting): - **`slack`** (default) — post to Slack channels. Proactive posts go through the slack plugin's channel bridge: `plugin(resource: "slack", command: "post --channel --text [--thread_ts ]")`. (There is no `slack.messages.send` tool — never call that.) The agent must have the `slack` plugin enabled as a channel. - **`neboloop`** — post into the customer's NeboLoop. Proactive posts use the `loop` tool: `loop(resource: "channel", action: "send", channel_id: "", text: "")`, or `loop(resource: "dm", action: "send", to: "", text: "")`. Resolve channel UUIDs once via `loop(resource: "channel", action: "list")` and cache the name→UUID map. The agent must have comm enabled (the loop connection). No slack plugin is required in this mode. Everything below (per-project routing, firm-wide channels, @mention rules, quiet hours, formatting) is **backend-neutral** — it decides *which logical channel* and *what message*. The **Output contract** section at the end maps that to the right `slack`/`loop` call based on `comm_backend`. When the customer is loop-only, treat the `#channel` names below as logical names that map to loop channel UUIDs. ## Channel naming convention Per-project channels: `#site--mw` - `` is the project name lowercased, non-alphanumerics replaced with hyphens, trimmed - `` is the requested or planned MW capacity, integer - Example: project name `Okmulgee 400MW`, location `Okmulgee, OK` → `#site-okmulgee-400mw` - Example: project name `Chisholm`, MW 5300 → `#site-chisholm-5300mw` If a per-project channel doesn't yet exist in Slack, fall back to the firm-wide channel and include a `(no per-project channel)` suffix in the notification. ## Firm-wide channels | Channel | Purpose | When to post | |---------|---------|--------------| | `#ai-sites-intake` | All new inbound deals | Always for new intake records — even when a per-project channel exists | | `#ai-deal-digest` | Jim's daily 7am digest | Weekday mornings only | | `#ai-portfolio-flags` | Cross-project alerts (fatal flags, watchlist changes) | Any fatal-flag detection from Pam | | `#leadership` | Escalations | Pursue-grade verdict OR deal size > $50M | ## Routing decision flow When an agent needs to post a notification: 1. Look up the project by id or name (Monument `project get` via MCP). 2. Build the per-project channel slug per the convention above. 3. If the notification is about a NEW intake (no project yet exists): post to `#ai-sites-intake` only. 4. If the notification is about an EXISTING project: - Post the full payload to the per-project channel - Post a 1-line digest pointer to `#ai-sites-intake` linking back to the per-project thread 5. If the notification is a fatal-flag warning from Pam: ALSO cross-post a 1-line alert to `#ai-portfolio-flags` 6. If the verdict is pursue-grade: ALSO cross-post to `#leadership` with a 1-line recommendation Always include a link back to the project's Monument URL (`https://monument.sh/app/projects/`) so a click takes the reviewer to the full record. ## @mention rules Mention only when action is required. Don't mention for FYI updates. | Trigger | Mention | |---------|---------| | Pursue-grade verdict | The `{{reviewer_mention}}` input (typically `@shad`) | | Any fatal-flag warning | The `{{reviewer_mention}}` input | | Pending intake review queue > 5 items at daily digest time | The `{{reviewer_mention}}` input | | Watchlist deal materially improved on rescan | The `{{reviewer_mention}}` input | | Capital schedule shows near-term cash need > $1M not yet committed | The `{{reviewer_mention}}` input | | Generic project status digest | No mention | | Routine task creation by Jim | No mention | When `{{reviewer_mention}}` is empty, do not mention anyone; the bare notification still goes to the channel. ## Message formatting Use Slack mrkdwn. Always include: - A leading emoji that matches the event (🆕 intake, 🟢 pursue, 🟡 watchlist, 🔴 pass/fatal, 📊 digest, 💰 capital, ⚠️ flag) - The project name in **bold** - A 1-line summary - A bulleted detail list (max 3 bullets — anything more goes to the linked PDF/page) - A trailing link to the Monument project or the PDF report Example for a new high-score scouting report: ``` 🟢 *Okmulgee 400MW* — Preliminary view: controlled follow-up • POWER: workable — adjacent 345 kV; ESA executed • FIBER: promising — 2 diverse long-haul routes • LAWS & PERMITS: active gate — confirm ETJ/zoning before LOI · ``` Example for a fatal flag: ``` 🔴 *Monaca PA Site B* — Pass (fatal flag) ⚠️ Active DC moratorium ordinance in Beaver County (passed 2026-03-15, expires 2027-03-15) ``` ## Output contract Resolve one logical destination + message per channel hop, then emit the call for the active `comm_backend`. Make ONE call per channel — never bundle cross-posts. **`comm_backend = slack`** — post through the slack plugin's channel bridge: ``` plugin(resource: "slack", command: "post --channel #site-okmulgee-400mw --text \"\"") ``` - For a threaded reply (e.g. answering an @mention), add `--thread_ts ` from the inbound message. - To @mention a reviewer, include their Slack user id in the text as `<@U01234>`. - Do NOT call `slack.messages.send` (it does not exist). The slack plugin's CLI tools (`slack.messages`, `slack.channels`, `slack.search`) are read-only; real-time posting is only the bridge `post`/`reply` op shown above. **`comm_backend = neboloop`** — post with the `loop` tool: ``` loop(resource: "channel", action: "send", channel_id: "", text: "") ``` - Map the logical `#site-…` / firm-wide name to a loop channel UUID via `loop(resource:"channel", action:"list")` (cache the map). If no matching loop channel exists, fall back to a DM to the reviewer: `loop(resource:"dm", action:"send", to:"", text:"…")`. - @mentions in the loop are plain `@name` in the text. - Answering an inbound loop @mention needs no send call at all — the runtime auto-replies on the originating conversation; just produce the answer text. Keep the message body identical across backends — only the transport call differs. The per-project / firm-wide / @mention / quiet-hours decisions above apply unchanged to both. ## Rules - Never post the same payload to more than 3 channels (per-project, firm-wide intake, conditional alerts) - Never @here or @channel — only specific user mentions from the `{{reviewer_mention}}` input - Never post during quiet hours unless the event is a fatal flag or a pursue-grade verdict. Quiet hours default to 7pm–7am US/Eastern unless overridden via input. - Always include the Monument project link - Never include sensitive financial terms in the channel post — the PDF report holds those, behind app permissions

stadium-channel-routing

About this skill