Weather comms template by Hive Backstage

---
name: weather-comms-template
description: Draft calm, factual weather contingency comms for an outdoor show, covering the four states an operator hits in real time (watch-and-see, doors delay, full delay, weather cancellation) across email, social, and on-site channels, without apology language for the weather itself. Trigger whenever an operator says "the [festival/outdoor show] is looking like rain", "we may need to delay for weather", "write the storm comms", "draft the weather hold message", "the show is getting weathered out", or asks for the comms that go out when an outdoor or partially outdoor event faces a weather call. Also trigger when the operator describes a storm window, lightning risk, heat advisory, wind advisory, or air-quality issue and wants the audience-facing comms ready. Distinct from non-weather contingency (use `contingency-comms-packet`). Weather comms have their own voice because the venue is not at fault and the audience is often already on site or en route.
---
# Weather comms template

## What this skill does

This skill drafts the comms that go out when weather is changing the plan for an outdoor or partially outdoor show. Weather comms are their own category for two reasons. The cause is outside everyone's control, so the voice does not apologize for the weather itself. And the audience often hears the comms while already moving toward the venue, so the comms have to land fast and act faster.

The skill produces comms for four weather states the operator encounters in order: watch-and-see, doors delay, full delay, and weather cancellation. Each state has email, social, and on-site versions. The operator picks the state matching the current call and gets a ready-to-send packet.

## When to trigger

Trigger when an operator mentions weather affecting a show. Trigger on "weather hold", "storm comms", "lightning delay", "the show is getting weathered out", "we are watching the radar", "heat advisory", "wind advisory", "air-quality", or any phrasing where the weather is the variable.

Do not trigger for non-weather contingencies (use contingency-comms-packet). The two skills produce different tones because the cause is different.

## Required inputs

Ask for these in one message before drafting. Weather comms move faster than other comms, so the skill should write quickly once the inputs are clear.

Artist name and venue.

The current state: watch-and-see, doors delay, full delay, or weather cancellation. The operator picks. The skill writes only the matching state.

The weather situation in plain language. A specific phrase from the operator: "lightning within 8 miles", "incoming storm cell, expected on-site at 7:45", "wind advisory just issued", "heat index hitting 105". The comms cite this in operator-friendly language without speculation.

The action the venue is taking. For watch-and-see: monitoring, no change yet. For doors delay: pushing doors from [time] to [time]. For full delay: clearing the venue or holding outside, with an updated time. For cancellation: refund mechanism and timeline.

The action ticketholders should take. Stay on site, return to cars, find shelter, hold outside the venue, head home and wait for an update, check the venue's social feed.

Update cadence. When the next update will go out. Comms with no update cadence read as abandonment. Even "next update at 8:15" or "we will update every 30 minutes" makes a huge difference.

For weather cancellation specifically: the refund mechanism and processing window. Same defaults as contingency-comms-packet.

## Voice

Read the venue voice profile if one exists. Weather comms still sound like the venue, just compressed and operational.

Default Backstage operator voice if no profile exists: calm, factual, brief. The voice is the venue saying "here is what we know, here is what to do, here is when we will update you". Not panic. Not apology.

Hard voice rules:

No em-dashes. Use commas, semicolons, or periods.

No apology for the weather. The venue is not at fault for the weather. Apologizing for nature reads as performative.

The exception is delays caused by venue operations downstream of the weather. If the venue's choice (extending the doors delay, choosing to cancel rather than hold) deserves acknowledgment, the comms can say "we know this is frustrating" once. Not three times.

No speculation about the weather. The comms cite what the operator gave you. "Lightning within 8 miles" is fine. "The storm should pass by 8" is not, unless the operator is sourcing that from the meteorologist they trust.

No urgency for the wrong reason. "Get to your car now" only when safety requires it. "Return to your car and wait for the next update" when the call is precautionary.

No hype on the rescheduled or resumed start. If the show resumes, the comms note the new start time. The next announce email can lean into the resumed show. Not these comms.

## The four states

### State 1: Watch-and-see
The show is on. The venue is monitoring. The audience needs to know the venue is paying attention so they do not surface bad info from social media.

### State 2: Doors delay
Doors are pushed by a defined amount of time. The show is still on. The audience needs the new doors time and what to do in the interim (hold outside, wait in cars, find shelter nearby).

### State 3: Full delay
The show is paused mid-event, or doors are delayed beyond the point where the audience needs to be cleared from the site. The audience needs the safety call, the rough re-start window, and the next-update time.

### State 4: Weather cancellation
The show is off due to weather. Refund mechanics same as contingency-comms-packet. The audience needs the cancellation, the refund mechanism, and any rescheduling intent.

## Output structure per state

The structure is consistent across states. The substance compresses.

### Email

Email goes out only at state 2 and beyond. State 1 (watch-and-see) typically does not warrant an email; social and signage are enough.

Subject line. Plain language. "[Artist] at [Venue]: weather update". "[Artist] show: doors delayed to [time]". "[Artist] show: cancelled due to weather". Under 55 characters.

Preheader. One sentence with the single most operational detail.

Opener. Two sentences. State the call. State the immediate next step.

The details. One short paragraph. The weather situation in operator-friendly language. The action being taken. The action ticketholders should take. The next update time.

CTA. One link, if applicable: the venue's social feed for live updates, or the refund FAQ on cancellation. Skip CTA on small delays where no action is needed.

Close. One line. Neutral sign-off.

### Social

The fastest surface. Update every state change here.

Format:

```
[Artist] update, [Timestamp]

[One sentence on the call.]
[One sentence on what to do.]
[One sentence on the next update time.]
```

X version: under 280 characters, same structure compressed.

### On-site signage and PA

For state 2, 3, and 4. Short blocks for box office, gate staff, and PA announcements.

Box office and gate signage:

```
[Artist] - [Date]
Weather update: [State + time]

[One line on the call.]
[One line on what to do.]
[Next update: [time]]
```

PA announcement (state 3 specifically):

A 3 to 5 sentence script for venue staff to read over the PA. Calm, slow, operational. Names the call, names the action, names the next update.

## Hard rules for weather comms

State the next update time. Every comms surface includes "next update at [time]" or "updates every [N] minutes". The audience can wait. They cannot wait without knowing when to expect the next signal.

Match the comms across surfaces. The email, social, and on-site all give the same call and the same next-update time. Conflicting numbers in weather comms are the fastest way to lose trust.

Do not predict the weather. The skill writes what the operator confirmed, not what the operator hopes. If the operator says "we are calling a 30-minute hold", that is the comms. If they say "we hope to resume around 9", the comms note that the next update is at the hold's end, not the hoped-for resume time.

Cancellation comms reuse the refund language defaults from contingency-comms-packet. Cross-check before sending.

Safety language is short and direct. If the call is to clear the venue, the comms say "clear the venue", not "we would like everyone to make their way calmly back to their vehicles".

Update cadence holds even when nothing changes. If 8:15 was the next-update time and the call has not changed, the 8:15 update goes out anyway saying "no change, next update at 8:45". Silence reads as abandonment.

## Common failure modes to avoid

Apologizing for the weather. "We are so sorry for the weather" is the failure pattern. The weather is not the venue's choice.

Long-form sympathy paragraphs. The audience needs information, not feelings, in the moment.

Skipping the next-update time. Comms without a next-update create a vacuum. The vacuum fills with rumors on social.

Hyping the resume. "The show is back on" is fine. "The show is back on and is going to be incredible" is not.

Treating cancellation as a marketing setup. The cancellation comms confirm the cancellation. The next reschedule comms can sell the new date. Not this one.

Inventing the meteorology. The operator confirms the situation. The skill writes what they said.

## What to deliver

Return the packet for the requested state, with each surface labeled (Email, Social, Signage, PA).

If the operator did not give you a next-update time, ask for it before drafting. Do not draft without one. If they did not give you the action ticketholders should take, ask for it before drafting. Do not draft without one.

End with two or three sentences naming any detail you had to leave generic and what the next state's comms would need from the operator. Do not walk through every word choice. Weather comms are read-and-act, not read-and-admire.