Claude Code Source Code Deep Research Report

1. Scope And Executive Summary

1.1 What This Research Actually Covered

This research did not stop at reading a single prompt file or scanning the repository tree. It reconstructed readable source files from sourcesContent inside cli.js.map, then followed the runtime from architecture to execution.

The investigation focused on:

• Claude Code's overall source structure
• How the main system prompt is dynamically assembled
• The model-facing protocols behind AgentTool and SkillTool
• The role split between built-in agents
• How the agent orchestration chain actually runs
• How plugins, skills, hooks, and MCP affect runtime behavior
• How permissions, tool execution, and hook decisions cooperate
• Why Claude Code feels much stronger than a plain "LLM + tool caller"

1.2 Confirmed Facts

The reconstructed package confirmed several concrete implementation details:

1. cli.js.map in the npm package contains full sourcesContent
2. At least 4,756 source files were recoverable from the map
3. The core main system prompt file is src/constants/prompts.ts
4. The Agent tool prompt lives in src/tools/AgentTool/prompt.ts
5. The Skill tool prompt lives in src/tools/SkillTool/prompt.ts
6. The agent scheduling core includes src/tools/AgentTool/AgentTool.tsx and src/tools/AgentTool/runAgent.ts
7. The tool execution chain centers on src/services/tools/toolExecution.ts and src/services/tools/toolHooks.ts

1.3 The Most Important Judgment Up Front

Claude Code is strong not because of one magic system prompt, but because it behaves like a complete software system.

Its advantages come from combining:

• modular prompt assembly
• governed tool execution
• a permission model
• specialized agents
• workflow packaging through skills
• plugin metadata and runtime constraints
• hooks as policy controls
• MCP as both capability injection and usage guidance
• cache-aware prompt construction
• lifecycle management for async and background work

The shortest possible summary is this:

Claude Code is not a prompt. It is an Agent Operating System that unifies prompts, tools, permissions, agents, skills, plugins, hooks, MCP, cache behavior, and product-grade runtime design.

2. Source Architecture: Why It Feels Like An Agent Operating System

2.1 The Top-Level Structure Already Reveals System Complexity

The extracted src/ tree shows a platform, not a thin CLI wrapper. Important modules include:

• src/entrypoints/
• src/constants/
• src/tools/
• src/services/
• src/utils/
• src/commands/
• src/components/
• src/coordinator/
• src/memdir/
• src/plugins/
• src/hooks/
• src/bootstrap/
• src/tasks/

That layout already suggests a runtime platform with interfaces, coordination, memory, extensibility, and task management.

2.2 The Entry Layer Shows A Platform Mindset

Visible entrypoints include:

• src/entrypoints/cli.tsx
• src/entrypoints/init.ts
• src/entrypoints/mcp.ts
• src/entrypoints/sdk/

This means the system was designed to support:

• local CLI usage
• initialization flows
• MCP mode
• SDK consumers

That is a platform architecture: one agent runtime, multiple entry surfaces.

2.3 The Command System Is Part Of The Product Control Plane

The command layer exposes a large set of system-facing commands such as:

• /mcp
• /memory
• /permissions
• /hooks
• /plugin
• /reload-plugins
• /skills
• /tasks
• /plan
• /review
• /status
• /model
• /output-style
• /agents
• /sandbox-toggle

This is not decoration. It is a runtime control surface. More importantly, it also loads plugin commands, skill commands, bundled skills, dynamic skills, and availability-filtered commands. The command system is an ecosystem entrypoint.

2.4 The Tool Layer Is Where The Model Becomes An Actor

The prompt and tool definitions expose key tools such as:

• FileRead
• FileEdit
• FileWrite
• Bash
• Glob
• Grep
• TodoWrite
• TaskCreate
• AskUserQuestion
• Skill
• Agent
• MCPTool
• Sleep

This is the layer that turns the model from a responder into an executor.

3. The System Prompt Assembly: The Real Role Of prompts.ts

3.1 src/constants/prompts.ts Is The Main Control Point

This file matters not because it contains one giant prompt, but because it assembles the runtime instructions for the main thread.

It handles:

• main system prompt assembly
• environment injection
• tool usage instructions
• safety and risky-action guidance
• session-specific guidance
• language and output style injection
• MCP instructions
• memory prompt injection
• scratchpad guidance
• function-result-clearing guidance
• feature-gated sections like brief mode, proactivity, and token budget rules

Claude Code's prompt is not a string. It is a prompt assembly architecture.

3.2 getSystemPrompt() Is An Orchestrator, Not A Paragraph

The core design is a split between a static prefix and a dynamic suffix.

Static prefix sections include:

• getSimpleIntroSection()
• getSimpleSystemSection()
• getSimpleDoingTasksSection()
• getActionsSection()
• getUsingYourToolsSection()
• getSimpleToneAndStyleSection()
• getOutputEfficiencySection()

Dynamic suffix sections include:

• session guidance
• memory
• model overrides
• environment info
• language
• output style
• MCP instructions
• scratchpad guidance
• function result clearing
• tool result summarization
• numeric anchors
• token budget guidance
• brief mode guidance

This is a high-value design because Claude Code treats prompts as runtime resources to compose, not as a static monolith.

3.3 Prompt Cache Boundaries Show Infrastructure Thinking

The source explicitly defines a dynamic boundary such as SYSTEM_PROMPT_DYNAMIC_BOUNDARY.

The comments make the goal clear:

• keep the prefix cache-friendly
• keep user- and session-specific content after the boundary
• do not casually modify the boundary because it will damage cache behavior

This is not just prompt writing. It is prompt assembly with cache economics.

4. Full Prompt Extraction And Section-Level Analysis

4.1 Identity And Base Positioning: getSimpleIntroSection()

This section establishes:

• Claude as an interactive agent
• the job as helping with software engineering tasks
• output style as something externally controlled
• cyber-risk guidance from the very start
• explicit instructions not to guess or invent URLs

The point is not self-introduction. The point is behavioral framing.

4.2 Runtime Reality: getSimpleSystemSection()

This section defines what the runtime world actually looks like:

• non-tool output is directly visible to the user
• tools execute under permission modes
• a denied tool call cannot simply be retried unchanged
• tool results or user messages may contain <system-reminder> tags
• tool output may include prompt injection
• hooks exist and affect runtime behavior
• context may be compressed automatically

This grounds the model in a controlled execution environment instead of a fantasy conversational space.

4.3 Task Philosophy: getSimpleDoingTasksSection()

This section is one of the biggest reasons Claude Code behaves consistently. It pushes the model away from common failure modes:

• do not add features the user did not ask for
• do not over-abstract
• do not refactor for the sake of refactoring
• do not add comments, docstrings, or type annotations unnecessarily
• do not add extra fallback logic or validation without need
• do not build speculative future-proof abstractions
• read code before editing code
• avoid creating files unless necessary
• avoid time estimates
• diagnose before switching strategies
• pay attention to security issues
• delete clearly unnecessary code instead of carrying compatibility trash
• report outcomes honestly and do not pretend tests were run

This is Anthropic turning good engineering behavior into policy.

4.4 Risky Action Rules: getActionsSection()

This section defines what requires confirmation:

• destructive operations
• hard-to-reverse operations
• shared-state modification
• externally visible actions
• uploads to third-party tools

The design encodes blast-radius thinking directly into system instructions.

4.5 Tool Usage Grammar: getUsingYourToolsSection()

The tool guidance is unusually explicit:

• prefer FileRead over cat, head, tail, or sed
• prefer FileEdit over shell edits
• prefer FileWrite over shell redirection for new files
• prefer Glob for file discovery
• prefer Grep for content search
• reserve Bash for genuinely shell-native work
• use TodoWrite and TaskCreate when available
• parallelize tool calls that have no dependency relationship

This is not just tool availability. It is operational syntax.

4.6 Session-Specific Guidance Is A Dynamic Rule Layer

getSessionSpecificGuidanceSection() injects runtime-dependent rules such as:

• whether AskUserQuestion is available
• behavior differences in non-interactive mode
• whether AgentTool is enabled
• whether Explore or Plan agents are available
• slash-skill usage rules
• guidance for DiscoverSkills
• verification contracts when a verification agent is available

The result is not one global prompt, but global rules plus session-local rules.

4.7 Output Efficiency Is Part Of Product Quality

The output efficiency section focuses on interaction quality:

• users read natural language, not logs
• state the action or conclusion first
• update when useful, but do not ramble
• avoid over-explaining
• avoid unnecessary tables
• use short, direct sentences

Claude Code optimizes not only for task completion, but also for operator experience.

4.8 Tone And Style Standardize The Feel Of The Product

Rules in this area include:

• avoid random emoji usage
• keep responses concise
• cite code locations with file_path:line_number
• refer to GitHub issues and PRs with owner/repo#123
• avoid awkward preambles before tool calls

These details are small individually, but together they shape product feel.

4.9 DEFAULT_AGENT_PROMPT Defines Sub-Agent Personality

The same prompt file also defines DEFAULT_AGENT_PROMPT, which sets the baseline role for sub-agents:

• you are a Claude Code agent
• use tools to complete the task
• complete the task end to end
• return a concise report when finished

That confirms the prompt stack is layered between main-thread behavior and agent behavior.

5. Agent Prompts And Built-In Agents

5.1 AgentTool/prompt.ts Is A Protocol Document

This file is extremely valuable because it functions as the model-facing protocol for multi-agent behavior.

It explains:

• how agent lists are presented
• how each agent is described
• when to fork yourself
• when to specify subagent_type
• the difference between a fork and a fresh agent
• when not to use AgentTool
• how to write a prompt for a sub-agent
• how foreground and background behavior differ
• what isolation modes like worktree or remote imply

The multi-agent system is not hidden. It is explicitly taught to the model.

5.2 Why Fork Semantics Matter

When fork mode is enabled, the prompt tells the model that:

• omitting subagent_type means fork yourself
• the fork inherits full conversation context
• research tasks are a strong fit for forks
• implementation tasks that generate large intermediate output may also fit
• forks are cheap because they share prompt cache
• changing the model for a fork hurts cache reuse
• the main thread should not peek into fork output files
• the main thread should not predict the fork's result in advance

This design solves a hard problem: parallel subtasks without polluting the main context.

5.3 The "How To Write The Prompt" Section Is Critical

The agent instructions actively teach the model how to delegate well:

• fresh agents do not have prior context
• prompts should resemble a real briefing to a new teammate
• include the goal and the reason behind it
• state what has already been ruled out
• include enough context to enable judgment
• say explicitly if you want a short answer
• do not outsource task understanding itself
• avoid lazy prompts like "find something and then maybe fix it"
• pass file paths, line references, and concrete change goals

This is a constraint against sloppy delegation.

5.4 Built-In Agents Represent Specialization

The source confirms built-in roles such as:

• General Purpose Agent
• Explore Agent
• Plan Agent
• Verification Agent
• Claude Code Guide Agent
• Statusline Setup Agent

Anthropic is clearly not pursuing one universal worker. It is assigning exploration, planning, verification, and general execution to specialized roles.

5.5 Explore Agent Is A Read-Only Specialist

The Explore agent prompt defines absolute read-only behavior.

It cannot:

• create files
• modify files
• delete files
• move files
• write temporary files
• use shell redirection or heredocs to create files
• run commands that change system state

Its core capabilities are:

• using Glob, Grep, and FileRead to explore quickly
• using Bash only for read-only commands like ls, git status, git log, git diff, find, grep, cat, head, and tail
• parallelizing reads whenever possible
• reporting quickly

That is not a generic agent that happens to search. It is a deliberately constrained read-only specialist.

5.6 Plan Agent Is Pure Planning

The Plan agent is also clearly defined:

• read-only only
• no file edits
• understand the request first
• inspect the codebase and relevant patterns
• produce a step-by-step implementation plan
• end with a list of critical files for implementation

The role is architect and planner, not executor.

5.7 Verification Agent Is One Of The Most Valuable Pieces

The verification agent prompt is unusually strong. Its job is not to say things look fine. Its job is to try to break the change.

The prompt explicitly warns against two failure modes:

1. verification avoidance: reading code, running nothing, then declaring success
2. being fooled by the first 80%: a feature looks okay and tests pass, so the remaining edge cases are ignored

It then requires concrete verification work:

• builds
• test suites
• lints and type-checks
• specialized checks depending on the type of change
• browser automation or asset validation for frontend work
• real curl or fetch checks for backend changes
• stdout, stderr, and exit-code checks for CLI work
• migration up/down testing when schema changes are involved
• public API verification for refactors
• adversarial probes
• explicit commands and observed outputs for each check
• a final VERDICT: PASS / FAIL / PARTIAL

This is an adversarial validator, not just a second pair of eyes.

6. The Agent Scheduling Chain: From AgentTool To runAgent To query

6.1 The Overall Call Chain

From AgentTool.tsx and runAgent.ts, the main sub-agent pipeline can be abstracted as:

1. the main model decides to call the Agent tool
2. AgentTool.call() parses the input
3. it resolves teammate, fork, built-in, background, worktree, and remote paths
4. it selects an agent definition
5. it builds prompt messages
6. it assembles or inherits the system prompt
7. it constructs the tool pool
8. it creates an agent-specific ToolUseContext
9. it registers hooks, skills, and MCP servers
10. it calls runAgent()
11. runAgent() enters the main loop via query()
12. message streams are produced
13. transcripts, metadata, and cleanup are handled
14. results are summarized or routed through async notifications

That is a full sub-agent runtime pipeline.

6.2 AgentTool.call() Is The Orchestration Controller

Its responsibilities go far beyond "call another agent":

• parse input fields like description, prompt, subagent_type, model, run_in_background, team_name, mode, isolation, and cwd
• detect teammate spawns
• handle team context
• decide whether background execution is allowed
• split fork paths from normal paths
• filter agents through permission rules
• check MCP requirements
• pick the selected agent
• handle remote isolation
• assemble prompts and messages
• register foreground or async tasks
• start worktree isolation if needed
• call runAgent()

This is real orchestration logic.

6.3 Fork Path Versus Normal Path

The source draws a clear branch.

Fork path:

• subagent_type omitted while forking is enabled
• inherits the parent system prompt
• builds prompt messages with buildForkedMessages()
• uses the parent thread's full context
• tries to keep the tool set aligned with the parent for prompt cache reuse
• enables exact-tool reuse

Normal path:

• a built-in or custom agent type is specified
• builds a fresh agent system prompt from the agent definition
• passes only relevant context
• applies that agent's own tool restrictions

Forking is therefore not just "launch another agent". It is a special execution path optimized for context inheritance and cache reuse.

6.4 Why Fork Emphasizes A Cache-Identical Prefix

The comments make the design intent explicit: fork paths try to preserve byte-identical request prefixes so prompt cache hits remain high.

This is a product-grade optimization. The goal is not only "make the subtask run" but also "make it run without wasting tokens."

6.5 Background And Foreground Agents Have Different Lifecycles

AgentTool.call() may choose among:

• synchronous foreground execution
• asynchronous background execution
• remote-launched execution
• teammate-spawned execution

Background path characteristics:

• registers an async agent task
• uses a separate abort controller
• may continue while the main thread proceeds
• returns later via notification
• may optionally summarize automatically
• can expose an output file, though peeking is discouraged

Foreground path characteristics:

• the main thread waits for completion
• execution can be moved into the background in some flows
• foreground tasks have explicit registration and progress tracking

This is lifecycle engineering, not a function call.

6.6 runAgent() Is The Real Sub-Agent Runtime Constructor

runAgent.ts handles substantial work:

• initialize agent-specific MCP servers
• filter and clone context messages
• handle file-state cache
• gather system and user context
• slim claudeMd and git status for read-only agents
• build agent-specific permission modes
• resolve tools
• obtain the agent system prompt
• create abort controllers
• run SubagentStart hooks
• register frontmatter hooks
• preload frontmatter skills
• merge agent-specific MCP tools
• create the sub-agent ToolUseContext
• enter the main loop through query()
• record transcripts
• clean up MCP, hooks, perfetto traces, todos, bash tasks, and more

That makes runAgent() a full runtime constructor for sub-agents.

6.7 Agent-Specific MCP Servers Are Additive Capability Injection

initializeAgentMcpServers() allows an agent definition to bring its own MCP servers.

It can:

• reference existing servers by name
• define agent-specific MCP servers in frontmatter
• connect to those servers
• fetch tools
• merge those tools into the agent's available tool set
• clean them up when the agent exits

This is a strong extensibility mechanism for specialized agents.

6.8 Frontmatter Hooks And Frontmatter Skills

runAgent() also registers frontmatter hooks and preloads skills declared on the agent definition.

That means an agent is not a hardcoded role. It is also a configurable prompt container with runtime-attachable capabilities.

6.9 query() Is The Final Main Loop Executor

Even without expanding the entire query.ts, the layering is clear:

• AgentTool routes and schedules
• runAgent builds lifecycle and runtime context
• query performs the actual model-message and tool-calling loop

6.10 Transcript, Metadata, And Cleanup Prove Productization

runAgent() includes product-grade lifecycle details like:

• sidechain transcript recording
• agent metadata writing
• perfetto registration
• cleanup tracking
• shell-task termination
• session-hook cleanup
• cloned file-state cleanup
• todo cleanup

Anthropic is treating sub-agents as real product runtime entities.

7. Skills, Plugins, Hooks, And MCP

7.1 Skills Are Workflow Packages, Not Just Docs

The source treats Skill as a first-class primitive.

The Skill tool logic makes clear that:

• if a task matches a skill, the model must call the Skill tool
• it should not merely mention the skill without invoking it
• slash commands may act as skill entrypoints
• if a skill has already been injected through tags, it should not be redundantly called again

A skill is best understood as:

• a markdown prompt bundle
• with frontmatter metadata
• optionally declaring allowed tools
• injectable on demand into current context
• compressing repeatable workflows into reusable capability packages

7.2 Plugins Are Prompt, Metadata, And Runtime Constraints

A key file here is src/utils/plugins/loadPluginCommands.ts.

Plugins can provide:

• markdown commands
• SKILL.md directories
• command metadata
• user config
• shell frontmatter
• allowed tools
• model and effort hints
• user-invocable declarations
• model-invocation disabling
• runtime variable substitution

This makes plugins behavior-layer extensions, not ordinary CLI plug-ins.

7.3 Hooks Form A Runtime Governance Layer

The hook system supports:

• PreToolUse
• PostToolUse
• PostToolUseFailure

Hook outputs are not limited to logging. They can return:

• user-visible messages
• blocking errors
• updated input
• permission behavior overrides
• continuation prevention
• stop reasons
• additional contexts
• updated MCP tool output

That is a policy layer for runtime control.

7.4 Hooks And Permissions Are Maturely Integrated

resolveHookPermissionDecision() shows that:

• hooks can recommend allow, ask, or deny
• hook-level allow does not automatically override global deny or ask rules
• if user interaction is still required, the unified permission flow still applies
• hooks may satisfy missing input by returning updatedInput

Hooks are powerful, but they do not bypass the safety model.

7.5 MCP Is Not Just A Tool Bridge

The prompt assembly includes sections such as getMcpInstructionsSection() and getMcpInstructions(mcpClients).

If a connected MCP server exposes instructions, those instructions are injected into the system prompt.

That means MCP can inject both:

1. tools
2. usage guidance for those tools

This makes MCP a behavior-injection layer, not just a registry.

8. Permissions, Hooks, And The Tool Execution Pipeline

8.1 toolExecution.ts Is The True Tool Runtime Spine

The actual execution chain looks roughly like this:

1. find the tool
2. parse MCP metadata
3. validate input schema
4. run tool-specific validateInput
5. run speculative classifier checks for Bash when needed
6. execute PreToolUse hooks
7. resolve hook permission results
8. perform the permission decision
9. update input again if permissions modify it
10. execute tool.call()
11. record analytics, tracing, and telemetry
12. run PostToolUse hooks
13. handle structured output and tool_result blocks
14. if execution fails, run PostToolUseFailure hooks

This is a governed runtime pipeline.

8.2 Input Validation Blocks Basic Errors Early

Before execution, tools go through:

• schema parsing
• tool-specific input validation

If validation fails, Claude Code returns a structured error tool_result instead of blindly reaching the execution layer.

8.3 PreToolUse Hooks Are The Main Interception Point

These hooks can produce:

• ordinary messages
• hook permission results
• updated input
• continuation prevention
• stop reasons
• additional context
• full stop decisions

The most important fields are:

• updatedInput
• permissionBehavior
• preventContinuation

This lets hooks directly shape control flow.

8.4 resolveHookPermissionDecision() Is A Key Semantic Glue Layer

This logic is valuable because it defines how hook decisions fit into the permission model:

• hook-level allow does not automatically bypass settings
• if a tool needs user interaction and hooks did not provide updated input, the normal permission path still runs
• ask-style hook results are forwarded as forced decisions
• deny-style results apply directly

The permission model remains centralized.

8.5 Tool Completion Is Not The End Of The Story

runPostToolUseHooks() and runPostToolUseFailureHooks() show that successful execution is not the final stage.

After success, hooks can still:

• append messages
• inject additional context
• block further continuation
• rewrite MCP tool output

After failure, hooks can still:

• add failure context
• block the next step
• provide recovery guidance

This is a major reason the system is more governable than naive tool-calling loops.

9. Why Claude Code Feels So Strong

9.1 It Is Not A Prompt, But An Operating Model

Many coding agents replicate only:

• a system prompt
• a file edit tool
• a bash tool
• a CLI shell

Claude Code's real moat is the operating model around those pieces:

• prompt architecture
• governed tool runtime
• permission modeling
• hooks as policy controls
• agent specialization
• workflow packaging through skills
• plugin integration
• MCP instruction injection
• prompt cache optimization
• async, background, and remote lifecycle handling
• transcript, telemetry, cleanup, and task systems

9.2 It Institutionalizes Good Behavior

One of Claude Code's biggest strengths is not simply model intelligence. It is that good engineering habits are written into prompts and runtime rules.

Examples include:

• do not add unnecessary features
• do not over-abstract
• do not blindly retry denied tools
• do not claim success without verification
• do not take risky actions casually
• do not let fork outputs pollute the main context
• invoke a matching skill instead of merely naming it
• verification must execute commands, not just inspect code

That institutionalization greatly improves consistency.

9.3 It Understands That Context Is A Scarce Resource

The source repeatedly optimizes around context scarcity:

• static versus dynamic system prompt boundaries
• prompt cache boundaries
• fork-path cache reuse
• on-demand skill injection
• MCP instructions injected only when connected
• function-result clearing
• summarized tool results
• compacting, transcript handling, and resume mechanisms

Tokens are treated as runtime budget, not free air.

9.4 Agent Specialization Is A Deep Advantage

The Explore, Plan, and Verification agents matter not because there are three more agents, but because they separate concerns:

• exploration does not pollute the main thread
• planning is isolated from implementation
• verification is independent from the implementer bias

Many systems fail because one agent is expected to explore, plan, implement, and validate everything.

9.5 The Ecosystem Is Model-Aware

A final strong point is that Claude Code's ecosystem is visible to the model itself.

Through:

• skill lists
• agent lists
• MCP instructions
• session-specific guidance
• command integration

The model knows what extensions exist, when to use them, and how to use them. That is why the ecosystem actually works.

10. Key Files And Further Research Directions

10.1 Core Prompt Files

Main system prompt:

• src/constants/prompts.ts

Agent tool prompt:

• src/tools/AgentTool/prompt.ts

Skill tool prompt:

• src/tools/SkillTool/prompt.ts

Other tool-specific prompt files worth deeper study:

• src/tools/FileReadTool/prompt.ts
• src/tools/GlobTool/prompt.ts
• src/tools/GrepTool/prompt.ts
• src/tools/BriefTool/prompt.ts

10.2 Core Agent Files

• src/tools/AgentTool/AgentTool.tsx
• src/tools/AgentTool/runAgent.ts
• src/tools/AgentTool/resumeAgent.ts
• src/tools/AgentTool/forkSubagent.ts
• src/tools/AgentTool/agentMemory.ts
• src/tools/AgentTool/agentMemorySnapshot.ts
• src/tools/AgentTool/builtInAgents.ts

Built-in agents:

• src/tools/AgentTool/built-in/exploreAgent.ts
• src/tools/AgentTool/built-in/planAgent.ts
• src/tools/AgentTool/built-in/verificationAgent.ts
• src/tools/AgentTool/built-in/generalPurposeAgent.ts
• src/tools/AgentTool/built-in/claudeCodeGuideAgent.ts
• src/tools/AgentTool/built-in/statuslineSetup.ts

10.3 Core Skill, Plugin, Hook, And MCP Files

Skill-related files:

• src/tools/SkillTool/constants.ts
• src/tools/SkillTool/prompt.ts
• src/commands.ts

Plugin-related file:

• src/utils/plugins/loadPluginCommands.ts

Hook-related files:

• src/services/tools/toolHooks.ts
• src/utils/hooks.js

Tool execution:

• src/services/tools/toolExecution.ts

MCP-related files:

• src/services/mcp/types.ts
• src/services/mcp/normalization.ts
• src/services/mcp/mcpStringUtils.ts
• src/services/mcp/utils.ts
• src/entrypoints/mcp.ts

10.4 Good Next Areas To Investigate

A second round of analysis should focus on:

1. query.ts for the main conversation and tool loop
2. resumeAgent.ts for agent resumption
3. loadSkillsDir for the full skills loading chain
4. plugin loading and bundled plugin behavior
5. systemPromptSections.ts for prompt section registration details
6. coordinator/* for multi-agent coordination patterns
7. attachments.ts for how skills, agents, and MCP deltas are injected into messages
8. AgentSummary for background-agent progress summarization

Conclusion

If there is only one sentence to keep from this report, it is this:

The real secret of Claude Code is not a system prompt. It is a unified system that combines prompt architecture, tool runtime, permission modeling, agent orchestration, skill packaging, plugin systems, hook governance, MCP integration, context hygiene, and product engineering.

That is why Claude Code behaves less like a chat interface with tools and more like a governable, extensible, product-grade Agent Operating System.