tv_series_development v1.0.0

name: "tv_series_development" description: "Develop a television series that can run for seasons: build the series engine in six fields, test whether the premise generates episodes instead of one story, wire a character web where every pair carries conflict and need, write the pilot so it runs a typical episode in full, shape a season with a midpoint turn and a finale that changes the status quo, and keep three bible tiers separate. Ships a runnable series auditor and one complete worked example, a family funeral home drama, with pilot beat sheet and 8 episode season outline. Use when someone has a TV show idea, a pilot, or a series bible to develop or fix, asks whether a premise can sustain a series, or needs a season outline." metadata: { "includeInPrompt": true }

TV Series Development

Purpose

Turn a show idea into a series that keeps generating episodes. A pilot is one episode. A series is a machine that produces episodes under pressure, with the same people, in the same place, without running dry or repeating itself. This skill builds that machine in a fixed order: engine first, character web second, pilot third, season fourth, bible last. Reversing the order is the common failure. Writers polish a pilot for a show that has no engine, then discover in episode three that there is nothing left to write.

The method works for one hour drama and half hour comedy, broadcast, cable and streaming. Act counts and page ranges below are the typical shapes reported in curriculum and craft sources, not rules any network guarantees. A buyer's own format requirements beat every default here.

Workflow

1. Classify the idea before developing it: series, feature, or limited run. Ask what happens the week after the pilot. A series idea contains a situation that keeps producing conflict on its own. A feature idea contains one journey toward one resolution, and it ends when the resolution lands. A limited idea contains a strong arc with a planned end and no weekly generator. Say which one the user has, plainly, before building anything. A feature idea can become a series: move the story to after the big decision and build the machine that keeps retesting it. The worked example does exactly this with an inheritance premise in references/worked_example.md.

1. Write the engine in six fields, one sentence each. No field may be left vague.

• Arena: the place, job, family or situation episodes return to.
• Protagonist drive: what the lead wants every week, stated as an ongoing want, never a one time goal.
• Built in opposition: the force inside the situation that makes the drive hard by design. It should be a condition, a rival institution, a rule of the world or a person whose job opposes the lead's job. A single villain who can be defeated is not built in opposition.
• Episode trigger: the recurring event that starts an episode, a case, a guest, a death, a delivery, a crisis, an assignment.
• Reset rule: what returns to normal at the end of an episode so the next one can start.
• Change rule: what never resets, the debts, relationships, reputations and season pressure that move a step each episode. Then compress the six fields into one engine sentence: every week, [trigger] forces [lead] to [drive] against [opposition], and it costs [change]. If the sentence needs the pilot's backstory to make sense, the engine is not written yet.

1. Run the generation test before writing any script pages. Draft 20 episode loglines from the engine alone, fast, without using the pilot's events. Each logline needs a different trigger, not the same trigger in a new costume. Count how many arrive without strain. Under 12 means the premise is thin: widen the arena, add a second trigger source, or strengthen the opposition. Then apply the long view test named for an old syndication benchmark: traditional US syndication wanted about 100 episodes, usually a fifth season, and producer David Victor's version of the test was that you should be able to see episodes 35 and 49 clearly before you begin. Sketch episode 35 and episode 49 in two lines each. If both sketches are just the pilot again with new guest stars, the engine repeats instead of generating, and step 2 needs another pass.

1. Choose the continuity setting and write it down: episodic, serialized, or hybrid. Episodic means each episode completes its own story and the status quo resets, which suits case and workplace shows and lets new viewers enter anywhere. Serialized means plot and character change carry across episodes and later episodes depend on earlier ones, which suits season long mysteries and gradual character change and rewards watching in order. Hybrid, the common modern default, closes the episode story while the change rule keeps moving underneath. The choice is a promise to the viewer, so pick it on purpose: it sets how much the finale may change, how much exposition each episode owes a new viewer, and how the reset and change rules divide the work.

1. Build the character web, not a cast list. For each regular write four things: ongoing want, flaw that generates story, role in the engine, and the actable trait another character can play against. Then build the pair matrix. Every pair of regulars needs two entries: a conflict, the thing they will reliably fight about, and a need, the reason they stay in each other's lives anyway. Conflict without need means the pair separates in episode two. Need without conflict means the pair has warmth and no scenes. Run the alone together test: pick any two regulars at random and pitch the scene where only they are in the room. A pair that cannot carry that scene is a hole in the web. Cut the character, merge the character, or write the missing conflict. Five regulars means ten pairs. The auditor in step 9 computes the density for you.

1. Give each regular a season step, not a season arc speech. A season step is one irreversible move per regular per season: a debt taken on, a signature given or refused, a skill mastered, a lie told that cannot be untold. It must be small enough to play inside episodes built on other people's triggers, and it must connect to at least one pair conflict so other characters can push it. Arcs that only move in the finale were never arcs. Spread the steps: one early, one at the midpoint, one in the penultimate episode is a workable spread for a short season.

1. Write the pilot to prove the engine, and ban the premise pilot. A premise pilot spends its acts setting up the situation: the arrival, the inheritance, the first day, the origin. It proves the show can start. It does not prove the show can run. A proof pilot runs one complete typical episode of the engine, trigger to resolution, at full difficulty, and lets the setup arrive inside that episode as action and friction. Rules that enforce this:

• The A story is a normal episode of this show, only slightly larger. If a later episode could not have the same shape, the pilot is a movie in disguise.
• The protagonist's core want stays unresolved at the end. Resolving it ends the series in episode one. The pilot may win the day. It may not win the want.
• The built in opposition appears as a recurring force with a price attached, not as a speech about future trouble.
• Backstory enters only where the present episode forces it out. Any scene that exists to explain the past and does no present work gets cut or converted.
• The pilot ends by stating the new status quo the series will live in from episode two on: who is where, what pressure is now permanent, what clock is ticking. Shape the acts to the format. One hour: a teaser of 2 to 4 pages that hooks before the titles, then four or five acts, total script length typically 45 to 65 pages. Half hour: a teaser or cold open of 2 to 3 pages, then two or three acts and an optional tag, typically 22 to 32 pages single camera and longer for multi camera. Streaming episodes keep the act turns even when nobody writes the act breaks: each act still ends on a turn that changes what the next act can do. Run an A story on the engine, a B story on a pair conflict from the web, and, where the format uses one, a short C story or runner for tone.

1. Shape the season by proportions, then lay episodes into it. Whatever the order size, a season needs the same five jobs done.

• Premiere: run the engine cleanly, open the season question in concrete form, and end with the status quo the season will spend itself disturbing.
• Early episodes: vary the trigger source each time so the audience learns the range of the show, not one trick.
• Midpoint turn: an episode, near the middle, after which the season question means something different. Help accepted that cannot be unaccepted, a fact learned that cannot be unlearned, a line crossed. Without this turn the back half repeats the front half at higher volume.
• Late episodes: raise personal cost. The engine starts charging the regulars, not just the guests.
• Penultimate and finale: the penultimate episode breaks the pattern, often by moving the trigger inside the family or team. The finale answers the season question, pays the change rule in full, changes the status quo in a way episode one of next season must live with, and opens the next season question in specific terms. A finale that restores the premiere's status quo teaches the audience that change does not stick. For episode counts, plan proportions rather than slots: in an 8 episode season the midpoint is episode 4 or 5, in 10 it is 5, in 13 it is 6 or 7, in a 22 episode broadcast season the same jobs stretch across sweeps periods and the midpoint turn often lands twice, once per half. Keep a used trigger list as you outline. A repeated trigger is a confession that the engine stalled.

1. Audit the spec before anyone calls it a series. Encode the work as JSON in the shape of scripts/example_spec.json and run python3 scripts/series_audit.py spec.json. The auditor checks engine completeness, character web density with a 60 percent floor, isolated regulars, pairs with conflict but no need, repeated episode triggers, a pilot that resolves the core want or runs on backstory only, and a season with no midpoint turn or finale. Fix every failure it reports. Its warnings deserve answers in writing, not silent acceptance. The auditor cannot judge taste, dialogue or whether a trigger is fun. Those stay human calls, made by reading the loglines aloud and cutting any that get the same laugh or the same gasp as the one before.

1. Write the bible in three tiers and never merge them. The tiers have different readers and different jobs, and merging them produces the bloated document nobody reads.

• Pitch bible, typically 5 to 15 pages: title, series logline (the engine, not the pilot), world and tone, the engine in one page, main characters with want, flaw and web position, pilot synopsis, first season episode loglines, and a short paragraph per future season showing the engine at a larger scale. Its job is to answer one question: can this run for years.
• Season bible, internal, written before each season: the season question, midpoint turn, finale state, each regular's season step, the trigger list with used triggers marked, and the facts the season must not contradict.
• Living bible, kept during production: everything the show has stated on screen, episodes summarised, funerals staged or cases closed and how, prices, dates, names, places and history as revealed. Historically this was the original bible, compiled as a show ran so new writers could learn what had been done and what the show would never do. New writers read this tier. Founders of the show reread the pitch tier at renewal time to check the show is still itself.

Output Contract

• The verdict on the idea: series, feature, or limited run, with the one sentence reason.
• The engine in six fields, one sentence each, plus the compressed engine sentence.
• The generation test result: the 20 loglines or the count honestly reached before strain, the distinct triggers counted, and two line sketches of episode 35 and episode 49.
• The continuity setting chosen and what it promises the viewer.
• The character web: each regular's want, flaw and role, the pair matrix with conflict and need for every pair, web density from the auditor, and any pair that failed the alone together test with the fix applied.
• The pilot plan: format and act shape, the typical episode it runs in full, how the opposition enters, what backstory was cut or converted, and the closing status quo.
• The season outline: one logline per episode, the season question, the midpoint turn named, the penultimate break, the finale's changed status quo and the next season question.
• The bible set: pitch bible contents at pitch length, plus the season bible and living bible started as separate documents or sections with owners named.
• The auditor report, pasted or summarised with verdict, failures fixed, and warnings answered.

Operating Rules

1. Engine before script, always. No pilot pages, no dialogue polish, no casting talk until the six fields and the generation test pass. A beautiful pilot for a show with no engine is a short film with a series budget problem.
2. Every factual claim about formats, page counts, act counts and industry practice must trace to a checked source. Page and act ranges in this skill are typical shapes from curriculum sources. Present them as ranges that vary by network, format and era, never as requirements.
3. The pilot resolves the episode and never the series. Check the ending against the protagonist's core want by name. If the want is won, lost for good, or exposed as empty in episode one, rewrite the ending.
4. No regular without a web. A character who only connects to the protagonist is a guest with a contract. Either wire them to the others or write them as a guest.
5. Triggers must differ in kind, not just in guest star. Keep the used trigger list from the first outline onward and check every new logline against it.
6. Change must stick. The change rule only moves forward. If a later episode quietly restores a debt, a rift or a reputation that the change rule already spent, flag it as a continuity break, not a reset.
7. Do not copy an existing show's engine and rename the arena. Borrowing a format shape is normal craft. If the engine sentence of the new show works word for word for an existing show with the names swapped, the idea is a cover version and needs its own opposition and cost.
8. Keep the three bible tiers in separate files or clearly separated sections, and date each one. A pitch bible updated with production facts stops pitching. A living bible written as a pitch stops recording.
9. Style for all delivered documents: plain craft language, complete sentences, no em dashes. State what an episode does and what it costs the characters. Skip praise words about the premise itself.