I agree with your take that there's no explicit need to create GITHUB_TOKEN. But creating a PAT grants freedom on the scope.
I'll approve this PR if you will add a link to the documentation on the restricted scope-flexibility of GITHUB_TOKEN and consequently recommend using a PAT for additional flexibility.

Could you go into more detail on how a PAT allows to limit the scope further? GITHUB_TOKEN is scoped to the current repo and can be further limited through

    permissions:
      contents: write

A PAT cannot be scoped to a single repo. The thing I don't fully understand is how the public_repo OAuth scope compares to the contents: write scope of GITHUB_TOKEN.

Could you go into more detail on how a PAT allows to limit the scope further?

I think you misread my comment. I was referring to the limited scope of the auto-generated GITHUB_TOKEN w.r.t to a PAT currently recommended by the live Jekyll Documentation..

Anyways, the GitHub docs on the relevant info are at:

• about GiTHUB_TOKEN
• granting additional permissions via PAT

Could you go into more detail on how a PAT allows to limit the scope further?

I think you misread my comment. I was referring to the limited scope of the auto-generated GITHUB_TOKEN w.r.t to a PAT currently recommended by the live Jekyll Documentation..

I was caught up by "consequently recommend using a PAT for additional flexibility". I can't think of any scenario where it makes sense to recommend using a PAT for github pages.

I can't think of any scenario where it makes sense to recommend using a PAT for github pages.

Fair enough.
I'll merge when the CI run finishes.
Thanks @letmaik

@jekyllbot: merge +doc