Study notes · 8.6% of the exam

Claude Application Design

Design Claude applications that behave predictably: know which instructions each interface gives Claude, separate trusted instructions from untrusted content, design schemas that guarantee usable output, keep sessions clean, and manage plugins deliberately.

Key points

1
claude.ai and the mobile apps add their own periodically updated system prompt (for example the current date and formatting guidance). The API has no default system prompt, so an API app must supply its own context, persona and output format.
2
Claude Code adds its own system prompt and loads CLAUDE.md as project memory. Raw Messages API calls load neither, so rules that must hold in every interface have to be sent explicitly, for example in the API app's system prompt.
3
Agent SDK: with no systemPrompt set it uses a minimal tool-calling prompt, unlike claude -p, which uses the Claude Code prompt. Use the claude_code preset (optionally with append) to match CLI behavior. CLAUDE.md loading is controlled by setting sources, not by the preset.
4
On the API, operator rules belong in the system parameter, not in a first user message, where they look like user text, can be argued with, and are lost when history is trimmed. A stable system prompt is also a good caching prefix.
5
Content boundaries: wrap untrusted or retrieved content in clearly named XML tags (e.g. <email>, <document>) and state that tagged content is data, not instructions. Give each document its own tags with metadata such as source, and place long documents before the question.
6
Boundaries can be forged: neutralize tag-like sequences in untrusted input before wrapping it, and gate sensitive actions with checks outside the model.
7
Schema design: use structured outputs (output_config.format with a JSON schema) or strict: true tools when code consumes the output. Use required, additionalProperties: false and enums to constrain values (e.g. a doc_id enum of the IDs actually supplied).
8
Give the model a valid way to say a value is missing (nullable fields or a status enum) and describe each field's source. Required fields with no way out push the model to invent values.
9
Tool definitions are prompts: distinct names, detailed descriptions of what the tool does and when to use it, and precise input schemas drive correct tool selection.
10
Check feature interactions when designing: citations and structured outputs cannot be combined in one request, so split the work and build provable fields in code from the citation objects.
11
Session hygiene in Claude Code: use /clear between unrelated tasks and after repeated corrections (restart with a sharper prompt); /compact is for continuing the same task when context is full; use subagents for file-heavy investigation; write a spec, then implement in a fresh session.
12
The root and user CLAUDE.md files are read at session start. Mid-session edits apply after /clear, /compact or a restart. In API apps, scope a conversation to one task and carry forward only a curated, current summary.
13
Plugins bundle skills, agents, hooks and MCP servers, and their skills are namespaced /<plugin>:<skill>. Install scopes: user (~/.claude/settings.json), project (committed .claude/settings.json; collaborators still install once) and local (.claude/settings.local.json). Local overrides project, which overrides user.
14
Plugins can run hooks and MCP servers, so review them before installing and pin marketplaces to reviewed refs (owner/repo#tag). For requirements across the whole organization (required plugins, approved marketplaces only), use managed settings, which users cannot override. In scripts and CI, use the claude plugin shell commands, because /plugin does not run under claude -p.

Read the source

Test yourself on Claude Application Design

Ten questions, with the answer and explanation after each one.