Rules
Rules are persistent instructions that shape how Panda works. They layer personal preferences over project conventions to create consistent, predictable behavior.
What rules are
Rules are persistent instructions that Panda follows in every conversation within their scope. Unlike a one-off prompt where you say "use TypeScript strict mode," a rule makes that instruction permanent. You write it once, and Panda applies it to every future message without being reminded.
Rules are the primary way to shape Panda's behavior. They can encode coding conventions ("use functional components, not class components"), safety constraints ("never delete production data without confirmation"), working style preferences ("explain your reasoning before making changes"), or anything else you want Panda to consistently respect.
Personal rules
Personal rules follow you across every project. They capture how you like to work regardless of the codebase. Examples:
- "Always explain your approach before making large changes."
- "Prefer small, reviewable edits over sweeping rewrites."
- "When unsure, ask before proceeding."
These are the right place for preferences about tone, caution level, and working style. They reflect you as a developer, not the project you happen to be in.
Project rules
Project rules are scoped to a single project and travel with it. When a teammate opens the same repository, they inherit the same guidance. This is how you encode project-specific knowledge:
- "All API routes must validate input with Zod schemas."
- "Use the Result pattern for error handling, never throw."
- "This project uses Tailwind CSS. Do not add inline styles."
Project rules eliminate the need to re-explain conventions in every conversation. They act as a living style guide that Panda enforces automatically.
How rules layer together
Inside a project, Panda sees both your personal rules and the project's rules merged together. Personal rules provide the baseline; project rules add specifics. When they conflict, project rules take precedence because they represent the team's conventions for that codebase.
Each personal rule has a per-project toggle, so you can disable any individual personal rule for a project where it does not fit, without deleting it everywhere else. For example, your personal rule "prefer verbose variable names" might not make sense in a project with an established terse naming convention. Toggle it off for that project; it stays active everywhere else.
Writing effective rules
The best rules are specific and actionable. Vague rules like "write good code" give Panda nothing to work with. Strong rules state a concrete behavior and, ideally, explain why:
- Weak: "Be careful with the database."
- Strong: "Always add a WHERE clause to UPDATE and DELETE statements. Our production database has no undo."
Rules take effect on your next message, so you can adjust Panda's behavior mid-session. If Panda does something you dislike, turn that correction into a rule so it never happens again.