2.6 Matching Instructions to the Interface in Use

Claude is reached through several genuinely distinct surfaces, and how instructions are interpreted differs by surface. This isn't a stylistic variation of the same underlying mechanism -- each row below is a different authoring model with its own conventions.

Programmatic integration through the API or an SDK has exactly the instruction channels covered in 2.3: the top-level system parameter, the messages you construct, any tools you define, and request parameters like temperature. There is no repository memory, no Project knowledge base, no local MCP connection implied by this surface on its own -- whatever instructions the model receives are exactly what you put in system and messages, nothing more.

claude.ai layers Project-level instructions and a Project knowledge base on top of ordinary chat -- a Project's custom instructions shape every conversation started inside it, and documents added to the Project's knowledge become available context, neither of which has anything to do with a system parameter on an API call. Claude Desktop is a chat surface too, but its distinguishing instruction mechanism is locally connected MCP servers: tools and resources a user has explicitly connected to the desktop app, which become available inside that chat.

Neither surface reads a CLAUDE.md file or a settings.json, and neither is configured through a system parameter the way an API integration is. Describing a claude.ai Project's setup in terms of "the system prompt" or describing an API integration in terms of "Project knowledge" is mixing up the mechanism with the surface.

Claude Code is an agentic CLI operating inside a repository, and its instruction mechanism is built for that context: a CLAUDE.md file holds project/repo memory and instructions that shape how Claude Code behaves in that repo, settings.json configures permissions/hooks/tool allow-deny lists/environment, and slash commands trigger specific predefined actions. None of these three has a direct equivalent on a raw API call -- a CLAUDE.md file sitting in a repository does nothing at all to a Messages API request sent from a completely separate service.

A recurring scenario shape on this task statement describes a design decision and asks you to spot where the wrong instruction mechanism got applied to the wrong surface. The tell is almost always a mismatch between the noun (which surface is actually being built) and the verb (which mechanism the described solution reaches for).

• •"We'll add a CLAUDE.md to guide our customer-facing chat widget" -- the widget is presumably an API integration; CLAUDE.md has no effect there. The mismatch: Claude Code's mechanism applied to an API surface.
• •"We'll configure a system prompt for our claude.ai Project" -- claude.ai Projects use Project-level instructions and knowledge, not a system parameter you set on a request; there's no request being constructed by the end user at all.
• •"We'll write a slash command so our Messages API backend can access the internal ticketing tool" -- slash commands are a Claude Code mechanism; an API backend reaches tools through the tools parameter, not a slash command.

In each case, the fix isn't a small tweak -- it's recognizing that the entire mechanism named in the proposal doesn't exist on the surface being described, and substituting the mechanism that actually applies to that surface: the system parameter and tools array for an API integration, Project instructions and knowledge for claude.ai, connected MCP servers for Claude Desktop, or CLAUDE.md/settings.json/slash commands for Claude Code.