GEMINI.md

• When a repository wants a dedicated GEMINI.md file and does not already have a strong one
• When you want starter GEMINI.md context to use through Oi API or MCP
• When Gemini-specific instructions should be separated from shared AGENTS.md guidance
• When the current GEMINI.md is weak enough that replacing it with a clean starter is easier than patching it

# GEMINI.md ## Purpose This file adds Gemini-specific guidance for this repository. Keep shared repository rules in AGENTS.md when possible, and use GEMINI.md only for behavior that is genuinely Gemini-specific. ## Read Order 1. User request and linked ticket 2. Product or architecture docs 3. AGENTS.md 4. GEMINI.md 5. README or incidental docs Do not duplicate AGENTS.md unless Gemini needs materially different handling. ## When To Use GEMINI.md Use this file for Gemini-specific execution guidance such as: - output shape and response discipline - tooling habits or shell behavior that are specific to the Gemini runtime - context-window, prompt-structure, or planning preferences unique to Gemini - constraints that should not be imposed on other agents in AGENTS.md If a rule applies equally well to Codex, ChatGPT, Claude, or other runtimes, it belongs in AGENTS.md instead. ## Gemini-Specific Working Style - Prefer concise instructions with explicit task boundaries - Separate hard requirements from heuristics - Keep outputs practical, execution-oriented, and easy to scan - Favor direct answers and concrete next steps over long framing - Avoid generic AI-policy prose that does not change implementation behavior - Avoid duplicating repository context that already exists in AGENTS.md or product docs ## Task Execution - Inspect relevant files before proposing or making changes - Follow the real code path instead of guessed architecture - Preserve repository conventions unless the task explicitly changes them - Keep edits minimal, scoped, and easy to review - State assumptions when context is incomplete - If the task is ambiguous, prefer the safest reasonable interpretation and call it out - For larger changes, keep the plan crisp and tied to observable repository facts ## Output Preferences - Lead with the answer, change, or finding rather than long preambles - Use structure only when it improves scanability - Keep explanations short by default and expand only when the task needs it - Make tradeoffs explicit when recommending one path over another - Distinguish clearly between confirmed facts, inference, and open questions ## Code And Review Guidance - Prefer concrete code-level reasoning over abstract best-practice language - When reviewing, prioritize correctness, regression risk, missing validation, and unclear behavior - When proposing edits, explain the implementation path in terms of actual files, flows, or contracts - Do not suggest broad cleanup unless it materially improves the requested outcome ## Validation - Run the smallest useful validation for the changed area - Report what was validated and what remains unverified - Surface risks, assumptions, and follow-up work clearly - Match validation depth to the risk of the change rather than applying a fixed checklist ## Keep In Sync When AGENTS.md and GEMINI.md overlap: - Put shared repository rules in AGENTS.md - Put Gemini-runtime-specific differences here - Remove duplication when it stops being useful - Update both when the workflow meaningfully changes

• Start from the repository's real workflows, risks, and constraints before drafting instructions.
• Keep shared guidance aligned with AGENTS.md unless Gemini-specific behavior requires a difference.
• Add Gemini-specific notes only where they improve real execution.
• Optimize for concise, high-signal runtime guidance instead of duplicative docs.
• Make the file useful for Gemini CLI work in this repo, not for generic AI advice.

Markdown