Projects

Rules and knowledge

Standing instructions Panda follows in every chat, and the documents it should know about.

A rule from your folder can be switched off per project

It stays in your rules folder and in every other project. Switching it off here only stops this project using it.

Where rules live

A project has one Rules list, on its overview. Panda follows everything in it, in every chat in that project, without being reminded.

A rule is a file. Write one directly, or tell Panda to write it and it will.

Rules you keep in your own rules folder (~/.claude/rules) are copied into every project automatically and show up in the same list, prefixed user-. That is the only sense in which a rule is "yours" rather than the project's: there is no separate personal list to manage. One of those copied rules can be switched off for a single project without touching the original.

Write one that works

A rule that names a behaviour beats one that names a virtue, and a reason makes it stick.

Weak: "Be careful with the database."
Strong: "Always add a WHERE clause to UPDATE and DELETE. Our production database has no undo."

Rules apply from your next message, so you can correct Panda mid-chat and watch it take.

Knowledge

Knowledge files are the documents around the code: specs, architecture notes, domain material. Rules say how to work, knowledge says what the work is about.

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.

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.

Rule Priority

When multiple rules exist, they're all included. There's no override mechanism, all rules are additive. If rules conflict, the most specific (project-level) rules should take precedence in practice, but it's best to avoid contradictions.

PandaOS-Managed Sections

PandaOS may inject managed sections into your project's CLAUDE.md file (e.g., Browser MCP tool instructions). These sections are marked with special comments and are automatically maintained, don't edit them manually.

<!-- PANDAOS:START -->
... managed content ...
<!-- PANDAOS:END -->

How Panda uses knowledge

When you chat in a project that has knowledge attached, Panda draws on those documents to give more informed answers. If your knowledge includes an API spec, Panda can generate code that matches the real endpoints. If it includes an architecture decision record, Panda understands why the system is structured a certain way and avoids suggestions that violate those decisions.

Knowledge is scoped to the project. When you switch projects, Panda's context switches with it, so knowledge from one project never bleeds into another.

Knowledge vs. rules

This distinction matters because the two serve fundamentally different purposes:

Rules are instructions. They tell Panda what to do and what not to do. "Always use snake_case in Python files." "Never commit directly to main."
Knowledge is context. It gives Panda information to reason with. "Here is our API specification." "Here is the architecture decision record for our auth system."

Think of rules as the guardrails and knowledge as the map. Rules constrain behavior; knowledge informs decisions. A well-configured project uses both: rules to enforce conventions, and knowledge to provide the context Panda needs to make good choices within those conventions.