A Guide to Getting Real Editorial Feedback from Claude

How I Use AI to Find the Patterns I Can’t See in My Own Fiction

This walks you through setting up Claude to critique your fiction at the chapter level, the method behind the analyses I’ve been posting about my own work on Inference. It assumes you haven’t used Claude before. It does not assume you need your hand held on the writing; the craft is yours, and the value here scales with how good your work already is.

A key principle: the feedback is only as good as the context you give it. A model reading one chapter gives you generic notes. A model referencing your entire manuscript and craft materials can tell you that a structural move in Chapter 9 is the fourth time you’ve used it, the kind of pattern you can’t see from inside your own book. Most of this guide is about getting your whole work in front of it correctly. The prompts are the easy part.

By the end, you’re not collecting isolated critiques. You’re building a map of your habits as a writer: what reliably works, what reliably weakens the work, and which single revision would improve the most chapters at once. That map is the payoff, and everything below is built to produce it.

---

The easiest way to use this guide

Hand this document to Claude (or whatever AI you use) and say: “I’d like to run the analysis described in this guide. Walk me through the setup steps one at a time and wait for me at each step.” It’ll act as your setup assistant by helping you create the Project, convert your files to markdown, and confirm everything loaded, answering questions as they come up.

IMPORTANT: The chat where you ask for guidance in setting up the process is not where the analysis happens. A standalone chat can coach you through setup, but it can’t see your manuscript. The actual critique happens in the Project you’re about to build, in chats opened inside that Project, where your whole book sits in the knowledge base. So: use any chat as a guide for the steps below; do the real work in the Project. The steps themselves are short enough to just follow directly if you’d rather.

---

Step 1 — Set up an account & project

Go to claude.ai and sign in. Projects are available on the free tier — free accounts can keep up to 5 active Projects at a time, which is plenty for this. (Paid plans raise that limit and the usage ceilings, which matters if you’re running a long manuscript through in one sitting, but you can start for free.)

In the left sidebar, you’ll see Projects. A Project is a workspace with its own knowledge base and its own chat history, separate from one-off chats. Everything you put in a Project’s knowledge is available to every conversation you start inside that Project, without re-uploading. That shared, persistent knowledge base is what makes chapter-by-chapter analysis possible.

(An aside: plan features and limits change over time. The free-tier details above are current as of writing, but if Anthropic revises what the free account includes, parts of this guide may go out of date.)

Click Projects → Create project. Name it something like “[Your Novel] — Editorial.” You’ll land on the project page. The panel for adding files is usually labeled Project knowledge (sometimes shown as “Add content” or a paperclip/upload control). That panel is where your manuscript goes.

Step 2 — Prepare your manuscript as markdown files

Save each chapter as its own file in Markdown (.md), one file per chapter, named so the order is obvious (Chapter_01.md, Chapter_02.md. Zero-pad the numbers so they sort right).

Use Markdown rather than .docx because it's already plain text. The model reads your actual words instead of reconstructing them from a layout file, which keeps the thing being analyzed accurate, and it's lighter, so you get more working room in a long session.

How to convert — two routes:

• Let the AI do it. Drop a .docx chapter into a chat: “Convert this to clean Markdown — preserve italics, bold, and scene breaks, and return it as a .md file.” Do a whole manuscript in batches.

• Export it yourself. Google Docs: File → Download → Markdown (.md). Many writing tools — Scrivener, iA Writer, Obsidian, pandoc — export Markdown directly too; check the export menu. Word is the exception: it usually needs an add-in, a converter, or the AI route above.

(Edge case: if a piece’s meaning depends on visual layout text can’t carry — concrete poetry, spatial typography, columns — upload it as a PDF instead. Claude can read many PDFs visually, including layout, though very long PDFs may be handled mainly as extracted text. For ordinary prose with italics and scene breaks, Markdown is better.)

Step 3 — Add your craft materials too

If you have anything you’ve written about the book, add it to Project knowledge alongside the chapters:

• character sheets/bibles

• a story outline or arc summary

• a style guide or prose rules, if you keep one

• a thesis or theme document

• any worldbuilding reference

This is what separates good feedback from exceptional feedback. With your character bible loaded, the critique can tell you a scene contradicts established canon. With your style rules loaded, it can flag where the prose violates your own standards rather than some generic ideal. The more it knows about what you’re trying to do, the more precisely it can tell you where you missed.

Upload all of it to the same Project knowledge panel as Markdown files where you can, same as the chapters.

Step 4 — Confirm it loaded

Start a new chat inside the Project (open the Project, then New chat — make sure the chat is inside the Project, not a standalone chat; the Project name should show at the top). Type:

List every file you can see in this project’s knowledge, in order.

You should see a list of all your chapters and craft docs. If anything’s missing, re-add it before going further. Don’t start the analysis until the file list is complete and correctly ordered.

Step 5 — Run the first chapter

In that same chat post the following Prompt:

Analyze Chapter 1 in detail. Rate it 1–10 against the best comparable fiction in its genre. Name the specific authors or books you’re grading against, and grade against that ceiling, not against genre-average and not against “good for a draft.” Then tell me, specifically, what it does well and what it does poorly from a reader-engagement standpoint, where a reader leans in, and where a real reader would slow down, skim, or drift. Be concrete, specific, and honest. Flag weaknesses plainly and explain why they’re weaknesses. Reference my other chapters and craft documents where relevant.

Why this prompt specifically;

• “against the best in the genre” - without a named, high ceiling, the rating drifts upward and the praise goes vague. Naming the comparison set forces a real standard.

• “from a reader-engagement standpoint” - this redirects the model from abstract literary appreciation to the one question that produces useful notes: where does a reader’s attention actually go, and where does it leak.

• “concrete, specific, and honest / flag weaknesses plainly” - models default to kindness. You have to license criticism explicitly or you’ll get cushioning.

Step 6 — Work through the book in order, comparatively

For every subsequent chapter, same prompt with one addition:

Analyze Chapter 2 in detail [...same prompt...]. Also, how does it compare to the previous chapters? What does it do better or worse, and what has the writing learned or stopped doing?

Go in sequence, one chapter per message. The comparative thread is where the highest-value insight lives. The model builds a picture of your trajectory across chapters, so it can tell you not just “this chapter sags here” but “this is a habit you’ve had since Chapter 1” or “you fixed in Chapter 8 the thing you struggled with in Chapter 3.” You only get that by going in order and asking for the comparison every time.

Step 7 — Build a shared vocabulary

After the first chapter or two, add:

As we go, name the recurring strengths and flaws you find in my writing, and reuse those names in later chapters so we build a consistent vocabulary for my patterns.

By the end, you’ll have a personal craft glossary that names the specific things you reliably do well and the specific traps you reliably fall into, tracked throughout the whole book. That glossary is more useful than any single chapter’s notes, because it’s diagnostic of you, not of one scene.

Step 8 — Argue when it’s wrong

Treat each analysis as a draft, not a verdict. When it misreads your intent, correct it. When it flags something you did deliberately, tell it why and make it reckon with that. When you think it’s wrong, say so and push.

This is where the best output comes from. The first read is the model’s opening position; the sharp insight tends to arrive two or three exchanges later, after you’ve corrected a wrong assumption and forced a revision. A model that simply agrees with you is worthless. A model you genuinely argue with becomes a real editor. Make it defend its reads, and make it account for your intentions, and the quality climbs.

---

Step 9 — Generate an improvement plan

Once you’ve worked through every chapter, the individual analyses are useful but scattered across separate critiques you’d still have to integrate yourself. Instead, you want a single, prioritized, by-chapter improvement plan. Ask for it explicitly using the following prompt, in the same chat, after the full pass:

Now synthesize everything. Pull all the chapter analyses into one prioritized improvement plan. Specifically:

1. Name the significant recurring flaws that show up most often. The habits that, if fixed, would improve the most chapters at once. Explain the mechanism: what I’m doing, why it weakens the work, and what it looks like in each place it appears.

2. Give me the rating curve across all chapters and tell me what it actually tracks: is the trend real growth, or something else?

3. For each chapter: what to protect (what I must not break while revising), the single highest-leverage fix, and why that fix matters from a reader’s standpoint.

4. Triage by leverage - order the fixes from most to least impactful, so I know what to do first. Separate the pure craft fixes (safe to make anytime) from anything that needs a bigger structural decision.

What a good synthesis contains

If the output is doing its job, it will have:

• A named core diagnosis. Not a list of unrelated problems but the underlying habits driving most of them. The most useful insight in my own run was that nearly every per-chapter flaw was the same flaw expressed in different ways throughout the story.

• Per-chapter protect/fix/why. The protect line is the one most analyses omit and the one that saves you: it names the strength you might accidentally optimize away while fixing a flaw. A more-correct chapter that’s lost what made it sing is a worse chapter.

• A leverage order. Some fixes are purely reader-experience and safe to make tomorrow. Others depend on a structural decision you haven’t made yet. A good synthesis separates them so you don’t break load-bearing architecture chasing a small gain.

A final note:

Order of operations matters. The synthesis only works after the sequential, comparative pass. Ask for it cold, without the per-chapter analyses behind it, and you’ll get generic writing advice. It’s a capstone, not a shortcut; it’s summarizing work already done, not doing the work.