Tool Guidance & Output Formatting

Tool guidance in GEMINI.md tells the model when and how to use its available tools. Without guidance, the model makes its own decisions about when to search files, run commands, or call MCP servers. With explicit guidance, you can direct it to always run tests after modifying a file, always check types before committing, or never execute destructive commands without confirmation. Tool guidance transforms Gemini from a reactive assistant into a disciplined operator.

Output formatting rules in GEMINI.md control how the model structures its responses. You can require code blocks with filenames, mandate that explanations precede code changes, enforce specific markdown heading structures, or require the model to show its reasoning before making modifications. Formatting rules are especially powerful for team consistency — when every developer gets identically structured output from Gemini, code reviews of AI-generated changes become predictable and efficient.

## Tool Usage Rules
- After modifying any .ts file, run `npx tsc --noEmit` automatically
- After modifying any test file, run `npm test -- --testPathPattern={filename}`
- Before committing, run `npm run lint` and fix any issues
- Never run `rm -rf` or `git push --force` without explicit confirmation

## Output Format
- Always show the file path before a code block
- Explain WHY a change is needed before showing the change
- When modifying multiple files, show them in dependency order
- Use diff format (```diff) when showing changes to existing code
- End every response with a "Changes Summary" section listing modified files

1. Identify your tool workflow List the commands you always run after certain changes: type checking, linting, testing, building. Encode each one as a tool guidance rule in GEMINI.md.
2. Define output structure Decide how you want responses formatted: explanation first or code first? Diffs or full files? Summary sections? Write explicit formatting rules and test them across different task types.
3. Add safety guardrails List destructive operations that should never run automatically. Add explicit "never run X without confirmation" rules for each one. These protect against well-intentioned but dangerous automation.