Your Agent's Configuration Deserves a Code Review
Project instructions can change an agent’s behavior without changing application code. Review the instructions and the access they enable.

One of my repositories has an agent instruction that says an article revision can't be called delivered until its repository copy and Guardian review match and a verification record exists. Remove that requirement, and the application still builds. The next agent can also hand back a local file as “delivered” while the copy I review remains old.
That file can change what the coding agent does without changing any application code.
CLAUDE.md and AGENTS.md are examples of project instruction files. Agent skills can add instructions and scripts for particular jobs. Changes to those files deserve the same question I ask of application code: what behavior changes after this merge?
In this repository, the instructions require the repository copy, Guardian review, and verification record to match before anyone calls an article delivered. Remove that line and the next agent can return unchecked or stale work.
I'd compare the instruction file with the last reviewed commit before starting an agent in that checkout. Reviewing the generated code afterward may catch one bad result. It leaves the instruction in place for the next run.
If the instruction points to another file, I read that file too. Approving the pointer while leaving the loaded instructions unread isn't a complete review. Tool and filesystem permissions belong in the same pass because they change what the agent can do, not merely how it describes the work.
Pillar Security disclosed the Rules File Backdoor, in which project rule files could influence coding agents to produce harmful changes. I treat these files as part of the execution path. A file comparison still won't catch every hidden influence, and an instruction change isn't automatically malicious.
In my experience, the instruction diff matters as much as the code diff. I want a reviewer to say which agents will read it and what changes when they do. If it adds access or skips a check, that needs to be called out directly.
If a team can't establish those answers, the change can wait. If we can't explain the change, I hold it.
A security scanner helps only where it covers these files and the behavior they enable. A code scan won't tell me whether the instruction is appropriate. I read the instruction and the access it adds before the next run.
That review happens before the next coding agent reads the file and starts changing code.
Sources: project memory files in Claude Code; Pillar Security's Rules File Backdoor disclosure.