Fixing Claude’s Output

This article is one chapter of my book Delphi in all its glory – AI-assisted development, the fifth book of the series.

Somewhere around Opus 5 a new complaint started showing up everywhere: the model got smarter and the answers got harder to use. Not wrong. Harder to use. You ask a small question and you get an essay written in a dialect you never agreed to learn.

It is worth being precise here, because this is not one problem. It is three, and they arrive at your desk in the same sentence – “I can’t read what Claude writes” – which is exactly why people fix the wrong one and give up.

Problem one is jargon. The model reaches for the compressed technical word every time, and it assumes you already speak the sub-field. Ask it why a form flickers on resize and you get “the invalidation cascade is being triggered by a synchronous relayout of the parent’s client rect during WM_SIZE”. Every word in that sentence is defensible. Together they are a wall.

Problem two is length. You ask something small and you get twelve paragraphs. This one costs you twice: your reading time, and output tokens, which you pay for.

Problem three is a wrong name, and it is the one nobody separates from the other two. This is a real case from a Delphi forum. A developer was working on an old program that launches other programs from a main menu, with the list of them kept in an INI file. Claude decided to call that list an “Application Repository”:

Claude Code kept calling it an Application Repository, which is technically correct I guess, but I kept thinking of it as a Windows Repository. After explaining that to Claude Code, it asked if “Application Catalog” was better which worked great for me – much easier to read and no more confusion.

Look at what that is. “Application Repository” is not jargon. It is grammatical, it is descriptive, and a stranger reading the code would nod at it. It is simply not what that list is called in this project.

That is the difference that decides everything below. Jargon and length are rules about behavior – how Claude writes, the same in every project you own. A wrong name is data – true in this project, meaningless in the next one. Behavior and data go in different places, and if you put them in the same place, you will spend a week fighting your own configuration.

Two of those three names probably mean nothing to you yet. That is fine – each gets its own part below, and each part starts by explaining what the thing is before telling you what to do with it.

First, kill the obvious wrong idea

Everyone’s first move is to drop the effort level. Shorter thinking, shorter answer, right?

No. Anthropic documents this directly, and it is worth quoting because it saves you the experiment: “Claude Opus 5’s default user-facing responses run longer than prior Opus models’. The effort parameter controls how much the model thinks rather than how much it says: lowering effort can reduce thinking volume without reliably shortening the visible response. To control response length, prompt for it explicitly.” (Prompting Claude Opus 5).

So dropping to medium buys you a cheaper, faster, dumber answer of roughly the same length. That is the worst trade on the menu. Length has to be asked for in words.

The same page notes something the community discussion almost always misses: files Claude writes to disk are a separate problem with a separate fix. “Files that Claude Opus 5 writes to disk (reports, Markdown documents, summaries) are often longer than on prior models.” A rule about chat brevity does nothing to the bloated report Claude just wrote to disk – in my case a file called HandOver.md, my own convention for carrying notes from one session to the next. That needs its own sentence, and Anthropic supplies one worth stealing verbatim: “Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.”

Problem one: jargon

The fix for jargon is a thing called an output style. Before we go further, here is what that actually is, because the name tells you nothing.

An output style is a small Markdown file that you write once and leave on disk. In it you put your rules about how Claude should talk: short sentences, plain words, keep the Delphi terms, drop the imported ones. Claude Code reads that file at startup and glues its contents into the system prompt – the block of instructions the model is given before it ever sees your question. So your rules are not something Claude was told once and may forget. They are part of what it is for that session. That does not mean it always obeys them.

Three things follow from that, and they are the reason the rest of this part is organised the way it is. An output style is permanent (it stays until you switch it off), it is global (every project, unless you scope it to one), and it changes how Claude writes, never what it knows. It is a voice setting. Nothing more.

We will write one in a minute. First, why it does not go in the file where everybody puts it.

Fix it, but not in CLAUDE.md

The instinct is to open the main CLAUDE.md and type “keep answers short”. I did exactly that. I even escalated it to a measured rule – a hard cap of about fifteen lines. It helped, but it kept eroding as sessions got long.

There is a mechanical reason, and it is worth knowing because it applies to every rule you write, not just this one.

CLAUDE.md is added as a user message placed after the system prompt. The output style is added to the system prompt itself, and Claude Code then keeps nudging itself about it: “All output styles trigger reminders for Claude to adhere to the output style instructions during the conversation” (Anthropic, Output styles).

That is the whole difference. Your CLAUDE.md rule is stated once, at the top, and then has to survive hours of tool output, file dumps and compiler errors. The output style rule is in the system prompt and gets re-asserted while the session runs. Same words, very different staying power.

So: a permanent rule about how Claude talks belongs in an output style. A rule about your project – that we compile only through the light-compiler agent, that FMX code must not call Windows APIs directly – still belongs in CLAUDE.md. Those are different jobs. Keep them apart.

Making an output style

The file has two parts: a small header, then the instructions themselves. Put it in one of three places:

• C:\Users\<you>\.claude\output-styles\ – all your projects

• <your project>\.claude\output-styles\ – one project

• the managed policy folder – only if your machine is administered by somebody else, such as a company IT department. On a personal machine you will never touch it.

---
name: Plain
description: Short answers in simple English
keep-coding-instructions: true
---

Lead with the answer, then the reason, then the caveat.
One idea per sentence. Active voice. No stacked nouns.
Keep Delphi and RTL terms exactly as they are. Drop imported jargon.

Then activate it. Note: the /output-style command no longer exists – deprecated in Claude Code v2.1.73, removed in v2.1.91. Run /config and pick under Output style, or write “outputStyle”: “Plain” into a settings file yourself. The change lands after /clear or on the next session, because the system prompt is read once at startup.

The first trap

I set up an output style called Plain, with a good Simplified Technical English line in it, switched it on through /config, saw it working, and moved on. For two days it did nothing at all.

Here is what happened. I had run /config in a session started in my own home folder, C:\Users\trei. The menu wrote the setting into:

C:\Users\trei\.claude\settings.local.json

Look at that path. It sits in .claude inside my user folder. It looks exactly like a global setting. It is not one. Claude Code reads five settings files, and that is not one of them:

The file the menu wrote is row three – the project-local file for the “project” that happened to be my home folder. So, my new output style was live in exactly one folder on the machine and silently absent in every Delphi project I opened. Nothing warns you. Nothing looks broken. Claude simply keeps writing the way it always did.

The fix is one line in the right file. Put “outputStyle”: “Plain” into C:\Users\<you>\.claude\settings.json by hand, and do not use the menu for this particular setting.

And here is how to check, which is the part I skipped: start a new session in a real project – not your home folder – and ask Claude which output style it is using. If it names yours, you are done. If it says default, the setting is in the wrong file.

Yet another trap

Look at that header again. keep-coding-instructions: true is not decoration.

Its default is false. A custom output style with that field missing removes Claude Code’s built-in software-engineering instructions – how it scopes changes, how it writes comments, how it verifies its own work. You wrote four lines about being brief and you silently deleted the part of the system prompt that makes it a competent programmer.

The failure is nasty because it does not look like a configuration error. Claude just gets subtly worse at Delphi, and you blame the model. If you are changing how it talks while still wanting it to code, that line is mandatory.

Simplified Technical English: yes, but know what you are buying

One trick doing the rounds is to tell Claude to answer in Simplified Technical English, a standard whose full name is ASD-STE100.

It is a real standard, not a prompt-engineering folk remedy. The airlines asked for it, because their maintenance technicians were spread over the world and “80% of which were not from English-speaking countries”. A technician who does not speak English natively has to read a repair procedure and get it right the first time, because the alternative is an aircraft falling out of the sky over a badly worded sentence. So, the standard fixes the language itself: 53 writing rules in 9 sections, plus a dictionary of about 900 approved words, “each with one meaning and one part of speech”. Current edition Issue 9, January 2025 (ASD-STE100).

Short sentences. Active voice. One meaning per word. No long chains of nouns stuck together. For any of us who did not grow up speaking English, that is exactly the target.

So, should you use it? Yes – as one line in your output style, and nothing more. Mine reads:

Follow ASD-STE100 Simplified Technical English where you can:
one meaning per word, active voice, no long chains of nouns.

That line is worth its space. Sentences get shorter, the stacked nouns disappear, and it costs you nine words of system prompt.

What you must not expect is compliance. Naming the standard gives Claude the direction, not the rulebook. It does not have the 900-word dictionary loaded, it cannot check a sentence against it, and nothing verifies the result. Feed the output to a tool that grades text against the standard and it will fail. So: do not buy the standard, do not install a checker, and do not tell anybody your documentation is written in Simplified Technical English. Use the name as a shortcut that tells Claude what kind of English you want, and take the 80% of the benefit that arrives for free.

ELI5: right instinct, wrong execution

“Explain it like I’m five” is the popular version of this fix, and the standard advice is to avoid it. Claude gave me exactly that advice while drafting this chapter, and it was wrong about half of it. Worth watching for: an assistant repeating the received wisdom of its field, confidently, when the thing in front of it says otherwise.

The objection is real. A five-year-old explanation drops the numbers, softens LRESULT into “the thing the function gives back”, and reads as condescending to somebody with twenty years of Delphi behind them. Never let it near the facts.

But look at what ELI5 actually demands, underneath the baby talk. It demands you assume the reader shares no context with you at all. Every term explained where it appears. Every file named in full. Every back-reference spelled out instead of pointed at.

That is the half worth keeping, because that is the half that actually fails in practice. When an answer does not land, the words are usually fine and the referents are missing: “the companion chapter”, “that table”, “the second issue”, “as I mentioned earlier”, “paragraph 12”. Every one of those is a hole only the writer can fill. No amount of simpler vocabulary repairs it, and asking for “plain English” makes it worse, because the missing explanation gets shorter too.

So, the line for your output style is not “be simple” and not “do not be simple”. It is this:

Assume the reader shares no context with you. Name every file in full, explain every term the first time it appears, and never point at something you have not just said. Then put the facts back exactly as they were: numbers, versions, real API names and every warning, unchanged.

Explain it like I am five, then put the facts back.

Problem two: length

Why the length fix does NOT go in the output style

The tempting move is to add “always be brief” to the file you just wrote. Do not.

You sometimes need the long answer. A design discussion, a review report, a chapter draft, a root-cause write-up. A permanent brevity rule fights all of those, and it fights them silently: you will not notice the paragraph that got cut, only that a decision later turned out to be based on half the picture.

There is a second reason, and for anyone using subagents it is the bigger one. Output styles apply to the main conversation only. A subagent runs its own system prompt, so your style does not shape its answers. The single exception is a fork, a subagent deliberately started as a copy of the current conversation, which inherits everything the parent had (Sub-agents). Which means the style you carefully tuned does nothing to the twelve-page report coming back from your review agent, your bug-triage agent or your compile agent. If you work the way this book recommends, that is where most of your wall of text actually comes from.

Worth knowing, since it is the natural next question: subagents do inherit your CLAUDE.md hierarchy, including C:\Users\<you>\.claude\CLAUDE.md. The two exceptions are Explore and Plan, the read-only agents Claude Code ships with for searching and for drawing up a plan – those two skip it. So, your project rules reach your agents. Your voice settings do not.

The right home for a length fix is a skill – something that costs nothing until you invoke it, and works on a chat answer and an agent report alike.

The skill: say it again, in plain words

Mine is called /light-md-Coherent. It has one job: re-say the previous message. Three modes, picked by what you type after it:

no argument – the same answer in plain words

a number, 3 – exactly three numbered points, most important first

a phrase – explain only that part, with the context that was missing

Two rules make it work, and both are about what it must not do.

It rewrites; it never re-derives. No files re-read, no tools run, no fresh thinking. Every claim in the plain version must already exist in the message being rewritten. Without this rule “say that simply” quietly becomes “answer again”, you get a second answer that differs from the first, and now you have two answers and no way to tell which one is right.

Facts cross over untouched. Numbers, versions, unit and class names, file paths, and every warning. Simplify the words, never the facts. The failure mode to guard against is the model deciding a caveat “reads like hedging” and dropping it – that turns a careful answer into a confident wrong one.

Here is the shape of it on real Delphi output. Before:

The root cause is a Win64 pointer-truncation issue: SendMessage returns an LRESULT, which is 64-bit on Win64, and it is being assigned into an Integer, so the upper 32 bits of the returned handle are discarded. This is non-trivial to spot because the code is correct under Win32.

After:

On Win64, SendMessage gives back an LRESULT, which is 64 bits wide. The code stores it in an Integer, which holds only 32 bits, so the top 32 bits of the handle are thrown away. The same line is correct on Win32, which is why nobody saw it.

Note what survived. LRESULT stayed, because a real API name is not jargon – it is the name of the thing. “Upper 32 bits” stayed a number instead of softening into “half”. What went was pointer-truncation issue and non-trivial to spot, which were carrying no information at all.

The bug itself is real, not invented for the example. Winapi.Windows.pas line 3839 declares LRESULT = INT_PTR, and line 27185 declares SendMessage as returning LRESULT (Delphi 13 source). INT_PTR is pointer-sized, so 64 bits under Win64, while Integer stays 32 bits on every platform.

That last point is the one people get wrong when they copy this idea. A plain-English rule must not strip your domain vocabulary. For us, procedure, record, RTTI, try..finally, DFM, interface section are the correct words and must survive untouched. What deserves to die is the imported filler: leverage (use), orchestrate (run), non-trivial (hard), semantics (meaning), canonical (standard), surface as a verb (show). A blanket “no jargon” instruction cuts both, and you end up with an answer that is easy to read and no longer says anything precise.

Does it actually save money?

The usual pitch is that shorter answers cost fewer output tokens. True for the output style – that one is a genuine saving on every single turn, and the added system-prompt text is cached after the first request in a session.

The skill is different, and you should know it. Invoking /light-md-Coherent spends tokens: it re-reads the long answer and writes a second, shorter one. It saves you money only when it replaces something more expensive – re-asking the question, or acting on an answer you misread. Used on every response it is a net cost. Used when you are genuinely stuck on a paragraph, it is cheap.

That is the honest accounting. The real win here is not the token bill anyway. It is that you stop skimming answers you do not fully understand, which is how wrong assumptions get into code.

Problem three: a wrong name

Back to the “Application Repository”. No output style can fix that, because a style rule says the same thing in every project, and this is a fact about one program. No skill can fix it either, because a skill runs after the wrong word is already on the screen.

It has to be stored somewhere. That is what the rest of this chapter is about: Claude’s memory, what it really is, and which part of it a name belongs in.

Claude’s memory is how you teach it your project, your conventions and your preferences, and keep that knowledge after you close the terminal. It is one of the most important things in this book. It is also the thing people get wrong most often, because two completely different mechanisms are both called “memory”, and the official documentation splits them on one question: who writes it, you or Claude.

Read the last two rows twice. They are the answer to where a name goes, and the next few pages are the evidence.

The one you write: CLAUDE.md

A Markdown file, read whole at the start of every session. Nothing decides whether it is relevant. It is simply there.

The hierarchy

Just like settings files, memory files stack. Claude Code reads them from the folder you started in and from every folder above it:

The closest file wins. If your global CLAUDE.md says “use 4-space indentation” and your project CLAUDE.md says “use 2-space indentation”, the project setting wins.

Subfolders join in later. A CLAUDE.md sitting in a subfolder is not loaded at startup. It arrives the moment Claude reads a file in that subfolder. So, you can put a CLAUDE.md in C:\Projects\MyApp\Test\ that only wakes up when Claude works on test code.

The size limit

4 MiB. It is a cliff, not a trim: a bigger file is skipped whole rather than cut short. You will never reach it writing prose.

The number people quote, 200 lines, is not a limit here at all. It is Anthropic’s recommendation, and the reason they give is worth reading twice: “Longer files consume more context and reduce adherence.” Going over does not break anything. It makes Claude follow you less well – which is worse than breaking, because you cannot see it happen.

Or so Anthropic says. In May 2026 somebody finally measured it. Damon McMillan ran Claude Code sessions with the same one-line rule in a CLAUDE.md padded to 25, 100, 250 and 500 lines, 50 sessions each, then counted whether that rule was obeyed: 60.0%, 65.2%, 67.7% and 64.0%. No trend that could be told apart from chance, and the paper concludes that “within 25 to 500 lines, file length did not produce a detectable compliance contrast in our data”. Moving the rule from the top of the file to the bottom made no detectable difference either. So keep the file short for the sake of your token bill, which is real – but do not expect a shorter file to buy you obedience. That part has been tested, and it did not show up. (Instruction Adherence in Coding Agent Configuration Files: A Factorial Study of Four File-Structure Variables, arXiv:2605.10039.)

/init – the starting point

To create a CLAUDE.md for a project, type /init. Claude reads the project structure and writes a summary of it into the file.

Do not leave it like that. It is a first draft, not a finished file. Open it and rewrite it. Delphi can display MD files, by the way, though it cannot edit them.

/memory – the quick edit

Type /memory during a session to open any of your memory files in your normal editor. It is the fastest way to add a rule while you are thinking of it.

Imports: @ is Delphi’s $I

A CLAUDE.md can pull in other files with @:

See @README.md for project overview.
Build instructions: @docs\building.md
Shared conventions: @delphi-conventions.md

The contents of README.md then become part of CLAUDE.md, exactly the way {$I} works in Delphi. And exactly like {$I}, it does not save you anything: the imported file is loaded at launch too, so splitting one big file into five imported ones organises your text without shrinking what Claude has to read. If you want a real saving, that is what the next section is for.

The one that loads only when needed: .claude\rules\

For a bigger project, instead of one giant CLAUDE.md, break the instructions into one file per topic:

C:\Projects\MyApp\.claude\
    CLAUDE.md                main project instructions
    rules\
        code-style.md        formatting and naming
        testing.md           test conventions
        delphi-patterns.md   Delphi-specific stuff

Every .md file in there is found automatically. A file with no header loads at launch, with the same weight as CLAUDE.md.

Now the part that earns its keep. A rule file can carry a small header naming the files it belongs to:

---
paths:
  - "**/*.pas"
  - "**/*.dfm"
---

# Delphi source rules

- Always use FreeAndNil, never .Free
- No global variables

Those rules load only when Claude opens a .pas or a .dfm. That is the one mechanism here that genuinely costs you nothing until it is relevant: your Object Pascal conventions arrive when Claude touches Object Pascal, your FMX mobile rules arrive only inside the FMX subtree, and in a session where you are editing a build script neither of them takes up a single token.

The one Claude writes: auto memory

This is what happens when Claude says “I’ll remember that” without touching CLAUDE.md. It writes notes to itself as it works. Typically:

build commands it discovered

code patterns it noticed

solutions to problems it ran into

preferences it picked up from what you said

You can also aim it directly: “Remember that we use MSBuild, not the command-line compiler”, or “Save to memory that the unit tests need LightSaber built first.”

It lives here:

C:\Users\<you>\.claude\projects\<project>\memory\

That folder holds an index file called MEMORY.md, and beside it one small file for each thing Claude remembered. The index carries a single line about each of those files. Here is the sentence the whole chapter turns on:

The index loads every session. The files behind it do not.

Anthropic says it flatly: “Claude reads them on demand using its standard file tools when it needs the information.”

So CLAUDE.md is always in the room. A memory is not. Claude has to go and fetch it – and the only thing it has to decide with is that one line in the index.

To switch the whole thing off:

set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

Why a name should not live in auto memory

Four reasons. None of them is a disaster on its own. Together they decide what auto memory is actually good for.

1. Subagents never see it. “The main conversation’s auto memory isn’t loaded into subagents.” If you work the way this book recommends, with a compiler agent and a review pipeline, then most of your actual code is written where auto memory does not exist. Correcting a name in chat teaches the session. It does not teach the four agents that will write the code. CLAUDE.md has no such hole: subagents inherit it.

2. The index has a ceiling. The first 200 lines or 25 KB of MEMORY.md load at session start; past that, nothing. One line per memory, so roughly 200 memories per repository. Claude Code does defend it now – it measures the file after every write, warns near the limit and errors past it – but the repair is Claude deciding which of your memories to merge or drop. The biggest index on my machine is C:\Users\trei\.claude\agent-memory\light-review\MEMORY.md at 106 lines, half the cap, on a subagent, and I had never once looked at it.

3. Recall is a guess. The index line is all the retrieval decision has to work with. A memory described as “notes about the parser” will sit unread next to the exact conversation it was written for, and nothing tells you. The fact is on disk, it is correct, and it never arrives.

4. A glossary is one document, not a hundred memories. The man on the forum fixed one term. Ask the next question: what about a hundred? That is half your ceiling spent on vocabulary – and vocabulary is the worst possible fit, because a term matters exactly when it appears, which is unpredictable, which is what retrieval is worst at. This is not a flaw in auto memory. It is a category error.

Two smaller things, in passing. The store is keyed by the git repository, so worktrees and subfolders share one – but outside a repository it follows the folder you launched in. My books are not a repository, so I have 74 memory index files on this machine for far fewer real projects. And it is machine-local: nothing follows you to the laptop.

What actually survives when you close Claude

Worth being blunt about this, because people assume too much and then get surprised.

Survives permanently

CLAUDE.md files and everything in .claude\rules\ – you control these

auto memory – Claude controls these

settings.json files

console-command permissions you approved with “don’t ask again”

Survives until the session ends

file-edit permissions – you approve them again next time

the conversation itself, though you can bring it back with claude -c

Does not survive

the context window. Resuming reloads the conversation from disk, but Claude still has to re-read any file it needs

any environment variable you set during the session

So what do you actually do

A rule you cannot afford to lose goes in CLAUDE.md. Loaded whole, no retrieval step, inherited by subagents. This is where “compile only through the light-compiler agent” lives.

A glossary goes in one table, in the project’s CLAUDE.md:

## Names we use in this project
| Say this | Not this | What it is |
|---|---|---|
| Application Catalog | Application Repository | the INI-driven list of launchable apps |

A hundred rows is a few thousand characters against a 4 MiB ceiling. One place to edit, no retrieval step, and your agents get it too.

A rule that only matters for some files goes in .claude\rules\ with a paths: header. That is the only one that costs nothing when it is not relevant.

Auto memory is for the occasional fact you can afford to miss. A preference. A gotcha about one library. Something whose absence costs you a minute, not a decision.

And one line to pin above all of it, from the documentation: “Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead.” Every one of the four places in this chapter is a suggestion. Only a hook is a rule.

The habit that has to come first

Storage is only half of it. The other half is a habit, and the man on the forum has it:

The more I treat Claude Code like a teachable and fast-learning programmer's assistant, the better it becomes. Just tell it what you like and don't like - it won't get its feelings hurt.

He corrects the wrong word the moment it appears, in conversation, at the cost of one sentence. Most of us do the opposite: notice the wrong word, translate it in our head, carry on. Then the session ends and the correction dies with it. Next session, same project, same wrong word.

No configuration gives you that. /light-md-Coherent runs after the bad paragraph exists. The habit prevents the paragraph.

So do both. Say the correction out loud the moment you see it – and then put it where it will actually be read.

What none of this fixes

None of these three fixes makes the model right. A plain, short, beautifully readable answer can still be confidently wrong, and stripping the hedges makes a wrong answer more convincing, not less. That is why the rule about carrying caveats across verbatim matters more than anything else in this chapter.

And there is a broader lesson worth keeping. Opus 5 leads the public benchmarks. At the time of writing it holds the top two slots on the Artificial Analysis Intelligence Index – an independent scoreboard that runs the same test suite against every model on the market – scoring 63 at both max and xhigh effort, ahead of everything from every other lab (artificialanalysis.ai). It also produced the loudest wave of complaints about being unpleasant to work with. Raw capability and daily usability are not the same measurement, and they can move in opposite directions.

When the next model does this again – and it will – the fix will be the same shape. Ask what kind of correction you are making. A permanent voice goes in an output style. An occasional cleanup goes in a skill. A name goes in CLAUDE.md. Put the rule where the machinery will keep loading it. It will still slip: in my own sessions, with my output style loaded, nearly half of Claude’s chat answers ran past 200 words, where the style asks for about 120. So keep reading what Claude writes.

Sources: Prompting Claude Opus 5, Output styles, Sub-agents, How Claude remembers your project, Claude Code settings, ASD-STE100, and Winapi.Windows.pas from the Delphi 13 source. Verified against Claude Code 2.1.237, August 2026. Measured on my own machine 2026-08-23: 74 MEMORY.md files, the largest 106 lines.

This was one chapter of a whole book

You just read one chapter of Delphi in all its glory – AI-assisted development: more than 400 pages about Claude Code and AI for Delphi programmers. Written by a Delphi programmer, with the failures documented next to the wins.

• Order the eBook or the paperback
• The paperback on Amazon
• The other four books of the series