Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

It makes sense to me that [ci skip] should skip RTD so +1 from me

Agreed. I think perhaps we will want more fine-grained control (only skip docs, or only run docs), but it seems to me that can always be added later.

fine-grained control

Yes, I think it is all possible now with their automation rules.

can always be added later

I'd rather we just decide now because I have to go to RTD admin settings and also update the docs here. It will be confusing if we keep changing the rules.

I would prefer a separate [skip ci] and [skip docs].

It's common that someone comments on a PR and asks for just a few changes in the doc string as last comment after the code is good so the last commit only needs to run the docs. We also have PRs that only update the docs. Again, I just want to skip CI, but build docs.

Since [skip ci] is our established way of skipping just the CI (that's what it does right now, even if that's not by choice but due to RTDs inability to hook into it in the past), I suggest that it's the easiest to add a new and separate [skip docs].

I think it's more useful to control docs and code CI separately, even at the cost of sometimes having to type both of them.

I'd be a little bit happier with separate CI and docs skip options too. The only real cost would seem to be for a commit/PR that only touches comments or so.

They just published a blog about this feature. Do you want to give these links a read and see if any of the many ways we can configure is what you want? They allow filter by files changed too, though I am not sure how to tweak that in a fool-proof way, especially it is something done on admin side.

• https://about.readthedocs.com/blog/2026/06/automation-rules-v2/
• https://docs.readthedocs.com/platform/stable/automation-rules.html#examples

I indeed do not see how we can filter on files, since the docstrings also matter. But it does seem not running on [skip docs] is possible, so maybe just start with that?

OK choices, choices... which one? 😸

1. [skip docs] and [docs skip]
2. [skip doc] and [doc skip]
3. [skip rtd] and [rtd skip]

I'm in favour of 1, since our directory is called docs too, but no strong opinion.