diff options
| -rw-r--r-- | .ai/workflows/cross-project-broadcast.org | 15 | ||||
| -rw-r--r-- | claude-templates/.ai/workflows/cross-project-broadcast.org | 15 |
2 files changed, 28 insertions, 2 deletions
diff --git a/.ai/workflows/cross-project-broadcast.org b/.ai/workflows/cross-project-broadcast.org index 3a6294c..63af84f 100644 --- a/.ai/workflows/cross-project-broadcast.org +++ b/.ai/workflows/cross-project-broadcast.org @@ -25,7 +25,20 @@ Automatic invocation: - *Project-specific work.* A handoff intended for one project goes through =inbox-send= directly, not broadcast. - *Routine status updates.* The session log and todo.org cover routine work. Broadcast is for capability- or rule-level changes. -- *Bulk noise.* Every broadcast adds N inbox files. Use sparingly; ask whether projects actually need to know. +- *Bulk noise.* Every broadcast adds N inbox files. Use sparingly. Ask whether projects actually need to know. +- *Every commit.* Most commits are project-internal hygiene (audit, intake, TODO updates) that the other projects don't care about. Even cross-project workflow updates rsync into every project's =.ai/= at next startup, so the capability lands without a broadcast. Broadcast only when projects need to *act* on the change (use a new tool, migrate before a deprecation, change their behavior per a new rule). Resist the urge to fan out a "here's what shipped today" digest. The startup rsync already carries the bits; the broadcast carries the *attention*, and attention is the costly resource. + +* Cadence Guideline + +Broadcasts are capability-and-rule-level events, not commit-level events. A reasonable cadence is one to four broadcasts per month, depending on what landed. Five reasons for the restraint: + +1. Each broadcast costs N inbox processings across the fleet (currently ~23 targets). Daily broadcasts mean daily noise. +2. Most commits are project-internal. Other projects do not need to read about another project's TODO sweeps, audit passes, or hygiene work. +3. The startup rsync already does the capability work. Broadcasts add awareness, not availability. +4. Aggregation wins. One weekly "here's what shipped" digest beats ten per-commit pings on every dimension. Fewer inbox files, easier to skim, easier to defer reading. +5. Per-commit broadcasts train projects to ignore inbox. Then a real handoff gets missed. + +If a session ships several broadcastable changes, bundle them into one broadcast at session end rather than firing one per commit. * The Workflow diff --git a/claude-templates/.ai/workflows/cross-project-broadcast.org b/claude-templates/.ai/workflows/cross-project-broadcast.org index 3a6294c..63af84f 100644 --- a/claude-templates/.ai/workflows/cross-project-broadcast.org +++ b/claude-templates/.ai/workflows/cross-project-broadcast.org @@ -25,7 +25,20 @@ Automatic invocation: - *Project-specific work.* A handoff intended for one project goes through =inbox-send= directly, not broadcast. - *Routine status updates.* The session log and todo.org cover routine work. Broadcast is for capability- or rule-level changes. -- *Bulk noise.* Every broadcast adds N inbox files. Use sparingly; ask whether projects actually need to know. +- *Bulk noise.* Every broadcast adds N inbox files. Use sparingly. Ask whether projects actually need to know. +- *Every commit.* Most commits are project-internal hygiene (audit, intake, TODO updates) that the other projects don't care about. Even cross-project workflow updates rsync into every project's =.ai/= at next startup, so the capability lands without a broadcast. Broadcast only when projects need to *act* on the change (use a new tool, migrate before a deprecation, change their behavior per a new rule). Resist the urge to fan out a "here's what shipped today" digest. The startup rsync already carries the bits; the broadcast carries the *attention*, and attention is the costly resource. + +* Cadence Guideline + +Broadcasts are capability-and-rule-level events, not commit-level events. A reasonable cadence is one to four broadcasts per month, depending on what landed. Five reasons for the restraint: + +1. Each broadcast costs N inbox processings across the fleet (currently ~23 targets). Daily broadcasts mean daily noise. +2. Most commits are project-internal. Other projects do not need to read about another project's TODO sweeps, audit passes, or hygiene work. +3. The startup rsync already does the capability work. Broadcasts add awareness, not availability. +4. Aggregation wins. One weekly "here's what shipped" digest beats ten per-commit pings on every dimension. Fewer inbox files, easier to skim, easier to defer reading. +5. Per-commit broadcasts train projects to ignore inbox. Then a real handoff gets missed. + +If a session ships several broadcastable changes, bundle them into one broadcast at session end rather than firing one per commit. * The Workflow |