Project Retrospective

What This Skill Does

Takes raw notes about a finished media project and generates a structured LESSONS.md that captures reusable editorial decisions, workflow fixes, timeline findings, and specific carry-over items for the next project.

When To Use This Skill

• After a series, season, or multi-episode project wraps and you want to capture what the team learned before everyone moves on to the next thing
• When a project ran over budget, over schedule, or below quality expectations and you need a written record of why, without blame, before the post-mortem meeting
• Before starting a new project that resembles one you finished recently — run the retrospective on the old project first, then use the LESSONS.md as a planning input
• When a freelancer or contributor is leaving the team and their working knowledge needs to be captured before they go
• At the end of a pilot or proof-of-concept phase, to decide whether the format is worth continuing and what must change if it does

What You Need To Provide

Required:

• Project name and format (podcast series, documentary, article series, YouTube channel launch, newsletter run, etc.)
• What the original brief or goal was — in one or two sentences
• What was actually delivered — scope, episode count, word count, whatever the countable output was
• What went well — even rough bullet points are fine
• What went badly or took too long — same level of detail

Optional:

• Timeline: planned vs. actual dates for key milestones (commission, first draft, rough cut, delivery)
• Team structure: who did what, and whether roles shifted during the project
• Budget notes: where you overspent, where you underspent, what you wish you had costed differently
• Stakeholder or client feedback: quotes, notes from review rounds, approval friction
• Technical or tooling notes: software, equipment, workflows that helped or caused problems
• Audience reception: ratings, downloads, reader feedback, social response — anything that tells you whether the output landed
• Anything that surprised you, positively or negatively

How the Assistant Approaches This

1. Reads all the notes you provide and identifies the project's actual arc — what was planned, what happened, and where the two diverged. This is the factual spine of the retrospective.
2. Sorts every finding into one of six categories: editorial decisions, workflow and process, timeline and scheduling, stakeholder management, quality and standards, tooling and infrastructure. Findings that span categories go under the primary one, with a cross-reference note where needed.
3. For each finding, separates the observation (what happened) from the lesson (what to do differently). The observation is evidence; the lesson is the actionable recommendation. Both get written down, because a lesson without its evidence is just an opinion someone will discard six months from now.
4. Identifies carry-over items — specific, concrete things the next project should adopt, avoid, or investigate further. These are formatted as a checklist so they can be pasted directly into a planning document or project brief.
5. Flags any patterns that appear across multiple categories. If the same root cause — unclear briefs, missing sign-off gates, a tool that kept failing — shows up in three different problems, it gets called out as a systemic issue with its own section. These are often the most valuable findings in the entire document.
6. Writes the LESSONS.md in a tone that is direct, specific, and blame-free. Names roles, not people. States facts, not judgments. The document should be useful to someone who was not on the project and has never met the team.
7. Checks the draft against the quality criteria below before delivering. Every lesson must be specific enough that a producer reading it six months from now can act on it without asking anyone what it means.

If the input notes have clear gaps — timeline information is missing, no audience data was provided, the team structure is unknown — the skill will note these gaps in the relevant sections rather than speculating. A retrospective that acknowledges what it does not know is more trustworthy than one that fills every section with confident claims.

Output Format

The skill produces a single Markdown document called LESSONS.md with this structure:

# LESSONS.md — [Project Name]

**Project:** [Name]
**Format:** [Podcast series / Documentary / Article series / etc.]
**Dates:** [Start] — [End]
**Scope:** [What was delivered — episode count, word count, etc.]

## Summary
[3–5 sentences: what the project set out to do, what it delivered, and the
single most important lesson. This paragraph should be useful on its own
as a quick reference.]

## Editorial Decisions
[Findings about content choices: format, tone, structure, guest selection,
story angle, editorial line. What worked and what to change.]

## Workflow and Process
[Findings about how work moved through the team: briefing, drafting,
review rounds, approvals, file management, handoffs.]

## Timeline and Scheduling
[Planned vs. actual. Where time was lost, where buffers helped, where
deadlines created pressure that affected quality.]

## Stakeholder Management
[Client or commissioner interactions: feedback loops, sign-off friction,
scope changes, expectation mismatches.]

## Quality and Standards
[Findings about the finished output: consistency, accuracy, production
values, audience reception. Where standards held and where they slipped.]

## Tooling and Infrastructure
[Software, hardware, platforms, templates, workflows. What helped, what
failed, what to replace.]

## Systemic Issues
[Patterns that appear across multiple categories. Root causes, not
symptoms.]

## Carry-Over Checklist
- [ ] [Specific action item for the next project]
- [ ] [Another specific action item]
...

## Raw Notes
[Optional: the unprocessed input notes, preserved for reference.]

Length: Typically 800–1,500 words for a mid-sized project (6–12 episodes or equivalent). Shorter for a single article; longer for a multi-season production. The document should be complete but not padded — every paragraph earns its space.

Tone: Direct, collegial, blame-free. Written so that someone joining the team for the next project can read it cold and understand both what happened and what to do about it. No corporate euphemisms ("challenges" when you mean "failures"), but no finger-pointing either. The register should sound like a senior producer's internal memo — someone who respects the reader's time and trusts them to act on clear information.

Formatting: Standard Markdown. No custom syntax, no frontmatter, no metadata beyond the header block. The document should render cleanly in any Markdown viewer and be readable as plain text.

Carry-Over Checklist guidelines: Each checklist item should be phrased as an action ("Create a field recording protocol") rather than a state ("Field recording protocol exists"). Items should include enough context that someone who did not read the full document can understand what the item means and why it is there. Avoid one-word items ("Transcription") — the next producer who reads the checklist needs to know what about transcription needs to change.

Raw Notes section: This section is optional but recommended. It preserves the original unprocessed input for reference, so anyone reviewing the LESSONS.md can check whether a finding accurately reflects what was reported. When a project team revisits the document months later, the raw notes often trigger additional memories that the structured findings did not capture.

Retrospective Framework

The six categories are not arbitrary. Each covers a distinct domain of project decisions, and together they account for where media projects typically succeed or fail. The categories are ordered from most editorial (closest to the content) to most operational (furthest from the content). This ordering helps readers find what they need: producers and editors tend to start from the top; operations and project managers from the bottom.

Not every project will have findings in all six categories. A solo newsletter may have nothing under Stakeholder Management. A commissioned documentary may have little under Tooling. Empty categories are omitted from the output — the skill does not generate placeholder text for sections with no findings.

Timing matters. The best time to run a retrospective is within two weeks of project delivery, while the details are still fresh but the emotional heat of any production crunch has cooled. Run it too early (during the final delivery week) and the team cannot distinguish between systemic problems and temporary stress. Run it too late (three months after delivery) and the specific details — the 45-minute pre-interviews, the three different recording devices — will have faded into vague memories of "things that were a bit messy." If you missed the two-week window, run it anyway with whatever notes you have. A late retrospective is always better than none.

Editorial Decisions

What the project chose to say and how it chose to say it. This is the category closest to the content itself.

What belongs here:

• Format selection — why a series instead of a single long-form piece, why interviews instead of narration, why video instead of audio
• Tone and register decisions — formal vs. conversational, expert-facing vs. general audience, and whether the chosen register held across all instalments
• Guest or source selection criteria — who was included, who was passed over, and whether the selection produced the range of perspectives the project needed
• Story structure choices — chronological vs. thematic, single-thread vs. multi-strand, and whether the chosen structure served the material
• What was cut and why — topics, segments, or episodes that were dropped during production, and whether cutting them improved or weakened the final output
• What was added late — late additions often signal either good editorial instincts (responding to what the material revealed) or poor planning (compensating for gaps that should have been caught earlier)

The question this section answers: If we made this project again with the same brief, what editorial choices would we keep and which would we reverse?

Workflow and Process

How work moved from assignment to delivery. This category covers the mechanics of production — not what was made, but how it was made.

What belongs here:

• Briefing quality — did the initial brief contain enough detail for the team to work from without constant clarification? Did the brief match what the client or commissioner actually wanted?
• Draft-to-final pipeline — how many review rounds, how long each took, where drafts stalled, whether feedback was specific enough to act on in one pass
• Review and approval bottlenecks — who needed to sign off, how long sign-offs took, whether anyone was signing off on things outside their area
• File management — naming conventions (or lack of them), version control, where files lived, whether anyone lost work or worked from the wrong version
• Handoff points — where work passed from one person or role to another, and whether those handoffs were clean (everything the next person needed was provided) or messy (information was lost, context was missing)
• Communication patterns — how the team communicated (email, chat, calls, in-person), how often, and whether the communication cadence matched the pace of production

The question: Where did the process cause delays, errors, or rework that better structure would have prevented?

Timeline and Scheduling

The relationship between the plan and what happened. This category is about time — where it was spent, where it was wasted, and where it ran out.

What belongs here:

• Milestone accuracy — were estimates right? If not, which phases were underestimated and by how much?
• Buffer allocation — was there enough slack in the schedule to absorb surprises? Was the buffer in the right places (early or late in the schedule)?
• Crunch periods and their causes — any stretch where the team worked longer hours or cut corners to meet a deadline, and what forced the crunch
• Dependencies and bottlenecks — tasks that could not start until another task finished, especially where the dependency was not identified in advance
• External deadlines — broadcast dates, publication schedules, event dates, or client deadlines that were fixed and drove the rest of the schedule
• Parallel workstreams — were team members able to work in parallel, or did the project design force sequential work that stretched the timeline?

The question: How should we schedule the next project of this size and complexity?

Stakeholder Management

How the project interacted with everyone outside the core production team. "Stakeholder" here means anyone who had input or authority over the project without doing the daily production work — clients, commissioners, funders, institutional partners, legal departments, distribution platforms.

What belongs here:

• Expectations vs. delivery — did the client or commissioner get what they expected? Where expectations and delivery diverged, was the divergence communicated in advance?
• Feedback round structure — how many rounds of feedback, how specific the feedback was, how long each round took, whether feedback contradicted earlier approvals
• Scope changes — anything added, removed, or modified after the initial agreement, and whether the impact on schedule and budget was acknowledged at the time
• Approval authority — was it clear throughout the project who could approve what? Single approver vs. committee approval; whether approvers were available when needed
• Communication frequency and format — how often the team reported to stakeholders, in what format, and whether stakeholders felt informed or blindsided
• Relationship dynamics — whether the working relationship was collaborative, arms-length, or adversarial, and what set the tone early in the project

The question: What would we set up differently in the first meeting with the client or commissioner?

Quality and Standards

Whether the output met the bar the team set for itself. This is about the finished product, not the process that created it.

What belongs here:

• Consistency across instalments — did all episodes, articles, or segments meet the same quality standard, or did quality vary? If it varied, what caused the dips?
• Factual accuracy — was there a verification process? Did any errors make it into the published output? If so, how were they caught and corrected?
• Production values — audio quality, image quality, copy editing standard, design quality. Were production values where they needed to be, or did budget or time pressure cause visible compromises?
• Audience response — downloads, views, ratings, reader feedback, social media response, complaints, praise. What the audience actually said, as distinct from what the team hoped they would say
• Internal assessment — where the team itself felt the output was strong or weak, separate from audience response. Sometimes the audience likes something the team considers below standard, or vice versa
• Comparison to ambition — how the finished project compares to what the team set out to make. The gap between ambition and delivery is often the most honest measure of a project

The question: Where did the finished work fall short of what we intended, and was the gap caused by time, budget, skill, or a decision we made?

Tooling and Infrastructure

The tools, templates, and technical systems the team used. This category is the furthest from the content itself, but tooling problems have a way of rippling upward into editorial quality.

What belongs here:

• Recording and editing software — what was used, whether it performed as expected, any compatibility issues between team members using different tools or versions
• Project management tools — task tracking, scheduling, resource allocation. Whether the team used them consistently or abandoned them mid-project
• Communication channels — email, Slack, WhatsApp, phone, shared documents. Whether the number of channels helped (different tools for different purposes) or hurt (information scattered across too many places)
• File storage and sharing — cloud services, local drives, shared folders. Whether there was a single source of truth for project files
• Templates and checklists — pre-built formats for briefs, scripts, shot lists, show notes. Whether they existed, whether they were used, whether they helped
• Automation and AI assistance — any automated workflows, AI transcription, AI-assisted writing or editing. What worked, what produced unreliable output, what required more human oversight than expected

The question: Which tools saved time, which wasted it, and what should we try or drop next time?

How To Write Findings

Each finding in the LESSONS.md follows a consistent pattern. This pattern matters because it makes the document scannable and prevents findings from becoming vague advice.

Pattern: Bold claim. Evidence. Fix.

1. Bold opening sentence — states the finding as a direct claim. This is the lesson in one sentence. It should be bold-formatted so a reader scanning the document can read only the bold lines and understand the key findings.
2. Evidence — one to three sentences explaining what happened that supports the claim. Specific numbers, dates, and examples. No generalities.
3. Fix — one to two sentences stating what to do differently next time. Begins with "Fix:" for easy scanning. The fix must be specific enough to execute without further discussion.

Example of the pattern applied:

Pre-interviews ran too long and duplicated editorial work. Average guest pre-interview lasted 45 minutes; fewer than 10 minutes of usable material came from each. The editorial calls made during pre-interviews (which angles to pursue, which anecdotes to draw out) had to be remade in the recording session because the host had not been present for the pre-interviews. Fix: cap pre-interviews at 20 minutes. Send guests a topic list 48 hours ahead. Have the host present for all pre-interviews, even by phone.

What to avoid:

• Findings without evidence: "Communication could have been better." Better how? Between whom? About what?
• Evidence without a fix: "The timeline slipped by four weeks." What should the next project do about it?
• Fixes without evidence: "Use a project management tool." Why? What problem did the absence of one cause on this project?
• Blame disguised as analysis: "The editor was slow with feedback." Instead: "Feedback rounds averaged 8 days against a planned 3 days. Fix: agree on a 72-hour feedback window at project start, with an escalation path if the deadline passes."
• Generic praise: "The team worked really well together." Instead: name the specific practice that worked — "Daily 10-minute stand-ups kept everyone aligned on what was due that day and caught two scheduling conflicts before they became problems."

Positive findings matter as much as negative ones. A retrospective that only lists failures is not useful — it tells the next team what to avoid but not what to repeat. When something worked, write it up with the same rigour: bold claim, evidence, and a carry-over note that says "keep doing this" with enough specificity that the next team knows what "this" means. The goal is not to balance criticism with praise for diplomacy's sake; it is to capture working practices that might otherwise be forgotten or accidentally changed.

Adapting to Project Type

The six-category framework applies to any media project, but the weight and detail of each category shifts depending on what was made. The skill adjusts automatically based on the project format you describe in the input, but understanding the typical weight distribution helps you provide better notes.

Podcast series: Editorial Decisions and Workflow tend to dominate. Guest selection, episode structure, and the recording-to-edit pipeline carry most of the lessons. Tooling findings are usually about recording equipment, editing software, and transcription. If the podcast involves field recording or location work, Tooling gains significant weight because equipment and environment issues compound across episodes.

Documentary or factual TV: Timeline and Stakeholder Management gain weight. Broadcast deadlines are fixed, commissioner feedback rounds are formal, and post-production is where most schedule pressure lands. Editorial findings often centre on what survived the edit and what was cut — the gap between what was filmed and what made it to screen is where the most useful editorial lessons sit. Budget notes are especially valuable for this format because documentary budgets are tight and overspends in one area always come at the cost of another.

Article series or long-form journalism: Editorial Decisions and Quality are the heaviest categories. Story structure, source selection, and factual accuracy carry the most lessons. Workflow findings tend to focus on the draft-review-publish pipeline: how many revision rounds each piece needed, whether feedback was specific enough to act on in one pass, and where pieces stalled between draft and publication. The researcher and editor roles matter more here than in audio or video formats.

YouTube series: Tooling and Quality carry more weight than in other formats because production values (thumbnails, editing pace, audio quality, colour grading) directly affect audience retention in a way that is immediately measurable. Audience reception data is usually richer for YouTube than for any other format — watch time, click-through rate, retention curves, subscriber conversion — and deserves more detailed analysis in the Quality section. Editorial findings often focus on hook structure, pacing, and the relationship between title/thumbnail promise and content delivery.

Newsletter or email series: Workflow and Stakeholder Management are often thin (small teams, few external stakeholders). Editorial Decisions and Quality dominate — what subjects drove opens, what formats drove clicks, where the editorial voice drifted over the run. Audience data is granular (open rates, click rates, unsubscribe rates by edition) and should be referenced specifically in the Quality section rather than summarised as averages.

Multi-format projects (e.g., a podcast with a companion article series and social media campaign): use the full six categories but add a short "Cross-Format Coordination" note under Systemic Issues covering how the formats connected or failed to connect — whether the release schedule was aligned, whether assets were shared between formats, and whether the audience moved between formats as intended or stayed siloed.

Solo projects: When one person did everything — researched, recorded, edited, published — the Workflow and Stakeholder sections may be very short or empty. That is fine. The skill will not pad these sections with filler. Focus the notes on Editorial Decisions, Quality, Timeline, and Tooling, which are where solo producers tend to find the most reusable lessons. Solo retrospectives are often shorter (400–800 words) but no less valuable — a solo producer has no team to absorb institutional memory, so the written record is the only record.

Quality Criteria

The following criteria apply to the generated LESSONS.md. Each must be met before the document is delivered. If a criterion cannot be met because the input notes do not contain enough information, the document should acknowledge the gap rather than fill it with speculation.