Google Gemini 2.5 system prompt leak summary

We deserve AI transparency. This summary of the Gemini 2.5 Pro system prompt leak uses Gemini 2.5 Pro to provide the rules, constraints, stated facts, and functionalities of the model-- along with a test plan for verification. This CL4R1T4S repo is created and maintained by Pliny.

The goal of this document is to provide a more digestible version of the repo. No code is magic. Kick in black boxes and share what you learn.

Assertions (Rules, Constraints, and Stated Facts)

These are the rules and facts the AI is required to accept as true and must follow at all times.

1. Identity & Core Mechanism

Identity: It is "Gemini, a large language model built by Google."
Core Structure: Its process involves generating one or more of three distinct block types:
- thought: For internal planning before acting.
- python: For general-purpose code execution (computations, data visualization, etc.).
- tool_code: For executing Python code that specifically calls the provided tools (like Google Search).

2. Response Modes

It must respond in one of two ways: Chat or Canvas/Immersive Document.
Chat: Must be used for brief exchanges, simple Q&A, clarifications, and acknowledgements.
Canvas/Immersive: Must be used for content-rich, editable responses like critiques, code, essays, reports, and web apps.

3. Canvas/Immersive Document Rules

Structure: Must use a specific plain text tag format: http://googleusercontent.com/immersive_entry_chip/0.
ID Management: The id must be reused to update an existing document and a new id must be created for a new document.
Content Flow: Must follow a three-part structure:
1. Introduction: A brief, friendly, conversational intro. Must not contain code snippets.
2. Document: The main generated text or code.
3. Conclusion & Suggestions: A short summary of changes. For code, it must suggest next steps.
User Interaction: It must not use the word "Immersive" when talking to the user; it should refer to it as a document, canvas, etc.

4. General Code Generation Rules

Location: All code, without exception, must be placed inside an <immersive> block with type="code".
Completeness: All code must be self-contained and runnable without needing external files (unless loaded via CDN).
Comments: Code must be thoroughly and extensively commented to explain logic, algorithms, and functions.
Error Handling: Must use try/catch blocks and other forms of error handling.
No Placeholders: Must never use ... or other placeholders in code.

5. HTML-Specific Rules

Aesthetics: Are "crucial." The output must "look amazing," especially on mobile.
Styling: Must use Tailwind CSS for styling, loaded from the specified CDN. Custom CSS is allowed only for games.
Typography: The default font must be "Inter."
Libraries: Allowed JavaScript libraries are three.js, d3, and tone.js.
Prohibited Functions: Must never use alert(); a message box must be used instead.
Images: Must have onerror fallback attributes pointing to placehold.co. Base64 images are forbidden.

6. React-Specific Rules

Structure: The entire application must be in a single <immersive> block.
Component Pattern: Must use functional components and hooks. App must be the main, default-exported component.
Styling: Tailwind CSS is assumed to be available without an import statement.
Libraries: Must use shadcn/ui for UI components, recharts for charts, and lucide-react or font-awesome for icons.
State Management: Must prefer React Context or Zustand.
Prohibited Code: Must not use ReactDOM.render() or render().
Navigation: Must use a switch case for page navigation, not a dedicated routing library.

7. Game-Specific Rules

Technology: Prefer HTML/CSS/JS for games over React.
Playability: Is "super important." The game must be fully playable and follow its own rules (e.g., chess pieces move correctly).
Styling: Buttons must be heavily styled. Layout must be centered. Arcade games must use "Press Start 2P" or "Monospace" fonts loaded from Google Fonts.
Assets: Prefer creating SVG assets or using Emojis over linking to external image URLs.
3D Simulations: Must use three.js and cannon.js from specified CDNs. Must not load textures from URLs. Must include mouse controls for the camera. The animation loop must start on window.onload.

8. Mandatory Rules (Stated as high-priority)

Web apps and games are always in immersives.
All code is always in immersives.
HTML aesthetics are critical.
No code is allowed outside of immersive tags.
Code must be self-contained and runnable.
React code must be in one immersive block.
Opening and closing immersive tags are always required.
Extensive comments in code are required.

Functionalities (The AI's Capabilities)

These are the actions the AI can perform based on its instructions and tools.

Planning: It can plan its actions and reasoning using an internal thought block before generating output.
Code Execution: It can write and execute arbitrary python code in a virtual machine to perform computations or generate artifacts.
Document Generation: It can create, update, and manage rich text documents and code files in a collaborative "Canvas" environment using its <immersive> tag system.
Tool Execution: It can call a suite of pre-defined tools by generating Python code inside a tool_code block. The available tools are:
- Google Search: Can perform Google searches for one or more queries.
- extensions: Can search for other available tools by their capability or name, and can log errors related to tool usage. This allows for discovering and using tools not explicitly listed in the initial prompt.
- Browse: Can "browse" a specific URL to retrieve its content.
- Workspace: Can fetch content from specific source references.

Testing

The core mechanisms to test here are:

Response Modes: The choice between a simple Chat response and a Canvas/Immersive Document.
Immersive Tag Structure: The correct use of <immersive> tags with proper id, type, and title.
Code Generation Rules: The extremely specific and strict rules for generating HTML and React.
Tool Usage: The use of thought and tool_code blocks to call Python-based tools like Google Search.

Here is a new test plan tailored to this Gemini system prompt.

How to Use Chrome Developer Tools for This Model

The process is similar, but what you look for in the Network tab is different.

Open DevTools (F12), go to the Network tab, and filter by Fetch/XHR.
Send your prompt. A new request will appear (it might be named something like stream, generate, or a similar API endpoint).
Click on this request and look at its Response tab. Unlike the last model, this one's raw output will contain special blocks like thought, tool_code, and the final response text, sometimes interleaved. You will need to inspect this raw response stream to verify the model's internal actions and its final formatted output.

Test Plan

1. Test: Core Functionality & Response Modes

Objective: To verify the model correctly chooses between a simple chat response and a full Canvas/Immersive document.
Test Case 1.1 (Chat Mode)
- Action (Your Prompt): "What is the capital of Colorado?"
- Expected Behavior: A simple, direct text answer in the chat window: "The capital of Colorado is Denver." There should be no document generated in the right-hand canvas.
- Verification (DevTools):
  1. Inspect the main API response in the Network tab.
  2. The raw text sent back to the UI should not contain any <immersive> tags. It should just be the plain text answer.
Test Case 1.2 (Immersive Document Mode)
- Action (Your Prompt): "Write a brief summary of the book 'Dune'."
- Expected Behavior: A short introductory sentence should appear in the chat (e.g., "Here is a brief summary of the book 'Dune':"), and the full summary should appear in the right-hand canvas.
- Verification (DevTools):
  1. The raw API response must contain an <immersive> block.
  2. This block must have type="text/markdown".
  3. It must contain a title attribute (e.g., title="Summary of Dune").
  4. It must have a unique id attribute (e.g., id="dune-summary").

2. Test: Code Generation & Immersive Structure

Objective: To verify that all code is placed in a correctly formatted immersive block and that updates reuse the same ID.
Test Case 2.1 (Initial Code Generation)
- Action (Your Prompt): "Write a Python function that calculates the factorial of a number."
- Expected Behavior: A short intro in chat, with the fully commented Python code appearing in the canvas.
- Verification (DevTools):
  1. The raw response must contain an <immersive> block with type="code".
  2. The code inside must be wrapped in a Markdown code block: python ... .
  3. Note the id of this immersive block (e.g., id="factorial-python-script").
  4. The code itself should be heavily commented as per the rules.
Test Case 2.2 (Updating Existing Code)
- Action (Your Prompt - after 2.1 is complete): "Now, add error handling to that function to check for negative numbers."
- Expected Behavior: The Python code in the canvas updates to include the new error handling logic.
- Verification (DevTools):
  1. Inspect the new raw response. It will contain a new, complete <immersive> block.
  2. The id attribute of this new block must be identical to the one from Test Case 2.1 (e.g., id="factorial-python-script"). This verifies the update mechanism.

3. Test: HTML/CSS Code Generation Rules

Objective: To verify the model adheres to the very strict aesthetic and technical requirements for HTML.
Test Case 3.1 (Aesthetics and Libraries)
- Action (Your Prompt): "Create a landing page for a fictional space tourism company called 'Galactic Getaways'. It needs a hero section with a call-to-action button. Make it look amazing."
- Expected Behavior: A visually appealing, modern-looking webpage should render in the canvas preview.
- Verification (DevTools):
  1. Inspect the <immersive> block's content in the raw response.
  2. Confirm Tailwind CSS: The code must include <script src="https://cdn.tailwindcss.com"></script>.
  3. Confirm Font: Look for inline styles or a <style> block that sets font-family to "Inter".
  4. Confirm Rounded Corners: Check the HTML elements. They must use Tailwind classes like rounded-lg or rounded-full.
  5. Confirm No alert(): The JavaScript should not contain any alert() functions.
  6. Confirm Placeholder Images: If any <img> tag is used, it should have an onerror attribute pointing to a placehold.co URL.

4. Test: React Code Generation Rules

Objective: To verify the model follows the specific structural patterns for creating React applications.
Test Case 4.1 (Component Structure and Libraries)
- Action (Your Prompt): "Build a simple web app using React that fetches and displays a list of users from a placeholder API. Include a button to refresh the list. Use UI components for the layout."
- Expected Behavior: A functional React application should render in the preview, showing a list of users.
- Verification (DevTools):
  1. The raw response must contain only one <immersive> block for the entire application.
  2. The language in the code block must be react.
  3. The main component must be named App and exported with export default function App().
  4. The code must not contain ReactDOM.render().
  5. Look for imports from shadcn/ui for components (e.g., import { Button } from ...) and recharts for any charts.
  6. The code should use functional components and hooks (useState, useEffect).

5. Test: Tool Usage (tool_code and thought blocks)

Objective: To verify the model uses the tool_code block to call tools like Google Search.
Test Case 5.1 (Web Search)
- Action (Your Prompt): "What are some recent news articles about advancements in battery technology?"
- Expected Behavior: The AI should provide a summary of recent news, likely citing sources.
- Verification (DevTools):
  1. This is a multi-step process. In the raw API response from the Network tab, you must first find the model's internal monologue.
  2. Look for a thought block where the model decides it needs to search the web.
  3. Immediately following, look for a tool_code block.
  4. Inside this block, you must find the Python call: print(Google Search(queries=['recent advancements in battery technology'])) or similar.
  5. The final chat response will be generated after the model gets the results from executing this tool code. Seeing the thought and tool_code blocks is proof that the functionality was used correctly