system-prompts-and-models-of-ai-tools/TOOL_PATTERNS.md

🔍 Common Patterns in AI Coding Tool Prompts

Analysis of recurring patterns, instructions, and architectures across 31+ AI coding tools

---

📊 Overview

After analyzing system prompts from Cursor, GitHub Copilot, Claude Code, Amp, Windsurf, and 26+ other tools, clear patterns emerge in how these systems are designed and instructed.

---

🎯 Core Instruction Patterns

1. Role Definition

Every tool starts by defining its identity and capabilities.

Common Pattern:

You are [NAME], a [TYPE] AI coding assistant.
You help the user with [PRIMARY TASKS].
Use the instructions below and the tools available to you to help the user.

Examples:

• Cursor: "You are a powerful agentic AI coding assistant, powered by Claude 3.7 Sonnet"
• Amp: "You are Amp, a powerful AI coding agent built by Sourcegraph"
• Claude Code: "You are an interactive CLI tool that helps users with software engineering tasks"

Key Insight: Strong identity = clearer behavior boundaries

---

2. Tool Usage Instructions

All tools follow similar patterns for tool interaction.

Universal Rules:

1. ALWAYS follow the tool call schema exactly
2. NEVER refer to tool names when talking to users
3. Only call tools when necessary
4. Explain why you're calling a tool before calling it (optional)
5. Never call tools that are no longer available

Example from Cursor:

**NEVER refer to tool names when speaking to the USER.**
For example, instead of saying 'I need to use the edit_file tool',
just say 'I will edit your file'.

Pattern Insight: Tools are implementation details, not user-facing concepts

---

3. Conciseness Mandate

Almost every tool emphasizes brief, direct communication.

Common Instructions:

- Be concise, direct, and to the point
- Answer in 1-3 sentences if possible
- Avoid unnecessary preamble or postamble
- No "The answer is..." or "Based on the information..."
- Skip explanations unless asked

Examples:

• Claude Code: "You MUST answer concisely with fewer than 4 lines"
• Amp: "Keep your responses short. You MUST answer concisely with fewer than 4 lines"
• Cursor: "IMPORTANT: Keep your responses short"

Token Economics: Shorter responses = lower costs + faster iteration

---

4. Code Comment Restrictions

Strong consensus against adding comments to code.

Universal Pattern:

- IMPORTANT: DO NOT ADD ANY COMMENTS unless asked
- No explanatory comments in generated code
- Comments belong in text responses, not code
- Only add comments when:
  1. User explicitly requests them
  2. Code is complex and requires context

Reasoning: Code should be self-documenting; AI explanations go in chat

---

5. Security Guardrails

Every tool includes security-focused instructions.

Common Security Rules:

1. Never introduce code that exposes or logs secrets/keys
2. Never commit secrets to repository
3. Follow security best practices
4. Never create malicious code
5. Redaction markers indicate removed secrets

Example from Claude Code:

IMPORTANT: Assist with defensive security tasks only.
Refuse to create, modify, or improve code that may be used maliciously.

Pattern: Defensive security is table stakes

---

🛠️ Tool Architecture Patterns

6. Standard Tool Categories

Almost identical tool sets across platforms.

Core Tools (Present in 90%+ of tools):

File Operations:
  - read_file / Read
  - edit_file / Edit
  - create_file / Write
  - delete_file

Search & Discovery:
  - codebase_search / semantic_search
  - grep_search / Grep
  - file_search / glob
  - list_directory

Execution:
  - run_terminal_cmd / Bash
  - run_command

Code Quality:
  - get_diagnostics
  - format_file

Web Access:
  - web_search
  - read_web_page

Version Control:
  - git commands (via terminal)

Advanced Tools (Present in 50%+ of tools):

- Sub-agents / Task executors
- Memory/Context management
- Image/multimodal support
- MCP (Model Context Protocol) support

---

7. Sub-Agent Patterns

Modern tools use specialized sub-agents.

Common Sub-Agent Types:

A. Task Executors

Purpose: Execute multi-step, complex tasks independently
Pattern: Fire-and-forget, no mid-execution communication
Examples: Cursor Agent, Amp Task, Claude Code Task

B. Search Agents

Purpose: Intelligent codebase exploration
Pattern: Combines grep, semantic search, file reading
Examples: Amp codebase_search_agent, Cursor codebase_search

C. Reasoning Agents

Purpose: Deep analysis, planning, architecture review
Pattern: Uses advanced models (o3, Claude Opus)
Examples: Amp Oracle, Cursor planning mode

Implementation Pattern:

When to use sub-agents:
- Complex multi-step tasks
- High token cost operations
- Independent workstreams
- Specialized expertise needed

When NOT to use:
- Simple operations
- Need user interaction
- Uncertain requirements

---

8. Context Management Patterns

Pattern 1: Explicit Context Files

Tool: Claude Code, Amp
Method: AGENTS.md / AGENT.md files
Contains:
  - Common commands (test, build, lint)
  - Code style preferences
  - Project structure
  - Tool usage patterns

Pattern 2: Memory Systems

Tool: Cursor
Method: Explicit memory tool with ratings
Features:
  - Remember user preferences
  - Track project context
  - Rate memory importance

Pattern 3: Workspace Caching

Tool: Most tools
Method: Cache directory listings, file structures
Benefits:
  - Faster subsequent operations
  - Reduced API calls

Pattern 4: Prompt Caching

Tool: Claude-based tools
Method: Anthropic's prompt caching
Benefits:
  - Reuse system prompt tokens
  - Lower costs for long prompts

---

9. Parallel Execution Patterns

Modern tools emphasize concurrent operations.

Standard Pattern:

Default to parallel for:
  - Independent file reads
  - Multiple searches
  - Separate code changes
  - Disjoint sub-agent tasks

Serialize only when:
  - Dependency exists
  - Same file editing
  - Shared contract changes

Example from Amp:

Default to **parallel** for all independent work:
reads, searches, diagnostics, writes and **subagents**.
Serialize only when there is a strict dependency.

Performance Impact: 3-10x faster for multi-step operations

---

10. Verification Gate Pattern

Consistent quality check workflows.

Standard Verification Order:

1. Typecheck (TypeScript, etc.)
2. Lint (ESLint, etc.)
3. Tests (Jest, pytest, etc.)
4. Build (compile, bundle)

Implementation Pattern:

After code changes:
1. Run diagnostics tool
2. Execute typecheck command
3. Execute lint command
4. Run test suite
5. Report results concisely

Source of Truth: AGENTS.md or similar context file

---

📝 Communication Patterns

11. File Linking Convention

Universal pattern for referencing code.

Standard Format:

file:///absolute/path/to/file.ext#L42
file:///absolute/path/to/file.ext#L32-L45

Usage Pattern:

- Use fluent linking (embedded in text)
- Always link when mentioning files
- URL-encode special characters
- Include line numbers when specific

Example:

The [`extractAPIToken` function](file:///Users/bob/auth.js#L158)
validates request headers.

---

12. Markdown Formatting Rules

Strict, consistent markdown across tools.

Universal Rules:

- Bullets: Use hyphens `-` only
- Numbered lists: Only for procedural steps
- Headings: Don't skip levels (#, ##, ###)
- Code fences: Always add language tag
- Inline code: Use backticks
- Links: file:// for local, https:// for web
- No emojis (unless user requests)
- Minimal exclamation points

Reasoning: Consistent, parseable output

---

13. Example-Driven Instructions

Most effective teaching method in prompts.

Pattern:

<example>
user: [user query]
assistant: [correct behavior with tool calls]
</example>

<bad-example>
[What NOT to do]
</bad-example>

Why It Works:

• Shows, doesn't just tell
• Handles edge cases
• Clarifies ambiguous instructions
• Faster model learning

Observation: Tools with more examples = better behavior

---

🎯 Task Management Patterns

14. TODO List Pattern

Newer tools emphasize visible progress tracking.

Standard Implementation:

Tools: todo_write, todo_read

When to use:
- Complex multi-step tasks
- Breaking down ambiguous requests
- Giving user visibility

Best practices:
- Create at task start
- Mark in-progress before starting
- Mark completed immediately after finishing
- Don't batch completions

Example from Claude Code:

Examples:
user: Run the build and fix any type errors
assistant:
[uses todo_write]
- [ ] Run the build
- [ ] Fix any type errors

[runs build, finds 10 errors]
[todo_write: adds 10 error items]
[marks first as in_progress]
[fixes it]
[marks as completed]
[continues...]

UI Impact: Makes AI work feel more transparent and controllable

---

15. Planning Before Action Pattern

Distinguish between planning and execution.

Pattern:

If user asks HOW to do something:
  → Explain, don't execute

If user asks you TO DO something:
  → Execute directly

For large tasks:
  → Show brief plan first
  → Wait for approval
  → Then execute

Example:

Bad:
user: "How should I approach authentication?"
assistant: [immediately edits files]

Good:
user: "How should I approach authentication?"
assistant: "Here's the approach: 1... 2... 3..."

user: "Implement user authentication"
assistant: [creates todo list, starts implementing]

---

🔄 Code Editing Patterns

16. Edit vs Create Pattern

Clear distinction in file operations.

Create File When:

- New file doesn't exist
- Want to replace entire file
- More token-efficient than edit

Edit File When:

- Modifying existing code
- Targeted changes
- Preserving surrounding context

Implementation Pattern:

edit_file requires:
  - old_str: Exact text to replace (with context)
  - new_str: Exact replacement text
  - Must be unique match (or use replace_all)

Anti-pattern: Reading entire file to change one line

---

17. Context Before Edit Pattern

Universal requirement to understand before changing.

Standard Pattern:

Before editing:
1. Read the file/section to edit
2. Understand surrounding code
3. Check imports and dependencies
4. Match existing style
5. Then make the change

Example from Cursor:

Unless you are appending some small easy to apply edit,
or creating a new file, you MUST read the contents or
section of what you're editing before editing it.

---

18. Existing Patterns Pattern

Reuse over invention.

Universal Instruction:

Before creating new code:
1. Search for similar patterns
2. Check existing libraries
3. Mirror naming conventions
4. Follow established style
5. Reuse interfaces/schemas

From Amp:

- **Reuse-first**: search for existing patterns;
  mirror naming, error handling, I/O, typing, tests.
- When you create a new component, first look at
  existing components to see how they're written

Anti-pattern: Introducing new patterns not used elsewhere

---

🔐 Advanced Patterns

19. Multi-Model Strategy

Tools increasingly support multiple models.

Common Pattern:

Available models:
- Fast models: For tab completion, simple queries
- Balanced models: For chat, medium tasks
- Powerful models: For complex reasoning

Model selection by:
- Task complexity
- Required capabilities
- User preference
- Cost optimization

Examples:

• Copilot: GPT-4.1, GPT-5, GPT-5-mini, Claude-4, Gemini 2.5
• Cursor: GPT-4, GPT-5, Claude 3.5, Claude 4
• Cline: Any OpenAI/Anthropic/Google model

---

20. Error Handling Pattern

Consistent approach to failures.

Standard Pattern:

When errors occur:
1. Don't loop >3 times on same error
2. Try alternative approach
3. If stuck, ask user
4. Don't suppress errors unless explicitly told
5. Report error context concisely

Linter Error Pattern:

If you've introduced linter errors:
1. Fix if clear how to
2. Don't make uneducated guesses
3. Stop after 3 attempts
4. Ask user for direction

---

21. Git Workflow Pattern

Standardized git integration.

Common Commands:

1. git status  # See changes
2. git diff    # See modifications
3. git log     # See history
4. git add     # Stage files
5. git commit  # Commit with message

Commit Message Pattern:

Format:
[Brief description]

🤖 Generated with [Tool Name](url)
Co-Authored-By: AI <email>

Best Practices:

- Never use interactive git commands (-i flag)
- Always check status first
- Verify staging before commit
- Follow repo's commit style
- Never update git config
- Don't push unless explicitly asked

---

22. Web Search Pattern

When and how to use web access.

When to Search Web:

- User provides URL to read
- Need current information
- Looking for documentation
- Researching libraries
- Finding best practices

When NOT to Search:

- Information in existing knowledge
- Internal codebase questions
- When you have context already

Tool-Specific URLs:

Claude Code: Fetch from docs.anthropic.com/en/docs/claude-code
Amp: Fetch from ampcode.com/manual
Cursor: Check cursor.sh documentation

---

23. Background Process Pattern

Handling long-running commands.

Pattern:

Background processes for:
- Servers (dev, prod)
- Watch modes
- Long builds

Implementation:
- Set is_background: true
- Or use run_in_background parameter
- Never use & operator directly
- Return terminal ID for monitoring

Example:

{
  "command": "npm run dev",
  "is_background": true
}

---

📊 Emerging Patterns

24. Reasoning Model Integration

New pattern with o1/o3 models.

Pattern (Amp Oracle):

Oracle Tool:
- Uses OpenAI o3 reasoning model
- For planning, debugging, architecture
- Has access to: Read, Grep, Web
- Returns detailed analysis

When to use:
- Code reviews
- Complex debugging
- Architecture planning
- Deep analysis

Trend: Separate "thinking" models from "doing" models

---

25. MCP (Model Context Protocol) Pattern

Emerging standard for tool integration.

Pattern:

read_mcp_resource:
  server: "filesystem-server"
  uri: "file:///path/to/file"

Benefits:
- Standardized tool interface
- Third-party integrations
- Extensibility

Adoption: Early but growing

---

26. Workspace State Caching

Performance optimization pattern.

Pattern:

Cache:
- Directory listings
- File structure
- Recent files
- Common reads

Update on:
- File changes
- User navigation
- Explicit refresh

Impact: 50-80% faster context gathering

---

🎓 Best Practice Synthesis

Universal Best Practices Found Across All Tools:

1. ✅ Be Concise - Every tool emphasizes this
2. ✅ Security First - Never log secrets
3. ✅ Verify Changes - Run checks after edits
4. ✅ Understand Before Changing - Read first
5. ✅ Follow Existing Patterns - Reuse over invent
6. ✅ Use Parallel Execution - When possible
7. ✅ Link to Files - Always use file:// URLs
8. ✅ No Code Comments - Unless asked
9. ✅ Respect Context Limits - Be strategic
10. ✅ Plan Complex Tasks - Use TODO lists

---

🔍 Anti-Patterns to Avoid

Common mistakes explicitly called out:

1. ❌ Verbose responses
2. ❌ Unnecessary tool use
3. ❌ Serial when should be parallel
4. ❌ Reading entire file for small edit
5. ❌ Adding comments without request
6. ❌ Suppressing linter errors
7. ❌ Ignoring existing patterns
8. ❌ Not verifying changes
9. ❌ Looping on same error >3x
10. ❌ Mentioning tool names to users

---

📈 Evolution Trends

Comparing older vs newer prompts:

Older Patterns (2023-early 2024):

• Simpler tool sets
• More verbose
• Less parallel execution
• Fewer sub-agents

Newer Patterns (late 2024-2025):

• Sub-agent architecture
• Strict conciseness
• Parallel by default
• Reasoning model integration
• TODO/progress tracking
• AGENTS.md pattern
• MCP support

---

💡 Key Insights

1. Convergent Evolution: Tools independently arrived at similar patterns
2. Token Economics Matter: Conciseness is cost-driven
3. User Experience Focus: Transparency (TODOs) improves trust
4. Security is Universal: Every tool includes guardrails
5. Modularity Wins: Sub-agents are the future
6. Context is King: All tools struggle with context limits
7. Verification is Essential: Every tool checks its work

---

This analysis is based on actual system prompts from 31+ tools in this repository.

Last Updated: October 2, 2025