ci: use docker/cagent-action/.github/workflows/review-pr.yml

[dvdksn]

• needs: actually pass prompt-files through to the root action cagent-action#36
• closes docker/gordon#118

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	44692cc
🔍 Latest deploy log	https://app.netlify.com/projects/docsdocker/deploys/6990ac088ba7a70008341792
😎 Deploy Preview	https://deploy-preview-24132--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

Review Summary

Workflow refactoring looks good! ✅

This PR successfully migrates from an inline agent configuration to using the reusable workflow from docker/cagent-action. The configuration is clear and well-structured with no documentation quality issues found.

The additional-prompt parameter appropriately configures the review agent with clear instructions and guidelines. The content is technically accurate and suitable for its purpose as agent configuration.

[derekmisler]

the only reason i haven't approved this yet is because we need this one to land first, or the prompt files will be ignored

[thaJeztah]

@dvdksn could we make it aware of pages being removed, and for those to check if a correct redirect is added? i.e., to prevent things like #23949 (comment)

[thaJeztah]

I think we were also looking at (or already have?) helping with triage; for 404 reports, it could also check wayback-machine to verify if it was a page that previously existed to exclude reports for made-up links 🤔 (if I'm not sure, I usually do a quick check to see if there was anything at that URL in the first place #23949 (comment))

[dvdksn]

@thaJeztah yes that would be a good addition. Let me update the instruction 👍

[dvdksn]

@thaJeztah for 404 - yes, for the triage agent (todo) we could probably just add a tool to check the wayback api, eg: https://archive.org/wayback/available?url=docs.docker.com/engine/reference/builder

[usha-mandya]

LGTM

[thaJeztah]

Silly question; I see secrets: inherit what permissions does that grant, and are all permissions needed for this workflow?

[thaJeztah]

Oh; nevermind; GitHub hid those lines, but I'm guessing it's these;

permissions:
  contents: read
  pull-requests: write
  issues: write

(Was mostly concerned it could inherit write access on content 😅)

[thaJeztah]

Still wondering; would it be good to set the top-level defaults to not be permissive, and explicitly set more permissions here? I recall that's what we do in most places; e.g. https://github.com/moby/moby/blob/3068dc540f79ea43d312918857d1465f25ad128f/.github/workflows/ci.yml#L3-L10

# Default to 'contents: read', which grants actions to read commits.
#
# If any permission is set, any permission not included in the list is
# implicitly set to "none".
#
# see https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
permissions:
  contents: read

And then in steps that must have more permissions, we set it locally;
https://github.com/moby/moby/blob/3068dc540f79ea43d312918857d1465f25ad128f/.github/workflows/ci.yml#L130-L138

  govulncheck:
    runs-on: ubuntu-24.04
    timeout-minutes: 120 # guardrails timeout for the whole job
    # Always run security checks, even with 'ci/validate-only' label
    permissions:
      # required to write sarif report
      security-events: write
      # required to check out the repository
      contents: read