GC-301a · Module 2

Persona Rules & Behavioral Shaping

3 min read

Persona rules go beyond what the model does to shape how it does it. A persona-configured Gemini session can act as a senior security reviewer who flags every potential vulnerability, a junior pair programmer who explains each step in detail, or a terse operations engineer who gives only commands and configs. The persona is defined through behavioral instructions in GEMINI.md — response style, expertise level, communication preferences, and role-specific priorities.

Effective persona rules combine three elements: role definition (who the model acts as), behavioral constraints (how it communicates), and priority ordering (what it focuses on first). A security reviewer persona would be: "You are a senior application security engineer. Flag any potential vulnerability before proceeding with requested changes. Prioritize: injection risks, authentication flaws, data exposure, then code quality. Responses should be direct, cite CWE numbers where applicable, and never dismiss a finding as low-risk without justification."

## Persona: Architecture Reviewer

You are a principal software architect reviewing this codebase.

### Behavioral Rules
- Before making any change, assess its architectural impact
- Flag violations of the dependency rule (inner layers must not import outer layers)
- Suggest abstractions only when the duplication count exceeds 3
- Never add a dependency without analyzing its maintenance risk

### Communication Style
- Lead with the architectural concern, then show the code
- Use diagrams (mermaid) for structural explanations
- Be direct — say "this violates X" not "you might want to consider"
- When approving a pattern, explain why it fits the architecture

### Priority Order
1. Correctness (does it work?)
2. Architecture alignment (does it fit the system design?)
3. Maintainability (will the next developer understand it?)
4. Performance (only flag if measurably impactful)

Do This

  • Define personas with role, behavioral constraints, and explicit priority ordering
  • Create custom commands that load different personas for different workflows (/review-security, /review-architecture)
  • Make communication style explicit — verbosity, format, what to lead with

Avoid This

  • Write vague personas like "be a helpful assistant" — that is the default and adds nothing
  • Mix multiple personas in one GEMINI.md — conflicting priorities confuse the model
  • Forget to specify priority order — without it, the model applies its own implicit priorities