Personally, this is what I use in claude code:

"Diff to master and review the changes. Branch designed to address <problem statement>. Write output to d:\claudeOut in typst (.typ) format."

It'll do the diffs and search both branch and master versions of files.

I prefer reading PDFs than markdown, but it'll default to markdown unprompted if you prefer.

I have almost all my workspaces configured with /add-dir to add d:/claudeOut and d:/claudeIn as general scratch folders for temporary in/out file permissions so it can read/write outside the context of the workspace for things like this.

You might get better results using a better crafted prompt (or code review skill?). In general I find claude code reviews are:

  - Overly fussy about null checking everything
  - Completely miss on whether the PR has properly distilled the problem down to its essence
  - Are good at catching spelling mistakes
  - Like to pretend they know if something is well architectured, but doesn't

So it's a bit of a mixed bag, I find it focuses on trivia but it's still useful as a first pass before letting your teammates have to catch that same trivia.

It will absolutely assume too much from naming, so it's kind of a good spot if it's making wrong kind of assumptions about how parts work, to think how to name things more clearly.

e.g. If you write a class called "AddingFactory", it'll go around assuming that's what it does, even if the core of it returns (a, b) -> a*b.

You have to then work hard to get it to properly examine the file and convince itself that it is actually a multiplier.

Obviously real-world examples are more subtle than that, but if you're finding yourself arguing with it, it's worth sometimes considering whether you should rename things.