Managed Like Code, Stored Like Docs

You are calling a model now, and somewhere in that code is a long string of instructions. It will be the most edited thing in your product and the least reviewed, and right now it is buried in a function where nobody can see it change. This chapter pulls it out.

6.2.1A prompt is content, not codeAdd note

A prompt buried in a source file is invisible. You cannot skim it, your agent edits it without you noticing, and a change to two words of instruction looks exactly like a change to the code around it.

So keep it out. Prompts live in their own files, in plain text or markdown. The code loads them by name:

Now the instruction is readable by you, editable without touching code, and every change to it shows up as a change to a document rather than a change to a program.

6.2.2Build it from pieces, not one wallAdd note

One enormous prompt is a single blast radius. Ask your agent to soften the tone and it rewrites the whole thing, and the safety rule you spent an afternoon on quietly disappears in the middle.

Split it. The role and the non-negotiable rules in one file, the tone in another, the examples in a third, and the code assembles them at call time. Now an edit to tone touches the tone file and nothing else, and you can see that at a glance.

The shared pieces follow the same habit as your settings: one copy, loaded by everything that needs it, never pasted twice.

6.2.3Version them like anything else you shipAdd note

A prompt change is a product change. Yesterday's answers came from yesterday's instructions, and if you cannot say which version produced a result, you cannot tell a model problem from a prompt problem.

Give each prompt a version and stamp it on the calls it makes:

Your repo already keeps the full history, so version four is one command away from version three. That matters most on the day quality drops and nobody remembers touching anything.

6.2.4Treat an edit like a deploy, because it isAdd note

A two-word prompt edit ships with none of the protection a code change gets. Nothing type-checks it, nothing compiles it, and it looks completely harmless in a diff.

It is not. Changing "be concise" to "be brief" has flipped output quality in production systems. So a prompt change goes through the same gate as any other. You review it, then run it against the set of examples you use to judge model quality before it reaches users.

Watch out: never let an agent edit a prompt as a side effect of some other task. Prompt files are content it will happily tidy. Make prompt edits their own change, always.

6.2.5Pull your prompts out of the codeAdd note

Do this now: paste the prompt and get every instruction string out of your code and into a file you can actually read.