Coordination patterns ​

Why Week 4 is the meta-layer ​

At running stage, coordination is mostly you. You decide which tab needs attention. You move information between tabs. You notice which streams are stuck. The whole orchestration happens in your head.

At flying stage, that breaks. 10+ streams means too many tabs to track manually, too much cross-stream context to hold, too many small coordination decisions per hour for the human to keep up. The fleet runs ahead of your ability to supervise it.

What replaces the human coordination is also agents. A class of agents whose job isn't to do the engineering work — it's to watch the agents that do the engineering work, surface what needs attention, and handle the routine coordination so you don't have to. These meta-agents are the difference between flying-stage as sustainable practice and flying-stage as burnout.

Three patterns to install this week:

1. The Team Ops sweep skill — a periodic agent that scans the whole fleet.
2. Cross-stream context sharing — when one tab needs context from another, without you walking it across.
3. PR-nudging automation — keeping your shipped work moving without your attention on it.

Plus the Friday demo + weekly planning ritual at flying-stage, which is mechanically different from the running-stage version because of the volume.

1 — The Team Ops sweep skill ​

The single most-installed pattern in Fred's daily fleet. Worth understanding in detail.

What it does ​

A periodic agent that, on a schedule (every 30 min, every hour, or on-demand when you trigger it), does this sweep:

• Reads every active cctab session via cctabs sessions + cctabs scrollback.
• Classifies each session's state: actively working, blocked-on-input, completed-and-quiet, stuck-in-a-loop.
• Reads recent activity in the repos those sessions are working against (recent commits, PR state, CI state).
• Drafts your responses for sessions that are blocked-on-input — based on the visible context, what would you most likely say back, and how should the agent prepare for that?
• Surfaces a triage list: here are the 3 sessions that need your attention now, here's what each is waiting on, here's the draft reply for each.

You read the triage list. You approve / edit / send replies via cctabs send. The fleet keeps moving.

Why this pattern is load-bearing ​

Without it: at 10 streams, you're context-switching to every stream every few minutes to check status. Brain-fry by lunch.

With it: you context-switch on a schedule (every 30–60 min), to the streams the meta-agent has surfaced, with the prep already done. Your attention goes to the decisions, not the scanning.

How to build one ​

You don't need a complex framework — it's a Claude Code skill file in your top-level orchestrator session. Rough shape:

# Team Ops Sweep

When invoked, do this:

1. Run `cctabs sessions` to list all active tabs.
2. For each tab, run `cctabs scrollback <name>` to read the last
   ~100 lines of terminal output.
3. Classify each tab's state:
   - **Active**: an agent is currently working, no input needed
   - **Blocked**: agent is waiting on a user reply or approval
   - **Quiet**: agent has been idle >30 min with no apparent work
   - **Stuck**: agent appears to be looping or repeatedly retrying
4. For each Blocked tab:
   - Read the agent's last message asking for input.
   - Read the surrounding context (the work-stream's CLAUDE.md,
     NEXT-STEPS.md, recent commits in the repo).
   - Draft a 1-2 sentence reply the human would likely send.
5. For each Stuck tab: identify what's failing and propose a
   re-prompt or a manual intervention.
6. Produce a triage report:
   - Streams needing attention: <list>
   - For each: state, draft reply (if Blocked), recommended
     action (if Stuck).
   - Streams cooking fine: <count, no detail needed>.
7. Surface the report. Don't take actions on other tabs — just
   draft what the human should send.

This is a starting template. Tighten it to your fleet's specifics — the repos you care about, the kinds of work that show up frequently, the conventions your team uses.

When to run it ​

• On-demand when you sit down to your fleet (start of the day, after a meeting, after lunch).
• On a schedule if you have a cron-or-equivalent that can hand the prompt to a Claude session.
• Triggered by external events — a deploy finishing, CI completing, a PR getting a review — for the more advanced setups.

The discipline: the sweep is for your attention, not for the agent's authority. The meta-agent surfaces and drafts; you decide and send. At today's capability level, letting the meta-agent send replies autonomously across the fleet introduces too many silent failure modes.

Meta-skill: writing your own skills ​

The Team Ops sweep template above is one skill. Once you're at flying-stage, you're authoring skills constantly — every time a prompt you've typed three times deserves to be extracted, every time a coordination pattern shows up across streams, every time a recurring agent task could be invoked by name instead of re-explained.

A few practitioner-tested rules:

• Extract on the third repetition. First time you do a thing manually is fine. Second time, you notice the pattern. Third time, the prompt is stable enough to be a skill. Trying to extract on the first or second iteration produces brittle skills that get refactored more than they get invoked.
• Naming is load-bearing. Skill names are how you (and other agents) discover them at call time. Use verb-leading, specific names: triage-stuck-prs, sync-staging-fixtures, summarize-week-for-friday-demo. Avoid generic names like helper or utils — those won't surface when an agent is scanning the available skill set.
• Frontmatter discipline. A clear description field at the top is what makes the skill discoverable by a sibling Claude session. Treat it as the one-line pitch the agent reads to decide whether this skill is the right tool. Vague descriptions get skipped; specific ones get invoked.
• Inline until it earns being a skill. Not every prompt needs to become a .md file in .claude/skills/. If the prompt is one-off, leave it inline. The skill library compounds in value when it's curated, not when it's exhaustive.
• Evals are usually overkill at the individual-skill level. At fleet scale, the eval is the working day — skills that produce bad output get re-prompted or replaced, fast. Reserve formal eval work for skills that hit a quality wall and need it.

The skill library is one of the artefacts that compounds across months of practice. The team that maintains a shared skills directory in their orchestrator repo (and treats it as a first-class artefact in code review) gets more leverage per engineer over time.

2 — Cross-stream context sharing ​

The pattern: information lives in one tab, needs to be used in another, without you carrying it.

The shapes this takes ​

• A decision made in tab A (after some research) needs to inform the work in tabs B and C. Old way: you remember and re-explain in each tab. New way: commit the decision to the repo as a markdown note in a known location (e.g. docs/decisions/), and the agents in B and C pick it up next time they scan their context.
• An artefact produced in tab A (a generated config, a schema, an analysis result) is consumed by tab B. Commit it to the repo with a clear path; tab B reads it.
• A finding from tab A ("this approach doesn't work because X") needs to prevent tab C from going down the same path. Commit to a LEARNED.md or equivalent, referenced from CLAUDE.md.
• Live runtime state from tab A is needed by tab B. This is the harder case — cctabs send and cctabs scrollback let one Claude session read another's terminal directly, and a sibling agent can hand context across at runtime.

The principle ​

The repo is the bus. Most cross-stream context flows through committed markdown.

When a decision matters across streams, it goes into the repo. When it matters only to one stream, it stays in that stream's working memory. The repo-as-bus pattern is what makes 10+ parallel sessions sustainable — because you're not the routing layer.

What this needs from you ​

Discipline: when an agent surfaces something cross-cutting, capture it to the repo before moving on. A 30-second commit now saves you (or a meta-agent) re-explaining the same thing across 8 tabs later.

3 — PR-nudging automation ​

The third coordination layer: keeping your shipped work moving through the team's process without you watching it.

What automates well ​

• Reviewer nudging. Agent watches your open PRs, identifies the ones that are stale (no reviewer activity for N hours), drafts a Slack/Teams nudge to the assigned reviewer (or escalates to a backup if the primary is OOO).
• CI retries on transient failures. A flaky network test fails; agent re-runs CI rather than waking you up. If it fails three times in a row, then surface it.
• Draft / ready-for-review transitions. Agent moves a PR from draft to ready when the conditions are met (CI green, self-review checklist complete).
• Auto-merge eligibility. When all approvals are in and gates are green, auto-merge — possibly queued for a low-risk merge window if your team has one.
• Branch cleanup. Merged branches deleted automatically. Worktrees pruned.

What doesn't automate well ​

• The actual content of code review on non-trivial PRs.
• Decisions about whether to merge a PR that's controversial.
• Anything that's a judgement call about product direction.

Where this connects to Week 3 ​

A lot of PR-nudging automation overlaps with the Team Ops sweep skill from §1. You can build them as one combined skill, or split them by domain (sweep handles in-flight work; nudging handles shipped work). Either works. The shared underlying capability is: an agent that periodically polls some surface, identifies what needs movement, takes routine actions, surfaces non-routine ones.

Review for direction, not size ​

The quiet shift that makes high-volume PR review workable: a one-line feature flip can carry the same weight as a huge refactor that doesn't visibly change anything on the surface. Trying to scale per-PR review time with per-PR line count breaks the moment you're shipping 5× the PRs at smaller average size.

The review question stops being "is this code OK" and becomes "is this change moving the work-stream in the right direction." Most of the time the answer is yes and the review takes 30 seconds. The few PRs that need real direction-discussion get it — the rest don't get pretend-attention they don't need.

4 — Daily ambient sync ​

The coordination primitive most fleets discover only after brain-fry has hit. A 10-minute daily Slack huddle (or equivalent) — no agenda, drop-in, context flows continuously while people work — becomes load-bearing the moment each person is running 10+ parallel streams.

Without it, context fragments across streams: tab A's agent figures something out that would help tab D's agent, but the human running both isn't paying attention to the cross-cutting opportunity. Multiply by N engineers, each running their own fleet, and the team is leaving compounding leverage on the floor.

What this looks like:

• A persistent Slack huddle (or Discord, or whatever your team uses) that runs in the background through the working day.
• People drop in and out — no obligation to be present, no penalty for missing.
• Conversation is whatever's surfacing right now: "agent says X, anyone seen this?", "I just shipped Y, anyone want the brief?", "anyone got a working pattern for Z?"
• Heavy on screen-shared scrollbacks, light on slide-deck formality.

What it's not:

• Standup. Standups are status reports, this is real-time context-flow.
• A meeting with an agenda. The whole point is no agenda.
• Mandatory presence. The huddle works because people drop in when their attention has room.

For solo operators, the equivalent is harder. A daily voice memo to yourself, or a running scratch file the agent reads at the start of each session, can substitute. Less rich than a real team's ambient sync; better than nothing.

5 — The Friday demo + weekly planning ritual at flying-stage ​

At running stage, Friday demo is straightforward: each engineer demos the week's shipped work, the team updates next week's plan. Maybe an hour.

At flying stage, the volume is different. A 4-engineer team running 8–20 streams each can ship 50+ PRs in a week. A 1-hour demo at that volume becomes a 4-hour slog if you try to demo each PR individually.

What changes ​

• Demos are thematic, not per-PR. Each engineer picks 1–3 themes from their week ("the auth refactor," "the partner-integration work," "the cctabs Cookbook patterns I extracted"). They demo the theme, with PRs as supporting evidence.
• The planning half compresses. Most of the week's planning has already happened in NEXT-STEPS.md updates throughout the week — Friday is for noticing the shifts that happened across the week, not for first-time planning.
• The meta-questions get airtime. What's the team's brain-fry rate this week? Which integrations are still missing? Where is the political layer (Week 5) starting to bite? These are the conversations that don't fit elsewhere in the week.
• Total time stays similar (~1 hour), but the density per minute is higher.

Why it matters at flying-stage ​

The Friday ritual is the heartbeat that keeps the fleet practice from drifting. Without it, individual engineers go heads-down on their fleets for weeks and the team loses shared context about what's being learned. The compounding that makes the practice valuable comes from the team learning, not from individuals running parallel sessions in isolation.

If you're solo running a fleet without a team, run it as a Friday self-demo + planning session. Record yourself, review the next morning. Same discipline, different audience.

The assignment — install + demo a Team Ops sweep skill ​

If this is your first time building a Claude Code skill: the rough shape is a markdown file with a description, the invocation pattern, and the steps the agent should follow. Claude Code's docs cover the format. The Team Ops sweep is a useful first skill to build because it pays for itself the day you finish it.

Self-check — did this week land? ​

• You have a Team Ops sweep skill, committed to a repo, that you've run at least 3 times this week.
• You're not context-switching to every tab every few minutes anymore. You're context-switching on the cadence the sweep skill surfaces.
• At least one piece of cross-stream context has flowed via the repo this week (committed decision, generated artefact, learned-finding note) rather than via you walking it between tabs.
• At least one PR-nudging or auto-merge pattern is running on your shipped work.
• Your PR-review reflex is direction-first, not size-first. Small PRs that move the work-stream get the same attention as large ones; large PRs that don't move direction get less than they used to.
• If you have a team, the daily ambient sync is running. If you're solo, the substitute is running (voice memos, scratch file, equivalent).
• You've authored at least one new skill this week (Team Ops sweep counts; anything else extracted-on-third-repetition counts too).
• You've run a Friday demo + weekly planning session at flying-stage cadence. Thematic, not per-PR.
• Your fleet feels less like “10 things demanding attention” and more like “a fleet that the sweep skill is helping me steer.”

What's next ​

Week 5 — The emotional spine. The identity work specific to flying stage. Letting go. Brain-fry mitigation. Trusting the structure. The political layer — selling parallelism to a skeptical manager, defending throughput in code review, explaining your work to colleagues who think you're cheating. The week that determines whether the practice sticks past Week 6.