Reusable Claude review workflow #8
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is to centralise the automated workflow definition, so we don't have to keep it up to date everywhere. The definition can either be static, or better, it can refer to guidelines in the individual repos.
This needs to be suplied by the caller, since it's not (at present at least) a secret at the org level.
This doesn't seem to be needed elsewhere, but the machine complains about it in its logs. (Although not fatally. Not fatally?)
squaremo
commented
Feb 5, 2026
| secrets: | ||
| CLAUDE_CODE_OAUTH_TOKEN: | ||
| description: A Claude Code access token. Supply this **or** ANTHROPIC_API_KEY. | ||
| ANTHROPIC_API_KEY: |
Contributor
Author
There was a problem hiding this comment.
I used one of these (as created in the Anthropic console), but I note that our repos have a CLAUDE_CODE_OAUTH_TOKEN (I don't know how to get one of those) -- they are not interchangeable, so I've made it possible to supply either.
squaremo
commented
Feb 5, 2026
| claude-review: | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| actions: read |
Contributor
Author
There was a problem hiding this comment.
In my trial (https://github.com/nscaledev/uni-shared-workflow-tester/actions/runs/21717714519/job/62638312318#step:3:399) it complained when it didn't have this, but we don't seem to have this permission anywhere else.
This is an attempt to use a shared CLAUDE.md by refering to it in the review prompt. I've put a subtle instruction in there so I can tell if it's working.
Break the context down into files in rules/, which I hope will work in sympathy with the Claude memory: https://code.claude.com/docs/en/memory#modular-rules-with-claude/rules/ I have put explicit pointers in CLAUDE.md to the individual files. I don't think can hurt, and it might help if we're referring to the CLAUDE.md from elsewhere.
squaremo
force-pushed
the
reusable-review-workflow
branch
from
eb90e3d to
e49eeac
Compare
Contributor
Author
|
I've been using a PR in https://github.com/nscaledev/uni-shared-workflow-tester, which calls the workflow here, to experiment. Some results (most recent to least):
|
Referring to the centralised guidelines via a github raw URL kind of worked, but much less well once I broke the rules down into separate files. The decision to fetch a particular file is down to the agent to reason about -- i.e., it's running through at least one layer of natural language interpretation -- and sometimes it appears to not be fussed. THis is another way of doing it: check out the centralised repo alongside the repo under consideration, and give Claude the magic env and argument to make it look there for rules. I think since this is directly supported by Claude, it'll work more reliably.
them. Fair enough. So this commit tries putting the repo alongside, by
giving the repo under review a path too, per the example given in
https://github.com/actions/checkout?tab=readme-ov-file#checkout-multiple-repos-side-by-side
Giving a path for the repo-under-review works OK for checkout, but then the claude action fails because it doesn't know where to look. I do not see an example of doing this anywhere, but my guess is I need to reset `GITHUB_WORKSPACE` to the subdirectory. I used the context value `github.workspace` rather than the env entry, because I think (perhaps superstitiously) that it needs to be evaluated in interpretation, not by the shell or container runner.
I don't know how to get GHA to clone the "main" repo, then to run further commands in that repo. So: put the secondary repo under .github/, in the hope that it at least keeps it out of the way for other actions.
The mention of .claude/CLAUDE.md works well if that's where the file is; but now I'm putting it the centralised guidelines in .github/uni, it doesn't find them (or it didn't find them the one time I tried it so far). This commit uses the wording "project memory" in the hope that it triggers claude to look in its memory search path. (Maybe I don't need to mention it at all?)
Claude uses glob to find CLAUDE.md, but if it's under a dotted directory this won't yield any results. Thus, my attempt here to put it somewhere it's more likely to notice, under .claude.
To see if it has any influence, I've added a rule for documentation. But it's honestly difficult to tell what makes a difference here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This takes the Claude workflow definition as it is in nscaledev/uni-region#381, tweaks it a little to make it more robust when files aren't present, and puts it in a
workflow_calltrigger.This means you can call it from another repo, and it'll act locally; and that means we can have centralised prompts (as below), but local guidelines (as in CLAUDE.md), which makes it much easier to evolve our reviews.
Fixes INST-545.