Design notification routing that sends agent messages to channels by topic, such as security, releases, or daily digests. Use shared configuration and message tags to keep important alerts visible among routine updates.
Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding
Review the instructions the agent will receive before you install.
When a Squad grows beyond a few agents, notifications flood a single channel — failure alerts drown in daily briefings, tech news buries security findings, and everything gets ignored. This is the pub-sub problem: a single message queue for everything is a recipe for missed alerts.
The fix is topic-based routing: agents tag notifications with a channel type, and a routing function sends them to the appropriate destination.
Trigger symptoms:
Define a .squad/teams-channels.json (or equivalent) mapping notification types to channel identifiers:
{
"teamId": "your-team-id",
"channels": {
"notifications": "squad-alerts",
"tech-news": "tech-news",
"security": "security-findings",
"releases": "release-announcements",
"daily-digest": "daily-digest"
}
}
Place this in .squad/ (git-tracked, shared across the team). For platforms that use channel IDs instead of
names (Teams, Slack), store the resolved ID alongside the name to avoid name-collision bugs:
{
"channels": {
"notifications": { "name": "squad-alerts", "id": "channel-id-opaque-string" }
}
}
Agents prefix their output with CHANNEL:<type> to signal where the notification should go:
CHANNEL:security
Worf found 3 new CVEs in dependency scan: lodash@4.17.15, minimist@1.2.5
dispatch_notification() {
local raw_output="$1"
local channel="notifications" # default
if echo "$raw_output" | grep -qE '^CHANNEL:[a-z][a-z0-9-]*'; then
channel=$(echo "$raw_output" | head -1 | cut -d: -f2)
raw_output=$(echo "$raw_output" | tail -n +2)
fi
send_notification --channel "$channel" --message "$raw_output"
}
The routing layer is provider-agnostic. Plug in your platform adapter:
.squad/notify-adapter.sh # Teams / Slack / Discord / webhook -- swappable
The routing config and CHANNEL: tags never change. Only the adapter changes per deployment.
Never send all notification types to one channel:
send_notification --channel "general" --message "$anything"
Never use display names as identifiers (name collision risk):
send_to_team --name "Squad" --channel "notifications"
Resolve channel IDs once at setup. Use IDs at runtime.
This is pub-sub with topic routing -- the same principle as Kafka topics, RabbitMQ routing keys, and AWS SNS topic filtering. Route by type. Each consumer subscribes to the topics it cares about.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Coordinate work across AI agents with shared rules for locating team files, recording decisions and their reasons, and requesting help. It also defines who owns revisions after a reviewer rejects an artifact.
Set shared development rules for an agent team: keep specific agent names out of product code, tests, and CI configuration, verify affected tests before finishing, and record lessons learned from mistakes.
Routes requests to design, create, update, debug, or upgrade GitHub Agentic Workflows to the appropriate instructions. It helps the agent select a workflow-specific procedure and apply any additional rules defined for the repository.
Prepare architecture proposals before implementation so the team can agree on a direction. Organize evidence, technical choices, effects on existing work, risks, and the first release’s scope into a document with clear recommendations and decision owners.
Update the gh-aw-firewall version used by gh-aw, rebuild generated files, and review release notes and configuration schemas, which define valid settings. It guides related code and test updates while identifying follow-up work that remains.
Review git and gh operations in gh-aw workflows to check credential availability for each repository. Identify missing token handoffs, risky expansions of limited checkouts, and error handling needed where credentials are intentionally unavailable.