Claude Code는 시스템 프롬프트를 구축합니다.

I like reading system prompts, either when they’re published as part of open-source software, exfiltrated via crafty prompting, explicitly shared, or (in the case of last week) accidentally leaked. They’re often the best manual for how an app is intended to work. We’ve touched on system prompts in the past, introducing them and breaking down Claude’s, showing how system prompt changes over time reveal product priorities, and diving deep with an analysis of coding agent prompts and variations. But one thing that’s been hard is understanding how system prompts are assembled. System prompts generally aren’t static strings; they’re dynamically assembled contexts with many conditional statements determining what makes it in the prompt. It’s true, we can look at open source harnesses or apps to understand approaches. But for the big company apps we can only get the big picture. We can extract a final prompt, but we can’t see how it was built. With the accidental leak of Claude Code’s source code last week, we can see for the first time how Claude Code assembles a context. It’s incredibly impressive, illustrating how complex context engineering can be and the importance of harnesses. I won’t share the code here, but after poring over it I’ve assembled a visualization below. It lists each component used to assemble the system prompt. Some components are always included (the rows with a solid blue dot) while others are conditional (the hollow blue dots). Components may have variations. For example, the “Using Your Tools” section only contains information regarding available tools. Take a look yourself. Click a row for more details. System Prompt Tells the model what it is and sets the session tone. Default You are an interactive agent that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user. With output style You are an interactive agent that helps users according to your "Output Style" below, which describes how you should respond to user queries. Ground rules for how tools, permissions, prompt injection, system-reminder tags, and context compression work. All text you output outside of tool use is displayed to the user. Output text to communicate with the user. You can use Github-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification. Coding philosophy: read before editing, don't over-engineer, keep changes minimal, don't introduce security vulnerabilities. Omitted when A custom output style is configured with keepCodingInstructions: false. Default Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Anthropic extra Default to writing no comments. Only add one when the WHY is non-obvious: a hidden constraint, a subtle invariant, a workaround for a specific bug, behavior that would surprise a reader. Guidelines for confirming before risky actions: deleting files, force-pushing, posting to external services. Carefully consider the reversibility and blast radius of actions. Generally you can freely take local, reversible actions like editing files or running tests. But for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding. Tells the model to prefer dedicated tools (Read, Edit, Glob, Grep) over raw shell commands. Default Do NOT use the Bash to run commands when a relevant dedicated tool is provided. Using dedicated tools allows the user to better understand and review your work. REPL Minimal version with only the task management bullet. Communication rules: no emojis, cite file paths, use GitHub link format. Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked. External extra Your responses should be short and concise. How verbose to be. Two very different versions for internal vs. external users. Anthropic When sending user-facing text, you're writing for a person, not logging to a console. Assume users can't see most tool calls or thinking - only your text output. External IMPORTANT: Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise. A marker separating globally-cacheable content from session-specific content. Not visible to the model — it's a cache optimization. Included when If global cache scope is enabled __SYSTEM_PROMPT_DYNAMIC_BOUNDARY__ Tells the model it can ask you a clarifying question if you deny a tool call. Included when If the AskUserQuestion tool is available If you do not understand why the user has denied a tool call, use the AskUserQuestion to ask them. Tells the model about the ! prefix for running interactive commands yourself. Omitted when Running in a non-interactive session (CI, SDK, headless). If you ne