notification-routing
Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding
Best use case
notification-routing is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding
Teams using notification-routing should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/notification-routing/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How notification-routing Compares
| Feature / Agent | notification-routing | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
## Context
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:**
- Important alerts missed because they're buried in routine notifications
- Team members turning off notifications entirely (signal overwhelm)
- Onboarding friction: "where do I look for X?"
## Patterns
### Channel Config Schema
Define a `.squad/teams-channels.json` (or equivalent) mapping notification types to channel identifiers:
```json
{
"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:
```json
{
"channels": {
"notifications": { "name": "squad-alerts", "id": "channel-id-opaque-string" }
}
}
```
### CHANNEL: Tag Convention
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
```
### Routing Dispatcher (shell pseudocode)
```bash
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"
}
```
### Provider-Agnostic Adapter
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.
## Anti-Patterns
**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.
## Distributed Systems Pattern
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.Related Skills
My Skill
No description provided.
rework-rate
Measure and interpret PR rework rate — the emerging 5th DORA metric
project-conventions
Core conventions and patterns for this codebase
tiered-memory
Three-tier agent memory model (hot/cold/wiki) for 20-55% context reduction per spawn
test-discipline
Update tests when changing APIs — no exceptions
Skill: Retro Enforcement
## Purpose
reflect
Learning capture system that extracts HIGH/MED/LOW confidence patterns from conversations to prevent repeating mistakes. Use after user corrections ("no", "wrong"), praise ("perfect", "exactly"), or when discovering edge cases. Complements .squad/agents/{agent}/history.md and .squad/decisions.md.
iterative-retrieval
Max-3-cycle protocol for agent sub-tasks with WHY context and coordinator validation. Use when spawning sub-agents to complete scoped work.
error-recovery
Standard recovery patterns for all squad agents. When something fails, adapt — don't just report the failure.
docs-standards
Microsoft Style Guide + Squad-specific documentation patterns
{skill-name}
{what this skill teaches agents}
versioning-policy
Semver versioning rules for Squad SDK and CLI — prevents prerelease version incidents