--- name: campaign_retrospective description: Run a post-campaign retrospective people learn from: rebuild the campaign timeline from records, clean raw survey and comment feedback into themes with counts and verbatim quotes, give every tactic a keep, fix, or kill verdict tied to evidence, and close with a short action list with owners and dates. Use when a marketing, social, launch, or fundraising campaign has ended, when a campaign review or post-campaign report is requested, or when the team is about to repeat a campaign and needs to know what to carry forward. --- # Campaign Retrospective ## Purpose Turn a finished campaign into decisions the next campaign actually uses. Most campaign reviews fail in three predictable ways. They argue from memory instead of a timeline, they quote three loud comments instead of the whole feedback set, and they end with lessons nobody owns. This skill prevents all three. The timeline settles what happened. The feedback cleaning settles what the audience said. The verdict table settles what changes. The action list settles who does it and by when. This is a post-campaign skill. For the brief before a campaign, use a campaign brief skill. For a weekly in-flight performance read, use a marketing performance brief skill. For a project or incident postmortem, use a postmortem skill. ## Workflow 1. **Set the scope and the clock.** Write at the top: campaign name, start and end dates, the one primary objective and target from the brief, total spend, and the date of this retrospective. Run the review soon after the campaign ends, while records and memory are still fresh. Name one facilitator who did not own the biggest tactic if you can. State the ground rule out loud at the start: the review judges tactics and systems, not people. 2. **Rebuild the timeline from records, not memory.** List every material event in date order: brief approved, assets approved, launch, each spend or targeting change, each creative swap, any outage, complaint spike, press pickup, or competitor move, and the end date. Source each row from a dated record: platform change history, email, ticket, invoice, or analytics annotation. Mark any row that comes only from memory with the word memory in the source column. A timeline with more than a third of its rows marked memory is not ready; go get the records first. This is the Gather Data stage in Derby and Larsen, Agile Retrospectives (2006): Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close the Retrospective. 3. **Answer the four after-action questions in order, on the timeline.** The US Army after-action review, in use since the 1970s, asks: what was supposed to happen, what actually happened, why did it happen, and what will we do next time. Do not skip to why before the group agrees on the first two. Army guidance as commonly reported puts about half the review time on the last question. Follow that split: facts are the floor, decisions are the point. 4. **Score the result against the target set before launch.** One table: metric, baseline, target, actual, source system, and verdict on the metric itself (hit, missed, or no valid read). Use plain arithmetic and say which formula you used: click-through rate is clicks divided by impressions, cost per result is spend divided by results, return on ad spend is attributed revenue divided by spend. If tracking broke, the metric verdict is no valid read, and the fix becomes an action. Never backfill a plausible number for a broken metric. Segment the actuals the way the brief segmented the audience. A campaign total can hide a segment that carried the result and a segment that burned the budget. 5. **Collect all audience feedback before anyone quotes any of it.** Pull the full set from every place the audience talked back: survey open ends, post comments, replies, DMs that are about the campaign, support tickets tagged to the campaign, reviews, and unsubscribe or complaint reasons. Record the collection window, the source, and the raw count per source. Dedupe exact repeats from the same person on the same source. Keep bots and spam in a separate excluded count with the reason, do not silently delete them. Anonymise names before the set circulates for coding, unless a person gave permission to be quoted by name. 6. **Clean the feedback into themes. Follow the method in `references/feedback-cleaning.md`.** The short version, adapted from Braun and Clarke thematic analysis (2006, and their 2022 practical guide): read the whole set first without coding, code each item with one or two short labels that stay close to the words used, group codes into candidate themes, check each theme back against the full set, then define and name each theme in one sentence. A theme needs a count, the share of coded items, at least two verbatim quotes, and a note on which segment or channel it came from. Single items that are severe (a safety issue, a legal complaint, a factual error in an asset) get listed on their own even with a count of one. Frequency is not the same as importance, so report both. 7. **Check the coding before you trust the themes.** Have a second person independently code a sample of at least 30 items, or 20 percent of the set if the set is larger than 150 items. Report simple percent agreement: agreed items divided by sampled items. If agreement falls below 80 percent, the code definitions are unclear; rewrite the definitions, re-code the sample together, and note the change in the retrospective. Percent agreement does not correct for chance, so label it as percent agreement and never as a kappa score. On a solo run with no second coder, say so in the document and re-code the same sample yourself after a break of at least a day, reporting that as a self-check, not independent agreement. 8. **Give every tactic a verdict: keep, fix, or kill.** A tactic is a repeatable unit the team chose: a channel, a format, an offer, a posting cadence, an audience slice, an approval step, a tool. One row per tactic in the verdict table in `assets/verdict-template.md`: tactic, what it cost in money or hours, the timeline and metric evidence, the feedback themes that touch it, the verdict, and the one-sentence reason. Keep means run it again as is. Fix means run it again only with the named change. Kill means stop it, and say what replaces it or what the freed budget and hours go to. No tactic gets a verdict from a metric alone or from comments alone; each verdict cites at least one timeline or metric fact and, where audience feedback exists for it, one theme. A tactic with no usable evidence gets the verdict fix with the change being instrument it properly next time. 9. **Separate causes from coincidences.** For each missed or beaten target, list the candidate causes and mark each as confirmed, likely, or unknown. Confirmed needs a dated record or a controlled comparison, such as a variant test run at the same time to the same audience. Likely needs two independent signals pointing the same way, for example a timeline change plus a theme in the feedback. Everything else is unknown, and unknown causes do not justify a kill verdict on their own. Write the strongest rival explanation next to the favoured one. If the rival explains the data just as well, both go in the document. 10. **Cut the action list down to what will happen.** At most seven actions. Each action is one sentence starting with a verb, with one named owner, a calendar due date, and a done test the reader can check (a link, a published change, a number). Order actions by what unblocks the next campaign first. Carry in the open actions from the previous retrospective at the top and mark each done, dropped with a reason, or carried again. A retrospective that ignores the last retrospective trains the team to ignore this one. 11. **Write the one-page summary last, and put it first.** Five short sections: result against target in two sentences, the three themes the audience handed you, the verdict counts (how many keep, fix, kill), the top three actions with owners, and the one thing to test first next time. The full tables sit behind it. Anyone who reads only the summary should still know what happened, what the audience said, and what changes. 12. **Run the checker and hold a 30 to 60 minute review meeting.** Run `python3 ~/workspace/skills/campaign-retrospective/bin/retro_check.py ` and fix every error before the meeting. In the meeting, walk the timeline first, then the themes, then the verdicts. Change a verdict only when someone brings evidence the document missed, and record the new evidence in the row. Close by reading the action list out loud, owner by owner, and confirming each due date is real. File the finished document where the next campaign brief will be written, and link it from that brief when the time comes. Start from `assets/retrospective-template.md`. A complete fictional worked example is in `references/worked-example.md`. ## Output Contract Deliver, in this order: 1. The finished retrospective using the template sections: header and result scorecard, rebuilt timeline, feedback themes with counts and verbatim quotes, tactic verdict table, causes table, action list, and the one-page summary placed at the top of the document. 2. The feedback cleaning log: raw count per source, excluded count with reasons, coded count, the code definitions used, the double-code sample size and percent agreement, and any definition changes made after the check. 3. The checker output, or a note that it ran clean, with warnings explained rather than ignored. ## Operating Rules - Never invent a metric, a quote, a count, or a date. A quote in the document must be copied from the feedback set. A number must trace to a source system named in the scorecard. - Report the feedback denominator every time. A theme count with no total coded count beside it does not go in. - Keep and kill are both respectable verdicts. A review where everything is a fix has made no decisions. - Do not average away a bad segment. If one audience slice, channel, or day drove the complaints or the cost, the verdict table says so in that tactic row. - Protect the people who gave feedback. Quote without names by default, remove contact details and other identifying details from quotes, and never paste DM text that the sender would reasonably expect to stay private without permission. Summarise private messages instead. - If the campaign is still running, stop. This skill is for finished campaigns. Use an in-flight performance brief and run this skill after the end date. - Mark the document draft until the review meeting has confirmed the verdicts and the action owners have accepted their dates.