What it is.
You add a YAML file under .github/workflows and it runs on the events you name, such as a push or a pull request. GitHub provides workflow templates, so the first one is a copy and an edit.
For content teams working in git or a headless CMS, this is where mechanical review belongs. Link checking, spell checking, a banned-phrase grep, and schema validation all run in seconds and never forget.
That leaves human review for the things a script cannot judge, which is the argument and the accuracy.
What you get.
- A workflow file that runs on the events you choose.
- Workflow templates, so the first one only needs editing.
- Automated checks on every change, with results visible on the pull request.
- Mechanical review handled before a person reads the draft.
- A free tier that covers public repositories.
How to set it up.
Confirm your content lives in a repository, since this only helps if it does.
Start from a workflow template instead of a blank file.
Create the file under .github/workflows and set the trigger to pull requests on your content paths.
Add a link checker first, because broken links are the most common and most mechanical problem.
Add a grep for your banned phrases, and have it fail the check instead of only warning.
Keep the run under a minute, since a slow check gets skipped by whoever is in a hurry.
Use cases
Check every content change
Run the workflow on the events you choose so nothing merges unchecked.
Catch a broken link in review
Fail the check before the page reaches production.
Start from a template
Edit a provided workflow file instead of writing the first one.
Best for
Docs and content in git
If content is already versioned, the review automation is free to add.
Enforcing a style guide
A banned-phrase check that blocks a merge holds better than a document nobody reads.
Catching broken links early
Checking on change is cheaper than crawling the site later.