feat(ci): orchestrate automatic and interactive Claude reviews

[sfreudenthaler]

Summary

• rename workflow to ai_claude-orchestrator.yml to reflect multi-trigger orchestration
• add pull_request triggers (opened, synchronize) for automatic Claude reviews
• add claude-automatic-review job using trigger_mode automatic
• skip automatic runs when PR title/body already contains @claude to avoid double-triggering (but we have concurrently control anyways)
• set direct prompt to a senior/staff review style (no praise, flag risk/issues, one-line clean verdict)

Non-functional considerations

• to make sure that a bad actor can't FDoS us by opening a slew of PRs on junk to devour our tokens runs we are gated by public org membership (downside is that it must be set by our devs manually). Should that fail or be removed...
  • limits set on the anthropic side
  • we have reporting and telemetry by key
  • the key isn't hard-coded to protect against forks and such

Validation

• reviewed workflow YAML diff locally

Closes #34809

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1cd8b89b4e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[wezell]

Let's see this work

[sfreudenthaler]

Let's see this work

just needs someone from core workflow devs group. I should actually just widen that net or just make it any two ppl

[spbolton]

@sfreudenthaler Note that due to our current security model on the Repo generally external users cannot spam us with PRs. The primary reason for this is we only allow any interaction to the repo by "collaborators" so anyone needing write access to the repository needs to be approved including creating PRs. https://github.com/dotCMS/core/settings/interaction_limits.

Interestingly there is a new configuration option just added that would not have impact with our current restriction, you you can now separately prevent access to creating PRs but allow access to the repo otherwise. This could mean you can allow access for external users to create issues, but not PRs. https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/

[spbolton]

Generally fine. Just a couple of points.

1. Without cancel-in-progress as true if there are changes pushed to the PR in quick succession then each will independently run in parallel to completion and create their own reviews, whereas the last commit pushed should be able to cover the current state of the code. With this set to false we just use more tokens.

2. Do we want even draft PRs to trigger review or only when it is made non-draft.

3. I am not sure if the allowed_tools is too restrictive and it may not allow claude to read files, check history or undersand context. git diff provides the full diff but

[sfreudenthaler]

Generally fine. Just a couple of points.

1. Without cancel-in-progress as true if there are changes pushed to the PR in quick succession then each will independently run in parallel to completion and create their own reviews, whereas the last commit pushed should be able to cover the current state of the code. With this set to false we just use more tokens.

Let me double check. I thought the orchestrator in ai-workflows handled this but I might have mistaken.

2. Do we want even draft PRs to trigger review or only when it is made non-draft.

Yes :) early feedback for devs is worth the offset in token waste

3. I am not sure if the allowed_tools is too restrictive and it may not allow claude to read files, check history or undersand context. git diff provides the full diff but

Probably but lets see

[sfreudenthaler]

ready for review again @spbolton