Interfaces and Their Instruction Mechanisms
CoreMatch instruction mechanisms to the Claude interface in use · Difficulty 1/5
Explanation
The Four Interfaces
Claude is reached through several distinct surfaces, and how instructions are interpreted differs by surface:
| Interface | Primary use | Instruction mechanism |
|---|---|---|
| API / SDKs | Programmatic integration | system param + messages, tools, params |
| claude.ai | Web chat / Projects | Chat + Project instructions & knowledge |
| Claude Desktop | Desktop app, local MCP | Chat + connected MCP servers |
| Claude Code | Agentic CLI in a repo | CLAUDE.md + settings.json + slash commands |
Each row is a genuinely different authoring surface, not a stylistic variant of the same thing. The API takes a structured system parameter and typed request fields; claude.ai layers Project-level instructions and knowledge on top of chat; Claude Desktop adds locally connected MCP servers to a chat surface; Claude Code reads repository-level `CLAUDE.md memory and settings.json` configuration, plus slash commands, on top of its agentic loop.
Why the Distinction Matters
A design that assumes one mechanism generalizes across surfaces will silently fail on another. Writing a `CLAUDE.md file does nothing for a raw Messages API integration -- that surface has no concept of repository memory; its only instruction channel is the system parameter and the message content you construct yourself. Conversely, structuring a system` string with API conventions doesn't map onto a claude.ai Project's instructions-and-knowledge model.
Common exam traps
- Assuming instructions transfer verbatim across surfaces. A `CLAUDE.md` shapes Claude Code; it does not configure a raw Messages API call. Always match the instruction mechanism to the specific interface in play.
- Treating "Claude" as a single monolithic product with one instruction surface, rather than one model reachable through several distinct products/APIs, each with its own instruction-authoring conventions.
Key Takeaways
- API/SDKs use the system parameter plus messages, tools, and params as their instruction mechanism
- claude.ai uses chat plus Project-level instructions and knowledge
- Claude Desktop uses chat plus connected MCP servers
- Claude Code uses CLAUDE.md, settings.json, and slash commands
- Instructions authored for one surface (e.g., CLAUDE.md) do not transfer verbatim to another (e.g., a raw Messages API call)
Glossary Terms
A markdown configuration file read by Claude Code at startup that injects persistent context, project conventions, and tool guidance into every session — without re-prompting. Claude Code supports CLAUDE.md files at the global, project-root, and subdirectory levels (see /glossary/path-specific-rules for the hierarchy). Uses @import for modular organization.
The Claude Code settings file that configures tool permissions, hook scripts, environment variables, and behavioral settings. Project-scoped (.claude/settings.json) checked into version control, or user-scoped (~/.claude/settings.json) for personal preferences. Hooks are defined here.
An open standard protocol for connecting Claude to external tools and data sources. Defines a client-server architecture where MCP servers expose capabilities that MCP clients discover and use. Supports project-scoped (.mcp.json) and user-scoped configurations.
The initial instruction set provided to Claude that defines its behavior, role, constraints, and operational context for an entire conversation. Set via the 'system' parameter in the API. Processed before the user turn and shapes all subsequent responses.
Related Concepts
Content Boundaries & Schema Design
Trusted instructions and untrusted data (user input, retrieved documents, tool output) must be kept separate and clearly delimited
CLAUDE.md and settings.json as Versioned Project Configuration
CLAUDE.md is project/repo memory for Claude Code and belongs in version control, reviewed like code