serial_fiction_publishing v1.0.0

name: serial_fiction_publishing description: Publish fiction in serial episodes on reader platforms: episode length and ending hooks, a release cadence readers can rely on, tags and blurbs matched to how platform search works, reading comment patterns to adjust pacing, and what to do when a chapter underperforms. Platform-neutral across Wattpad, Royal Road, Tapas, Radish-style coin apps, Ream, Patreon, and Substack, with a worked launch calendar and comment-driven pacing rules. Use when launching, scheduling, packaging, or diagnosing a serialized story.

Serial Fiction Publishing

Purpose

Run a serialized story as a publishing operation, not as a novel chopped into pieces. Each episode has to work on its own, end with a reason to return, land on a schedule readers can predict, and be findable through the search and list systems of the platform it lives on. This skill covers platform choice, episode design, launch, cadence, packaging, comment reading, and recovery when an episode falls flat. It stays platform-neutral: the same story bible and episode files should be able to move platforms without a rewrite.

Workflow

1. Pick the platform by reader habit, not by hype

• Match genre to where that genre already reads in serial form. Progression fantasy and LitRPG concentrate on Royal Road. Romance, YA, and fan-adjacent original fiction concentrate on Wattpad. Mobile coin apps such as Radish built their model on short genre episodes, mainly romance, read on phones. Tapas mixes prose and comics and suits short episodes read in brief windows. Ream and Patreon suit an author who already has readers willing to pay for early or bonus chapters. Substack suits an author who wants an owned email list and can bring most readers themselves.

• Check four facts in the platform creator dashboard or help center on the day you commit, and record them in the story bible: allowed episode length, scheduling tool and how far ahead you can queue, how discovery works (search tags, hot lists, rising lists, recommendations, or none), and how readers pay (free, coins or ink, subscription, patron tiers). Platforms change these numbers. A number remembered from last year is not a fact.

• Treat closure risk as real. Amazon closed Kindle Vella on February 26, 2025, after announcing the shutdown in October 2024. Keep your master files, metadata, and reader list off-platform from day one: plain text or Markdown episodes, a spreadsheet of titles and tags, and an email list or other owned channel you control. Never let the platform be the only copy.

• Choose one primary platform for launch. Cross-post later only after the primary cadence holds for at least one full season, and adapt packaging per platform instead of pasting the same blurb and tags everywhere.

2. Design episodes, do not slice a novel

• Give each episode a complete small arc: an opening that orients the reader in two or three lines, one clear change (a discovery, a decision, a reversal, a cost paid), and an ending hook. A chapter cut in half mid-scene fails this test. Move the cut or rewrite the join.

• Set a target band per platform and hold it steady. Consistency matters more than any single ideal number.
• Wattpad official guidance: keep chapters short, about 2,000 words, because most readers read on mobile on the go.
• Royal Road common practice: 1,500 to 5,000 words per chapter, with many guides landing at 1,500 to 2,500. A 277-story Royal Road dataset found near-zero correlation between chapter length and ratings or followers, so do not chase length as a ranking trick.
• Mobile coin apps: about 2,000 words per episode was the Radish model described by Publishers Weekly, with a conversational style built for phones.
• Owned channels (Substack, Ream, Patreon): 1,200 to 2,500 words fits an email sitting and a paid early-access drop. Longer is workable if the cadence stays weekly or slower.
• Pick one band, write it in the bible, and audit against it with scripts/episode_audit.py. A swing of more than about 40 percent from your own median needs a reason, such as a finale.

• Rotate hook types so readers do not learn to ignore them. Use one per episode and log it.
• Mid-crisis cut: stop at peak danger before the outcome.
• Reveal cut: give a new fact that reframes what came before, then stop.
• Decision cut: a character commits to a choice with a visible cost, outcome unseen.
• Arrival cut: someone or something expected, or feared, shows up.
• Promise cut: end on a concrete question the next episode will answer, stated in scene, not in an author note.
• Quiet cut: end a heavy episode on a small resolved beat and one changed relationship. Use these on purpose every four to six episodes. All crisis, all the time, trains readers to skim.

• Reorient returning readers without recapping the whole story. Open with place, person, and pressure in the first lines. Add a formal recap episode or a short previously-on note every ten episodes or at a season break, and keep a linked index page on owned channels so late joiners can start at episode one in one click.

• Build a backlog before launch. Bank 10 to 15 episodes before episode one goes live, or enough to cover eight weeks at your chosen cadence, whichever is larger. Launch with a block readers can sample: about 20,000 words live on Royal Road style launches is a common practitioner target, five to ten episodes is the usual floor on other platforms. The backlog is what protects the schedule when life intervenes.

3. Set a cadence you can hold, then publish the promise

• Choose cadence from backlog and writing speed, not ambition. Wattpad official guidance is 1 to 3 new chapters a week with a regular schedule. Wattpad Originals serialization asks for at least once a week. Royal Road schedules cluster around daily, Monday to Friday, or three days a week, and daily only works with a deep backlog. Weekly is a defensible floor on every platform.

• State the promise where readers see it before they start: in the blurb, in the story details, and in the welcome or pinned post. Follow the Wattpad help example and write it plainly, for example: New episodes every Tuesday and Friday.

• Plan in seasons. Wattpad serialization guidance treats each five months of posting as one season, with a one-month break after it. End a season with a smaller wrap that closes the season question and leaves the larger questions open. Never start a hiatus with a character in immediate peril and no resolution at all. Announce the return date before the break starts.

• Queue ahead with the platform scheduler where one exists and keep at least two episodes queued at all times. If you miss a slot, post a short notice in the story feed the same day, state the new date, and hit it. Silence breaks serials faster than a late episode does.

• Generate the calendar before launch with scripts/launch_calendar.py and paste the result into the bible. The worked example in references/launch-calendar.md shows an eight-week, twice-weekly launch with a season break.

4. Package for how each platform is searched

• Write the blurb in this order and stop: protagonist and situation in one line, the problem that will not wait, what makes this version different, the cadence promise, and one content note if the story needs it. Wattpad caps descriptions at 2,000 characters and says stories with descriptions get far more reads than stories without one. Test the blurb by reading only its first two lines: a stranger should know genre, protagonist, and stakes from those lines alone.

• Build tags from search behaviour, not from adjectives you like.
• Layer them: 2 to 3 genre tags, 3 to 5 trope tags readers actually search (for example enemiestolovers as a single token where the platform requires one-word tags), 2 to 3 setting or format tags, 1 to 2 audience tags, and the rest for themes the story truly delivers.
• Respect the platform format. Wattpad allows a maximum of 25 tags, tags are one word with no spaces, periods, or hyphens, and the same tag set applies story-wide. Wattpad rankings weigh tag relevance and accuracy, plus popularity, engagement, and how recently the story updated, and ranked stories surface on the Hot List for that tag.
• Cut any tag the first ten episodes do not deliver. A mismatched tag brings the wrong readers, and wrong readers leave quiet, rating-damaging drops.
• Revisit tags at each season break, not weekly. Ranking systems need stable signals, and constant tag churn makes results unreadable.

• Make episode titles do work. A title should carry a concrete noun or a tension cue, not just a number. Keep numbering in the platform field if it has one, and keep titles short enough to read in a list on a phone.

• Set the cover and title for thumbnail size first. Check both at the size they appear in search results, in black and white as well as colour. If the title cannot be read at that size, the cover fails regardless of how it looks full-screen.

5. Read comments as pacing data

• Collect comments after every episode into the log in references/comment-patterns.md. Sort each comment into one bucket only: confusion (reader cannot follow who, where, or why), drag (reader reports skimming or waiting), delight (a named character, line, or beat they praise), demand (a named thing they want more of or want answered), and theory (reader predicts what happens next).

• Act on patterns, not on single voices. Rules that hold across platforms:
• Three or more independent confusion comments on the same point in one episode means the episode has a clarity fault. Fix the episode if the platform allows edits, and reorient faster at the next opening regardless.
• Drag comments rising for two episodes in a row means the arc has stalled. Bring the next promised payoff forward by one episode, or cut the subplot scene that is holding it.
• Delight concentrated on a side character for three episodes means readers have voted. Give that character a scene with real consequence within the next three episodes. Do not promote them to lead on comment pressure alone.
• Theory comments that guess your twist correctly and early mean the foreshadowing is too loud. Do not swerve into a weaker twist to stay unpredictable. Tighten later clues and keep the earned ending.
• Demand for faster release with stable read numbers means cadence is working. Bank the pressure as goodwill. Do not speed up past what the backlog supports.

• Reply like a host, briefly. Wattpad guidance is to respond to comments, engage readers in conversation, and include an open question or call to action in the story text. Ask one specific question per episode, about a choice or a prediction, not a generic request for comments. Never argue with a critic in the thread, never promise a plot change you have not decided, and never reveal future plot to win an argument.

• Track five numbers per episode in a simple sheet: views or opens, completions or votes/likes where the platform shows them, comment count, new follows or subscribers, and drop-off compared with the previous episode. Without those numbers, comment reading turns into mood reading.

6. Diagnose an underperforming episode before reacting

• Define underperforming against your own baseline first: views or completions down 30 percent or more against your trailing five-episode median, for the episode and the one after it. One soft episode is noise. Two in a row is a signal.

• Run the checks in order and fix the first fault you find:

1. Packaging fault: wrong or stale tags, a title that changed style, a missed scheduled slot, or the episode posted at an unusual hour. Fix packaging and wait one episode before touching the story.
2. Hook debt: the previous episode ended on a quiet cut or a resolved beat, so readers felt finished. Repair by opening the next episode with immediate pressure and restoring a stronger hook rotation.
3. Orientation fault: new readers or returning readers could not re-enter. Confusion comments will show it. Add orientation lines and an index or recap link.
4. Stall fault: no change happened in the episode, only travel, talk, or setup. Move a payoff into the next episode and cut setup that pays off more than three episodes later.
5. Promise fault: the episode broke an expectation the blurb or tags set, such as a genre beat readers came for going missing for several episodes. Restore the beat or correct the packaging honestly.
6. Off-platform fault: a platform outage, a list change, or a holiday week. Check dates against known platform or calendar events before rewriting anything.

• Do not delete and repost a weak episode, do not rewrite published episodes in a panic, and do not change cadence mid-dip. One measured fix per episode, logged with its result, teaches you what actually moves your numbers. If three episodes in a row fall after fixes, pause promotion, finish the season arc early with a proper wrap, and relaunch the next season with new packaging and a rebuilt backlog.

Output Contract

When planning or running a serial, deliver these in order:

1. Platform decision: primary platform, the four verified facts from step 1, and the off-platform backup plan.
2. Episode spec: target word band, hook rotation, recap interval, and backlog count at launch.
3. Launch calendar: dated episode list for at least eight weeks, with launch block, regular slots, recap or bonus slots, season end, and hiatus return date. Use scripts/launch_calendar.py output or the format in references/launch-calendar.md.
4. Packaging pack: final blurb within the platform character limit, layered tag list with format checked, episode title style, and the cadence promise line exactly as it will appear.
5. Tracking sheet header: episode, date, words, hook type, views, completions or votes, comments by bucket, new follows, and fix applied.
6. For a diagnosis: baseline comparison, fault found from the step 6 order, one fix, and the episode where its result will be judged.

Operating Rules

• Never invent a platform number. Episode limits, tag limits, fees, thresholds, and scheduling features must come from the platform help center or creator dashboard checked for this project, or from references/platform-specs.md with its date noted. If a number cannot be verified, say so and design without it.
• Never recommend Kindle Vella as a live publishing option. It closed on February 26, 2025. Cite it only as a portability warning.
• Keep master files off-platform. Episodes, bible, tags, and covers live in the author files first, platform second.
• One primary platform at launch. Cross-posting before the first season holds spreads a thin audience thinner.
• A schedule you miss silently is worse than a slower schedule you keep. Downgrade cadence openly rather than drifting.
• Comments steer pacing and clarity. They do not take over plot, character, or ending decisions. Log demands, act on patterns, keep authorship.
• Vary hooks on purpose and log the type per episode. An audit that shows five mid-crisis cuts in a row is a pacing problem, not a style.
• Edit published episodes only for clarity faults, typos, and broken continuity. Note substantive edits in the episode or author note where readers will see them.
• Style law for everything this skill generates: no em dashes, plain direct prose, no filler.

Available connectors

• Use muse.connector_search to find other connectors and muse.skill_search to find related skills.
• If nothing here fits, look on the web for a maintained API or MCP server and set it up with Custom Connectors and MCPs, or build a custom connector.

Websites

• Wattpad Help Center at support.wattpad.com for tag rules, description limits, ranking factors, and serialization guidance. Verify current limits there before packaging.
• Royal Road at royalroad.com for chapter publishing, Rising Stars and genre lists, and the Latest Updates surface. Check the author dashboard for current scheduling and tag options.
• Tapas at tapas.io for Ink-based episodes and Wait Until Free style reading. Verify creator terms in the dashboard, as program thresholds change.
• Ream at reamstories.com and Substack at substack.com for owned-channel serials. Verify current fees and section or chapter tools before committing a paid tier.