Methodology packs

A methodology pack is a body of narrative craft turned into rules the pipeline can actually execute: structure slots, generation instructions, critic criteria and pacing constraints.

It is not a template library. A template gives you a shape to fill in; a pack takes part in generation and validation — its rules go into the prompts, its checklist runs against what comes out, and its pacing constraints are checked mechanically.

What is in one

Four buckets, and anything that does not fit them does not belong in a pack:

Bucket	What it holds
Beat archetypes	Structural slots: name, function, suggested position range, emotional charge hint
Prompt fragments	Operational rules injected per stage — structure, characters, production, critique
Critic checklist	Criteria with a rubric for judging any given text against them
Pacing rules	Quantifiable constraints, such as how many low-charge beats may run consecutively

Industry anecdotes, historical background and the author’s biography do not go in a pack. Neither does anything that cannot change either what gets generated or how it gets judged.

Where this stands today: the pipeline ships with three packs — three-act, Save the Cat and the hero’s journey — and new projects use three-act. Choosing between them, and installing a pack of your own, is not exposed in the app yet. The rest of this page describes how packs are built, because that is what determines whether the idea is worth anything; it is not a self-serve feature you can use today.

The two rules a pack has to obey

Distil, do not pour in. A pack holds rules in your own words, never the source text of a book. Beyond the copyright problem, verbatim prose is actively bad input: the engine needs stable “when X, do Y” rules, not discursive argument. The test is simple — every line in a pack should be something you could write after closing the book.

Every rule must be operational. If a rule can change neither what gets generated nor how it gets judged, it is not a rule, it is a sentiment. “Narrative should move people” — cut. “Every major character must make one choice that exposes their core flaw before the end of act one” — keep.

How a pack gets made

1 · Read and take operational notes. Read outside the tool. Every time the book gives a rule, template, checklist or formula, write one note in your own words and tag which bucket it belongs to. Page numbers are for your own re-checking; they do not go in the pack.

2 · Sort and de-duplicate. Drop anything an existing pack already says. A pack should carry only what is genuinely this book’s contribution — duplicated rules dilute the prompt when several packs are combined.

3 · Draft. Turn your notes — not the book — into the pack format. Every prompt fragment has to be an imperative, executable instruction; every rubric has to let a reviewer reach a definite verdict on an arbitrary piece of text.

4 · Revise by hand. Three passes: does each rule survive the operational test; does anything still read like the book’s prose; and can each rubric actually be applied — take a piece of your own old writing and try scoring it. A rubric you cannot apply is a rubric to rewrite.

5 · Lint and dry-run. Validate the pack’s shape, then run a stage with it and look for two things: can you find traces of three to five of its rules in what came out, and did its checklist items show up in the critic report.

6 · Bake off. Run the same project through two packs and compare: validation pass rate, how many revision rounds it took to converge, cost, and quality scores. Losing on the numbers does not mean a pack is worthless — it may suit a different kind of project — but the numbers are what you decide on, instead of taste.

Combining packs

Prompt fragments are concatenated in the order the packs are declared, so order is priority: where rules conflict, the later pack wins, and the engine says so in the prompt rather than leaving the model to guess.

Beat archetypes are unioned, and two packs claiming the same slot name is a validation error — rename one. Critic checklists are unioned and de-duplicated by criterion.

In practice: activate one structural pack, not several. Structural frameworks fight each other. Production and critique packs stack fine.

Common failure modes

Symptom	What it means	Fix
Fragments read like the book	You poured instead of distilling	Close the book and rewrite; if it fails the “could I have written this” test, cut it
Output shows no sign of the pack	The rules are too abstract	Add a trigger and an action: when X, do Y
The critic gives different verdicts on the same text	The rubric is not applicable	Rewrite it as an answerable question plus explicit grading conditions
Prompts get diluted and costs rise	The pack is too big	A book is usually worth 5–15 genuinely distinct rules. Cut to that
Bake-off shows no difference from the baseline	De-duplication was not done properly	Keep only this book’s increment

Versions and dirty propagation

Packs are versioned. Any version change marks the artifacts that used the pack as dirty in the dependency graph — this is intended, not a nuisance: a rule changed, so what the rule produced is now open to question. You then choose whether to regenerate or merely re-validate.