Standard collaboration patterns for all squad agents — worktree awareness, decisions, cross-agent communication
日本語の概要は準備中です。原文の説明を表示しています。
Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Standard collaboration patterns for all squad agents — worktree awareness, decisions, cross-agent communication
日本語の概要は準備中です。原文の説明を表示しています。
Shared hard rules enforced across all squad agents
日本語の概要は準備中です。原文の説明を表示しています。
Route gh-aw design, creation, diagnosis, patching, active debugging, and upgrade requests to the right strategies.
日本語の概要は準備中です。原文の説明を表示しています。
How to write comprehensive architectural proposals that drive alignment before code is written
日本語の概要は準備中です。原文の説明を表示しています。
Upgrade gh-aw to latest gh-aw-firewall release and identify follow-up spec tasks.
日本語の概要は準備中です。原文の説明を表示しています。
Review code that performs git or gh operations against repository checkouts in gh-aw, checking that the right credentials are available at the right time and that sparseness, shallowness and credential-free factors are properly considered.
日本語の概要は準備中です。原文の説明を表示しています。