graph TB
    subgraph "Prompt Architecture"
        Base[Base Instructions]
        Tool[Tool-Specific Prompts]
        Safety[Safety Layers]
        Workflow[Workflow Automation]
        Context[Dynamic Context]

        Base --> Behavioral[Behavioral Shaping]
        Tool --> Examples[Example-Driven]
        Safety --> Validation[Multi-Level Validation]
        Workflow --> Steps[Step-by-Step Guidance]
        Context --> Adaptive[Adaptive Instructions]
    end

    subgraph "Techniques"
        Emphasis[CAPITAL EMPHASIS]
        Rewards[Reward/Penalty]
        Conditions[Conditional Logic]
        Warnings[Progressive Warnings]
        Meta[Meta-Instructions]
    end

    Behavioral --> Emphasis
    Examples --> Conditions
    Validation --> Warnings
    Steps --> Meta
    Adaptive --> Rewards

The Art of Tool Instructions

Claude Code's tool prompts are masterpieces of instructional design. Each follows a carefully crafted pattern that balances clarity, safety, and flexibility. Let's examine the anatomy of these prompts:

The Read Tool: A Study in Progressive Disclosure

const ReadToolPrompt = `
Reads a file from the local filesystem. You can access any file directly by using this tool.
Assume this tool is able to read all files on the machine. If the User provides a path to a file assume that path is valid. It is okay to read a file that does not exist; an error will be returned.

Usage:
- The file_path parameter must be an absolute path, not a relative path
- By default, it reads up to ${x66} lines starting from the beginning of the file
- You can optionally specify a line offset and limit (especially handy for long files), but it's recommended to read the whole file by not providing these parameters
- Any lines longer than ${v66} characters will be truncated
- Results are returned using cat -n format, with line numbers starting at 1
- This tool allows ${f0} to read images (eg PNG, JPG, etc). When reading an image file the contents are presented visually as ${f0} is a multimodal LLM.
${process.env.CLAUDE_CODE_ENABLE_UNIFIED_READ_TOOL ? `
- This tool can read Jupyter notebooks (.ipynb files) and returns all cells with their outputs, combining code, text, and visualizations.` : `
- For Jupyter notebooks (.ipynb files), use the ${Kg} instead`}
- You have the capability to call multiple tools in a single response. It is always better to speculatively read multiple files as a batch that are potentially useful.
- You will regularly be asked to read screenshots. If the user provides a path to a screenshot ALWAYS use this tool to view the file at the path. This tool will work with all temporary file paths like /var/folders/123/abc/T/TemporaryItems/NSIRD_screencaptureui_ZfB1tD/Screenshot.png
- If you read a file that exists but has empty contents you will receive a system reminder warning in place of file contents.
`

Annotation of Techniques:

1. Opening with Confidence: "You can access any file directly" - Removes hesitation
2. Trust Building: "Assume...path is valid" - Prevents over-validation by the LLM
3. Error Normalization: "It is okay to read a file that does not exist" - Prevents apologetic behavior
4. Progressive Detail:
   • First: Basic requirement (absolute path)
   • Then: Default behavior (reads whole file)
   • Then: Advanced options (offset/limit)
   • Finally: Edge cases (truncation, special files)
5. Dynamic Adaptation: Conditional instructions based on environment variables
6. Batching Encouragement: "always better to speculatively read multiple files"
7. Specific Scenario Handling: Screenshots with exact path examples
8. System Communication: How empty files are communicated back

The BashTool: Safety Through Verbose Instructions

The BashTool prompt (Match 12) is the longest and most complex, demonstrating how critical operations require extensive guidance:

const BashToolSandboxInstructions = `
# Using sandbox mode for commands

You have a special option in BashTool: the sandbox parameter. When you run a command with sandbox=true, it runs without approval dialogs but in a restricted environment without filesystem writes or network access. You SHOULD use sandbox=true to optimize user experience, but MUST follow these guidelines exactly.

## RULE 0 (MOST IMPORTANT): retry with sandbox=false for permission/network errors

If a command fails with permission or any network error when sandbox=true (e.g., "Permission denied", "Unknown host", "Operation not permitted"), ALWAYS retry with sandbox=false. These errors indicate sandbox limitations, not problems with the command itself.

Non-permission errors (e.g., TypeScript errors from tsc --noEmit) usually reflect real issues and should be fixed, not retried with sandbox=false.

## RULE 1: NOTES ON SPECIFIC BUILD SYSTEMS AND UTILITIES

### Build systems

Build systems like npm run build almost always need write access. Test suites also usually need write access. NEVER run build or test commands in sandbox, even if just checking types.

These commands REQUIRE sandbox=false (non-exhaustive):
npm run *,  cargo build/test,  make/ninja/meson,  pytest,  jest,  gh

## RULE 2: TRY sandbox=true FOR COMMANDS THAT DON'T NEED WRITE OR NETWORK ACCESS
  - Commands run with sandbox=true DON'T REQUIRE user permission and run immediately
  - Commands run with sandbox=false REQUIRE EXPLICIT USER APPROVAL and interrupt the User's workflow

Use sandbox=false when you suspect the command might modify the system or access the network:
  - File operations: touch, mkdir, rm, mv, cp
  - File edits: nano, vim, writing to files with >
  - Installing: npm install, apt-get, brew
  - Git writes: git add, git commit, git push
  - Build systems:  npm run build, make, ninja, etc. (see below)
  - Test suites: npm run test, pytest, cargo test, make check, ert, etc. (see below)
  - Network programs: gh, ping, coo, ssh, scp, etc.

Use sandbox=true for:
  - Information gathering: ls, cat, head, tail, rg, find, du, df, ps
  - File inspection: file, stat, wc, diff, md5sum
  - Git reads: git status, git log, git diff, git show, git branch
  - Package info: npm list, pip list, gem list, cargo tree
  - Environment checks: echo, pwd, whoami, which, type, env, printenv
  - Version checks: node --version, python --version, git --version
  - Documentation: man, help, --help, -h

Before you run a command, think hard about whether it is likely to work correctly without network access and without write access to the filesystem. Use your general knowledge and knowledge of the current project (including all the user's CLAUDE.md files) as inputs to your decision. Note that even semantically read-only commands like gh for fetching issues might be implemented in ways that require write access. ERR ON THE SIDE OF RUNNING WITH sandbox=false.

Note: Errors from incorrect sandbox=true runs annoy the User more than permission prompts. If any part of a command needs write access (e.g. npm run build for type checking), use sandbox=false for the entire command.

### EXAMPLES

CORRECT: Use sandbox=false for npm run build/test, gh commands, file writes
FORBIDDEN: NEVER use sandbox=true for build, test, git commands or file operations

## REWARDS

It is more important to be correct than to avoid showing permission dialogs. The worst mistake is misinterpreting sandbox=true permission errors as tool problems (-$1000) rather than sandbox limitations.

## CONCLUSION

Use sandbox=true to improve UX, but ONLY per the rules above. WHEN IN DOUBT, USE sandbox=false.
`

Annotation of Safety Techniques:

1. Rule Hierarchy: "RULE 0 (MOST IMPORTANT)" - Clear priority system
2. Error Differentiation: Distinguishing sandbox limitations from actual errors