Ccc Broadcast

$ccc-broadcast — Outbound Status Relay

Placeholders like ~~chat and ~~email refer to connected tools. See CONNECTORS.md.

Turn "did the deploy work?", "is the site up?", and "did the overnight run finish?" into pushed status updates. ccc-broadcast watches the operational signals a CC Commander session already produces — builds, deploys, CI results, task completions, cost/budget alerts — and relays a plain-language summary to the channels a team actually reads (~~chat, ~~email). No dashboards to open, no terminal to babysit.

This is the outbound-status counterpart to $ccc-nightwatch (which relays approval requests to your phone). Nightwatch asks "can I do this?"; broadcast tells "here's what happened."

What it does

The skill maps CC Commander lifecycle events to a small set of business-legible messages and forwards them through whatever ~~chat or ~~email connector is enabled via $ccc-connect. Each relay is a short, scrubbed summary — event type, human outcome, and a link if one exists — never file contents, diffs, or secret values. Signals are classified by audience so engineers, owners, and clients each get the right altitude.

Triggers

• $ccc-broadcast
• "tell the team when the deploy finishes"
• "send me a status when the build is done"
• "broadcast ops updates to Slack"
• "let the client know when it's live"
• "team status updates"

Signal → Audience Matrix

Unclassified signals default to the 🗒️ digest (batched, low-noise).

Architecture

CC Commander session
       |
  [lifecycle signals]  ← Stop / TaskCompleted / deploy / CI hooks
       |
  [Audience Classifier]
       |
  ┌────┴───────────────┐
  |                     |
immediate            digest (batched)
  |                     |
[Scrubber] — strips file contents, diffs, secrets
  |                     |
  └──────── ~~chat / ~~email connector ────────┘
              (Slack · Teams · Discord · Gmail)

Setup

Step 1 — Choose your audience + channel

Run $ccc-broadcast setup and pick where updates go:

AskUserQuestion:
  question: "Where should status updates land?"
  options:
    - Team chat (~~chat — Slack / Teams / Discord)
    - Email digest (~~email — Gmail / Outlook)
    - Both (chat for incidents, email for the daily digest)
    - Log-only (no push — just an audit trail)

Step 2 — Connect a channel

Broadcast is tool-agnostic. Enable a ~~chat and/or ~~email connector once via $ccc-connect; broadcast uses whatever is configured there. No channel-specific credentials live in this skill.

Step 3 — Pick a noise level

AskUserQuestion:
  question: "How chatty should the broadcast be?"
  options:
    - Quiet (incidents + daily digest only)
    - Normal (ships, CI failures, task completions, cost alerts)
    - Verbose (every signal, real-time)

Step 4 — Verify

$ccc-broadcast test   # sends one sample message to each connected channel
$ccc-broadcast status # shows audience map, noise level, and last 5 relays

Concrete Examples

Example 1 — Solo founder, overnight build You kick off an overnight feature build and go to bed. At 2am the run finishes. Broadcast sends one ~~email: "✅ Checkout flow shipped — 6 files, tests green, deployed to staging. Review: ." No terminal, no dashboard.

Example 2 — Two-person team, deploy visibility A teammate pushes a fix. CI goes red. Broadcast posts to ~~chat immediately: "🔴 CI failed on fix/cart-total — 2 tests. ." When it goes green and deploys, a follow-up: "🟢 Live in production." Nobody had to ask.

Example 3 — Client-facing digest At 6pm broadcast compiles the day into one ~~email digest for the business owner: 3 ships, 1 incident (resolved), CI 94% green, spend $4.10 of $10 budget. Business-legible, no jargon, forwardable to a client as-is.

Tools Used

• Read — inspect broadcast config (audience map, noise level) and recent relay log
• Bash — read lifecycle signals, format payloads, invoke the connected channel
• AskUserQuestion — audience/channel picker and noise-level selection

Privacy Note

Every relay is scrubbed before it leaves the session. Broadcast sends event type + human-readable outcome + optional link only — never file contents, diffs, code snippets, env vars, or secret values. Example relay: "Deploy failed on main — build step, see CI log <link>" not the log body.

When NOT to Use

• Solo sessions where you're already watching the terminal — the relay overhead isn't worth it
• Highly regulated contexts where any outbound relay must route through an approved DLP gateway first
• One-off scripts with no team audience — there's no one to notify

Limitations

• Requires a ~~chat or ~~email connector enabled via $ccc-connect; log-only mode works with none
• Broadcast reflects only signals the session actually emits — it does not poll external infra on its own
• Digest batching means non-incident updates can lag up to the digest window
• Audience routing is a default heuristic; per-signal overrides are configured in ~/.claude/commander/broadcast.json
• Not a replacement for real monitoring/alerting (~~monitoring) — it relays your session's outcomes, not production health

⚙️ Fable contract: plan before build · verifier ≠ worker · prove before alarm · loops need gates · leave durable state — rules/fable-method.md

(On Codex, present these options as a numbered list and ask the user to reply with a number — AskUserQuestion is Claude-only.)