Chapter 02 Prompt is Control Plane

# Chapter 2 Prompt Is Not Personality, Prompt Is the Control Plane

## 2.1 Treating prompt as persona is a common misunderstanding

When people hear "system prompt," they first think of familiar rhetoric: who you are, what you are good at, ideally with a stable personality. That framing is enough for chat-only systems and clearly insufficient for an agent that reads files, calls tools, touches shell, handles permissions, and executes across turns. Persona answers "what it looks like"; a control plane answers "what it can do, when, what happens on failure, who owns fallback." They are different layers.

Claude Code implementation shows this directly: its system prompt is a layered assembly of behavioral blocks — closer to a runtime protocol than to a character biography.

## 2.2 In source, Claude Code prompt is layered from the beginning

In `getSystemPrompt()` at `src/constants/prompts.ts:444`, Claude Code returns an array of sections, not one complete string. This detail matters. Once prompt becomes multi-block, the system formally acknowledges internally distinct constraints with distinct duties.

These sections include at least several categories.

First is identity and mission. At `src/constants/prompts.ts:175`, the system states it is an interactive agent that uses available tools to complete software engineering tasks, including safety constraints such as not guessing URLs.

Then come system-level rules. Starting at `src/constants/prompts.ts:186`, the system explicitly defines:

- Which text users can see
- That tool calls may trigger permission approval
- That denied actions must not be mechanically retried
- That system reminders may appear inside tool results and user messages
- That context may be automatically compacted

These rules share one obvious property: they do not care whether the model "looks like a smart assistant." They care whether it is a disciplined executor. That is control-plane tone; its primary mission is boundary definition.

Then, starting at `src/constants/prompts.ts:199`, come engineering instructions for doing work: do not add requirements casually, do not optimize beyond authorization, do not hide failed validation just to look polished, and do not invent abstractions unnecessarily. They may look like writing-style guidance, but they are tightly coupled to engineering constraints. A model that "helpfully optimizes everything" may look enthusiastic product-wise and still be dangerous engineering-wise.

So source structure alone already shows this: Claude Code prompt is designed to keep model behavior within boundaries in complex runtime.

## 2.3 Prompt value is not text itself, but precedence structure

If prompt just exists as text, that still does not prove control-plane status. What decides that is strict precedence.

You can see this in `buildEffectiveSystemPrompt()` at `src/utils/systemPrompt.ts:28`, where prompt sources are composed in explicit order:

1. override system prompt
2. coordinator system prompt
3. agent system prompt
4. custom system prompt
5. default system prompt

Then `appendSystemPrompt` is uniformly appended.

The proactive-mode handling is even more direct. After `src/utils/systemPrompt.ts:99`, when agent prompt and proactive mode co-exist, agent prompt no longer replaces default prompt; it is appended after. A general constitution can be extended by a job description, but must not be wiped out by it.

### Skeleton: the prompt-assembly precedence chain