Event Content

Everything you will publish about the event, written before the event. Teams that plan to write it afterward send it five days late, and five days late is a different asset entirely.

When to use

• T-3 weeks on any event worth talking about
• After an event, when nothing was prepared and speed still matters
• A roundtable or panel that generated genuinely good material

Inputs

• Reads: workspace/events/<event>/ (the plan, the program, the speakers), workspace/program/charter.md
• Needs from user: who publishes in which voice, whether the event is on or off the record, and what capture is available

Workflow

1. Build the pre-event set

For a private dinner, skip almost all of this. Publicizing a private room damages the thing that makes it work.

2. Write the post-event set before the event

All of it, in skeleton, with placeholders for what you cannot know yet:

The only work left afterward is personalization and filling the blanks, which is the only part that genuinely has to happen afterward.

3. Brief the photographer with a shot list

Without a list you get a hundred photos of people eating and none of the five you needed.

• The room full and looking busy, from the back
• Your speaker mid-gesture at the lectern or in conversation
• Two or three candid conversation shots, three-quarter angle
• The venue looking good before guests arrive
• One clean group shot if the format allows it
• Detail shots: the table set, the signage, the branding

Agree the permission rules first. Under Chatham House Rule or any off-the-record framing, publishing attendee faces or names is a breach, and it will cost you the next room. Ask in the room if you want a specific photo published.

4. Capture the substance, not just the pictures

The most valuable output of a good roundtable or panel is what was said. Assign a notetaker who is not the moderator or a speaker, and capture themes and quotable formulations rather than a transcript.

Get attribution permission on the spot. Asking in the room is easy. Asking three weeks later is awkward and usually gets a no.

5. Write recaps that are worth reading

A recap that lists who spoke and thanks everyone is a press release nobody reads. A recap worth reading takes the single most interesting thing said in the room and makes an argument out of it.

The test: would this be worth reading by someone who was not there and has no interest in your company? If not, rewrite it around the idea rather than the event.

6. Route everything through the quality gate

Every published piece runs through writing-quality. Event recaps are unusually prone to the tells: inflated significance, three-part lists, and words like "incredible" and "energy" doing the work that a specific detail should be doing.

Output

• Writes: workspace/events/<event>/content/ with pre and post assets, the shot list, the capture plan, and the publishing calendar
• Prints: the calendar with owners, which assets are drafted, and the permission rules

Rules & quality bar

• The post-event set is written before the event
• Photographer briefed with a written shot list
• Chatham House Rule honored in every published asset, including social
• Attribution permission asked in the room
• A recap is an argument, not a thank-you list
• Private dinners are not publicized. Publicity damages the format
• Everything runs through writing-quality
• No invented quotes. Attributed words are verbatim or they are paraphrase without quote marks

Related skills

• Reads: the format skills, speaking-and-stage
• Pairs with: event-followup (different audience, same deadline)
• Gated by: writing-quality, optionally artifact-eval