Official References: GEMINI.md Overview · Project Settings
GEMINI.md is Not Just a Prompt
Many users treat GEMINI.md as simply a "prompt file for the AI." However, in Gemini CLI, this file serves as the core node of a hierarchical memory system. Gemini traverses up from your current execution directory and combines all discovered GEMINI.md files to define the "identity" of the current task.
1. The Hierarchy Strategy
For efficient project management, separate your GEMINI.md files into three distinct levels.
Level 1: Global Level (~/.gemini/GEMINI.md)
Define your personal coding style or security principles that apply to all projects.
- Example: "API keys must never be exposed," "Never suggest code without accompanying tests."
Level 2: Project Level (/your-project/GEMINI.md)
Define the tech stack, architectural patterns, and tool-use rules for a specific project.
- Example: "Use Next.js 16 App Router," "Error handling must always use
src/lib/errors.ts," "Use Prisma MCP for DB access."
Level 3: Directory/Module Level (/your-project/src/components/GEMINI.md)
Define fine-grained rules (JIT context) specific to a module or domain.
- Example: "UI components must always use Tailwind v4," "Wrap all components in
memo."
2. Leveraging JIT (Just-In-Time) Context
The power of Gemini CLI lies in its ability to immediately (JIT) read the GEMINI.md of a folder as soon as you enter it. This prevents attention drift by supplying only the information relevant to the current scope.
Structure Example:
project/
├── GEMINI.md (Global Rules: Next.js, TS)
├── content/
│ └── GEMINI.md (Content Rules: MDX structure, Locale Parity)
└── src/
└── components/
└── GEMINI.md (UI Rules: Atomic Design, Style Guide)3. Five Key Elements for Your GEMINI.md
For successful automation, ensure your file includes these sections:
- Project Context: A summary of the project's purpose and business logic.
- Tech Stack: Framework versions and core library lists.
- Coding Standards: Naming conventions, file structure, and error handling patterns.
- Tooling Rules: Specific instructions on when to use certain MCPs or Sub-agents.
- Verification: Criteria for determining task completion (e.g., successful build, passing tests).
4. GEMINI.md vs. /memory
- GEMINI.md: Explicit, static rules. Guidelines that should be shared by the entire team (Committed to Git).
/memory: Dynamic, personal knowledge. Specific file locations learned during a session or personal preferences (Stored locally).
Pro Tip: If something learned in /memory during a session proves useful for the whole team, move it into the root GEMINI.md.
5. Bad vs. Good Examples
Bad Example (Vague)
"Write clean code." "Add lots of tests."
Good Example (Specific/Structured)
"All functions must include JSDoc; if complexity exceeds 10, split into a separate function." "When modifying business logic, write at least 3 tests in
tests/unitincluding edge cases."
Next to Read
- Techniques for breaking down complex tasks: Gemini Task Decomposition
- How to coordinate multiple specialists: Multi-Agent Orchestration