# A cookbook manuscript — recipe development, testing rounds and headnotes for a proposal Recipe No. 25, Kitchen and table. From The know.sh Cookbook: https://know.sh/cookbook/cookbook-manuscript - For: a food writer developing sixty recipes and a proposal for a first cookbook - You bring: recipes in development, a kitchen notebook, a dozen volunteer recipe testers, and a literary agent waiting on the proposal - You get: a document per recipe holding its current version and every testing round, the decisions that settled each one, headnotes in your own words, and a proposal your literary agent can read behind a password - Time: an evening to set up, then twenty minutes after each test and each round of tester feedback, over the months of development - Keep it: private while you work; share one document by a read-only link A recipe in a cookbook has usually been made a dozen times before it is printed. The first test tells you the braise is too sweet; the third, with less cider, is right in your oven and wrong in a tester's gas oven in Denver. By the time the manuscript is due, the question that matters is not "what is the recipe" but "why is it this way", and the answer is scattered across notebook pages, texts from testers and three versions of the same file. This recipe keeps the answer. Each recipe in development is a document whose overview is the current version. Each testing round is a numbered finding: what you changed, what happened, what the testers said. When you settle something, you file a *Decision*. The document's revisions keep every version of the recipe, so round two is one click away when round three goes wrong. Testers read the current version on a password-protected link; your literary agent reads the proposal on another. The assistant you already use, Claude, ChatGPT or a local model connected to know.sh, turns your notebook and your testers' emails into that structure and compares rounds; you fix it up in the editor. The recipes, the method wording and every headnote are yours. ## What you will use - **Shelf**: One shelf for the book, *The Tuesday Braise*, with a line on what the book is and who it is for. - **Research document**: One document per recipe in development, whose overview is the current version of the recipe, plus one document for the proposal itself. - **Finding**: One finding per testing round, filed as *Evidence*; a *Decision* for each thing you settle; a *Question* for what testing has not answered yet. - **Revisions**: Every version of the recipe in the overview, marked with who changed it, with **Restore** when a round goes backwards. - **Public link**: A password link on each recipe for its testers, with the round logs left out, and a separate link on the proposal for your literary agent. - **Your AI assistant**: Builds a document per recipe from your notebook, files each round from your notes and testers’ emails, and compares rounds, without touching the recipe or the headnote. - **The editor**: Where you correct what the assistant filed, edit the recipe in the overview, mark Decisions **Key** and write every headnote yourself. - **Look up**: Look up (⌘K) shows how often leeks turn up across the sixty recipes, and which recipes still lack a Contains line. ## Method ### 1. Give your assistant the notebook Make a shelf named for the book and write a line on what it is: "Sixty braises for weeknights, for cooks with one heavy pot." Then give the assistant you use what you have so far: photos of the notebook pages, your draft recipe files, the testers' emails. Ask it to make one document per recipe on that shelf, titled with the dish and its main ingredients, such as *Chicken thighs braised with leeks and cider*. Each document's overview should be the latest version of the recipe exactly as you wrote it, and each test so far a finding. Ask for a *Proposal* document too, with a finding per section your literary agent expects: *The book*, *The reader*, *Comparable titles*, *Chapter outline*, *Sample recipes*. The assistant makes the headings; the pitch is yours to write. ### 2. Fix up each recipe in the editor Open each recipe and press **Edit**. Check the overview against your latest notes: yield, ingredients by weight and volume, method, and the timings you actually used. The overview is the recipe; the findings are its history. When you change the recipe, edit the overview directly. Revisions keep every earlier version, dated and marked as yours or an assistant's. Drag the rounds into date order, fix any test the assistant misread, and delete what does not belong. Star the recipes going into the proposal, and put the one in testing this week in **Focus**. ### 3. Log every test as a finding After each test, give your assistant your notes and the testers' replies and ask it to file the round in that recipe's document, titled by round and date, *Round 3, 11 March*, as *Evidence*, with the same three headings every time: - **What changed**: one or two changes from the last round, and why. - **What happened**: times, temperatures, texture and taste, in plain words. - **Testers**: what each tester reported, by code (Tester B, gas oven, Denver), never by full name. Read the round before you plan the next one. Change one thing per round where you can; when you change two, say so. ### 4. Send testers the current version behind a password When a recipe is ready for testers, press **Share** on its document, set a password and an expiry at the end of the round, and copy the link the moment it appears. From each finding's own page, leave out the round logs, the Decisions and the headnote draft, so testers read the recipe and nothing else. Add one finding they do see, *How to report back*, with the questions you want answered. Testers reply by email or your feedback form; they cannot write in the library. Their answers go into that round's finding, by you or your assistant. For the next round, **Replace** the link, so last round's testers lose access, and send the new one to this round's. Replacing resets the expiry and the findings you left out, so set both again. ### 5. Ask your assistant to compare rounds Ask your assistant to read two rounds of a named recipe and the overview's revisions, and to file a comparison: what changed, what the testers reported, and where they disagree. Ask it to file that as a finding, not to edit the recipe. An assistant is good at the bookkeeping you skip at eleven at night: noticing that the two testers who found the sauce thin both used a wider pot, or that round four quietly undid a fix from round two. Whether the braise is right is still for your palate to decide. ### 6. File the decisions When testing settles something, file a *Decision* and mark it **Key**: "Bone-in thighs, not boneless: boneless dried out for three of four testers." Link the rounds that decided it. A Decision is what you will point to when a copy editor asks why the recipe calls for a 5-quart pot and not a 7. Then write the headnote yourself, as its own finding, in your own voice. Headnotes are the part of a cookbook that is most clearly yours and most clearly protected; they are also the part readers remember. ### 7. Check the manuscript before it goes out Before the proposal goes to your literary agent, search Look up for each main ingredient. If *leeks* fills the list and *fennel* finds nothing, the book has a habit. Ask your assistant to check every recipe document on the shelf for units written two ways, oven temperatures without °C, and a missing *Contains* line. Share the proposal with its own password and an expiry. When the book is under contract, read what the contract says about recipes appearing online before publication, and turn off tester links the day a round ends. ## Prompts to try Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read every testing round in the document [recipe] on my shelf The Tuesday Braise and the revisions of its overview. Make a table of rounds: date, what changed, each tester’s verdict and their oven and pot. Then list what is still unresolved. File it as a new finding called “Rounds compared”. Do not edit the recipe or the headnote. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, check every recipe document on my shelf The Tuesday Braise. List any overview that writes units two ways, gives an oven temperature without Celsius, has no yield, cooks poultry or ground meat without a safe internal temperature, or lacks a Contains line. Group the list by recipe and put it in a new finding in the proposal document. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, tell me which recipes on my shelf The Tuesday Braise have a Decision finding marked Key and a headnote finding, and which are still missing one or the other. List them in two columns. ## Variations - Keep a [bake log](/cookbook/bake-log) for the bread and pastry chapters, where a round is a single bake and the numbers matter more than the testers. - Use Claude Code to turn the delivery schedule into a campaign: an operation per chapter with testing, headnotes and photography notes, each blocking the manuscript delivery date. - Writing a community cookbook rather than your own? The [fundraiser cookbook](/cookbook/fundraiser-cookbook) collects and checks recipes from many cooks. ## Where it falls short - There is no export. When the manuscript goes to your editor, you copy the recipes into the publisher’s template or your word processor; know.sh remains the record of how each recipe got there. - Testers cannot comment on the link or fill in a form in know.sh. Their feedback reaches you by email or your own form, and you or your assistant file it. - Reading notebook photos needs an assistant that reads images, as Claude and ChatGPT do; smaller local models read handwriting and call know.sh’s tools less reliably. Whichever you use, read what it files; Revisions shows every change. - Photos of each test cannot be stored in the library. Keep them in your photo library, named by recipe and round, and say in the round finding where they are. - Links are one recipe each. Twelve recipes in testing at once means twelve links to manage, each with its own password and expiry. ## A note on food safety, headnotes and your publisher Give every recipe a *Contains:* line listing the major allergens: milk, eggs, fish, crustacean shellfish, tree nuts, peanuts, wheat, soybeans and sesame. Never call a recipe free of an allergen. Where a recipe cooks meat, give the USDA safe internal temperature and tell the reader to use a thermometer: 165°F (74°C) for poultry, 160°F (71°C) for ground meat, 145°F (63°C) with a three-minute rest for whole cuts of beef, pork and lamb. Any pickle, jam or preserve in the book should follow a tested process from the USDA or the National Center for Home Food Preservation; your publisher will ask. A list of ingredients is not protected by copyright; headnotes and method wording are. Write your own. Where a recipe is inspired by another cook's, say so in the headnote. If you quote a tester in the book, ask them first. Many publishing contracts limit how recipes may appear before publication and ask you to confirm the work is your own. Read yours, or ask your literary agent, before sharing more widely, and follow your publisher's policy on disclosing AI assistance. Assistants make mistakes; check every temperature and allergen line yourself, and never let one draft a headnote or method you will sign as your own. Indexed under: Recipe testing, Testing rounds, Recipe testers, Headnotes, Cookbook proposals, Decisions, Allergens, Food safety.