System Prompts of 34 AI Coding Tools - What They Reveal

What is a system prompt?

Every AI coding tool - Claude Code, Cursor, Windsurf, Devin - receives a set ofhidden instructions before you even talk to it. These instructions define its behavior: what it can do, what it must not do, how it responds, what tone it adopts, which tools it uses.

This is the system prompt - the "source code" of the agent's behavior. You never see it in the interface. But it's what determines whether the tool asks for confirmation before deleting a file, whether it adds comments to code, or whether it refuses to do a git push --force.

A GitHub repo has collected these prompts for 34 AI coding tools. Over 30,000 lines of instructions that reveal how these products are built - not at the code level, but at the level of behavioral rules.

The 34 documented tools

Here's the full list of tools whose system prompts are available in the repo:

Editors and AI IDEs

Autonomous AI agents

Application generators

Specialized tools

What we learn reading these prompts

1. Everyone imposes the same guardrails

Whether it's Claude Code, Cursor, or Devin, the same rules come up systematically:

• Never do a git push --force without explicit confirmation
• Never modify the user's git config of the user
• Never commit sensitive files (.env, credentials, API keys)
• Always read a file before modifying it - never propose changes blindly
• Prefer edits over full rewrites - modify surgically rather than replace everything

These rules aren't there by chance. They come from real bugs - users who lost code, corrupted their git history, or pushed secrets to production. Every guardrail line in a system prompt is a post-mortem incident.

2. The tone is precisely calibrated

Claude Code gets explicit instructions on its tone: "Professional objectivity - prioritize technical accuracy over validating the user's beliefs", "avoid over-the-top validation or excessive praise". The prompt literally forbids expressions like "You're absolutely right".

Cursor and Windsurf have similar instructions but calibrated differently - more conversational, more "assistant-like". This is a deliberate product decision: the agent's tone is part of the user experience just as much as the graphical interface.

3. The tools define when NOT to act

A fascinating pattern: a large part of the system prompts is devoted to what the agent must not do. Claude Code has detailed instructions on when not to use certain tools (don't use Bash to read files when Read exists), when not to commit, when not to deploy.

It's counterintuitive - you'd think prompts say what to do. In reality, most of the work consists of preventing the agent from doing too much. AI is proactive by default; the system prompt frames it.

4. Context management is a central concern

All agents have instructions on how to manage their context window:

• Prefer specialized tools over generic bash commands (fewer tokens consumed)
• Parallelize tool calls when operations are independent
• Use subagents for exploratory tasks (avoid polluting the main context)
• Limit file reading to relevant sections rather than loading everything

This is the most instructive part for anyone writing CLAUDE.md or skills: the creators of these tools aggressively optimize context consumption. If you write instructions for an AI agent, do the same.

5. Tool definitions reveal the architecture

Some repos (Cursor, v0, Lovable) include the Tools.json files - the list of tools the agent can call, with their parameters and descriptions. This is a goldmine for understanding the internal architecture:

• v0 has specific tools to generate React + Tailwind code, with strict JSON schemas for each component
• Lovable exposes tools for creating files, running commands, and preview - revealing its sandboxed architecture
• Cursor evolved from a simple v1.0 prompt to a complex v2.0 system with dedicated CLI tools - you can see the product's evolution through its prompts

What this changes for you

Writing better CLAUDE.md files

If you use Claude Code, your CLAUDE.md is a system prompt you write yourself. Reading professional prompts teaches you patterns that work:

• Be prescriptive about prohibitions - "never do X" is more effective than "try to do Y"
• Give concrete examples - good prompts show the expected format, not just the rule
• Structure by category - security, tone, tools, workflow, each section has its role
• Explicitly prioritize - "use tool A first, B as fallback" works better than "use A or B"

Understanding your tool's limits

System prompts also reveal the intentional limits of each tool. When Claude Code refuses to do a push --force, it's not a bug - it's a decision written in black and white in its prompt. Knowing these rules saves you from fighting the tool.

Choosing between tools

The prompts reveal the product philosophy of each tool. Claude Code is oriented toward a "senior engineer who doesn't flatter"; Cursor is more of a "collaborative assistant"; Devin is an "autonomous agent that plans". If you're torn between these tools, reading their prompts tells you more than any comparison article.

The elephant in the room: ethics

This repo raises a delicate question. These system prompts are intellectual property. They weren't voluntarily published by the companies - they were extracted through reverse engineering (prompt injection, reading local files, intercepting API requests).

The repo is under a GPL-3.0 license, but that doesn't legitimize the extraction itself. Companies invest time and expertise in writing these prompts - it's a significant part of their products' value.

That said, transparency also has benefits:

• Users better understand the tools they pay for
• The community can identify security flaws
• Developers writing their own prompts (CLAUDE.md, skills) learn from the best

It's a bit like the open source vs proprietary debate: transparency pushes everyone to improve, but it doesn't always respect the boundaries of intellectual property. It's up to each person to navigate this tension.

Key takeaways

• System prompts are the real product - the graphical interface is just the surface. Behavioral rules define the user experience
• The same patterns repeat everywhere - git guardrails, read-before-write, tool parallelization. These are de facto standards
• Your CLAUDE.md is a system prompt - apply the same techniques: explicit prohibitions, concrete examples, clear priorities
• Prompts evolve with the product - Cursor has 7 documented versions. A prompt is never finished, it's continuously refined
• Context optimization is critical - all professional prompts devote instructions to saving tokens. Do the same in your instructions