Write a Release Train Coordination Prompt That Sequences Multi-Team Deploys

A release train is a fixed-cadence deploy: everything that's ready ships together on schedule, and anything that isn't waits for the next one. The idea is simple. Coordinating it across eight teams the morning of the train is not. A release train coordination prompt takes the readiness roll-up, the dependency map, and the deploy window, and turns them into an ordered plan you can actually run.

The pain isn't any one service. It's the seams between them. Service A deploys, service B depended on A's old contract, and now the train's half out of the station with a broken coupling. Someone has to know the order, hold the rollback paths, and keep six Slack channels informed. Usually that someone is a release manager with a spreadsheet and a bad afternoon.

What the ranking pages give you, and what they don't

Search release train coordination and you get thorough explainers. Octopus Deploy's release orchestration guide (~3,000 words) walks the concepts well: it covers how orchestration works, best practices, even rollback mechanisms, but abstractly, with no copyable artifact. The SRE School release train reference is enormous, close to 9,000 words, with an implementation guide and a pre-production checklist. Still no prompt. Both teach you what a release train is. Neither hands you the thing that sequences your specific train on Tuesday.

That's the gap a prompt fills. You already understand the concept after one read. What you need is the roll-up and the ordering for the services in front of you.

What you can do with this prompt

• Roll up per-service readiness into one train-level status
• Order deploys so upstream services ship before their dependents
• Surface rollback paths for every service before the train departs
• Flag services that aren't ready and shouldn't board this train
• Draft stakeholder comms sized to the audience, from engineers to execs
• Produce a plan a release manager can approve or veto line by line

Anatomy of the prompt pack

The reliable structure is a roll-up feeding a sequencer feeding a rollback review feeding comms. Each stage consumes the last one's artifact, so the sequencer reasons against a real readiness table instead of a vibe.

Variables → Prompt → Output

{{service_change_summaries}}   # what each service is shipping
{{service_dependencies}}       # who depends on whom
{{release_window}}             # when the train leaves
        │
        ▼
Readiness Roll-Up          → {{readiness_report}}
        │
        ▼
Deploy Sequencing Plan     → {{sequencing_plan}}
        │
        ▼
Risk and Rollback Review   → {{rollback_registry}} + {{risk_summary}}
        │
        ▼
Comms Publisher            → per-audience update

The {{readiness_report}} from stage one is the spine. When it's passed verbatim into the sequencer, the deploy order maps to real service names and real blockers. When each stage re-derives readiness, the plan drifts and the coupling between services gets lost.

Step-by-step usage

1. Collect the change summaries

For {{service_change_summaries}}, gather one short summary per service: what's shipping, the migration status, whether it's feature-flagged. This is the input teams already have from their own tickets, so assembling it is copy-paste, not analysis.

2. Map the dependencies

{{service_dependencies}} is the input that makes sequencing possible. List which services call which. Even a rough "B reads A's API, C reads B" is enough for the model to order the train correctly.

3. Roll up, then read the blockers

The roll-up produces {{readiness_report}}. Read the not-ready rows first. If a service is red, the useful output isn't "wait," it's "this service holds up these three dependents, so either it boards or they don't." The prompt should make that coupling explicit.

4. Sequence by dependency, not by team

The sequencer emits {{sequencing_plan}} ordered so upstream deploys land first. Group microservices that must ship together into one train car and orchestrate them as a unit. That single-unit grouping is what keeps rollback and observability sane.

5. Lock rollback before comms

The rollback review fills {{rollback_registry}} with a path per service and a {{risk_summary}}. Only then does the comms stage draft the stakeholder update. Comms before rollback is how you announce a launch you can't safely reverse.

Prompt-craft patterns that matter here

Pass the readiness table, don't summarize it. The sequencer needs real service names and real blocker states. A pasted {{readiness_report}} survives a long prompt far better than a paraphrase the model wrote earlier. This is the difference between a plan that orders "auth before billing" and one that hallucinates a service.

Make the sequencer show its dependency reasoning. A two-line role plus a hard output contract beats a paragraph of persona. Force the order and the reason:

Role: You are the release conductor for a scheduled train.
Task: From the readiness report and dependency map, order the deploys.
Output contract:
- Ordered deploy list, each with its upstream dependencies named
- Any service that must not board, with the dependents it blocks
- Rollback trigger per service
No preamble.

Naming upstream dependencies per row is what makes the plan auditable. A bare ordered list is a guess you can't check.

Size comms to the audience, one artifact each. Here's the opinionated part: don't write one release note for everyone. Engineers need the deploy order and rollback triggers; execs need the customer-facing outcome and the go/no-go. The comms stage should take an {{audience}} variable and produce distinct updates, because a single message that tries to serve both serves neither.

Variables you'll set

Getting started

1. Collect one change summary per service into {{service_change_summaries}}.
2. Sketch {{service_dependencies}} (rough is fine).
3. Set the {{release_window}}.
4. Run the roll-up; read the not-ready rows and their dependents.
5. Sequence the train; confirm upstream services come first.
6. Lock {{rollback_registry}} before you draft any comms.
7. Publish per-audience updates and hold the go/no-go.

If a single service still needs its own gate, the deployment go/no-go review prompt handles that decision, and the coordination prompt sits one level above it across the whole train. Every service in the train also needs a reversal path, which is where the rollback plan prompt earns its keep before the train leaves.

One honest limit: a model can propose the order, but it can't know a service is quietly degraded unless your inputs say so. Feed it accurate readiness, pin the deploy window, and treat the sequence as a plan to approve, not to auto-run. For the launch update itself, the release communications pack drafts the stakeholder side, and the release readiness pack verifies a single milestone before it boards the train.