You lint your code. You run tests. You check for security vulnerabilities.
But what about your documentation?
Most teams treat docs as second-class citizens in CI/CD. Code gets automated quality gates; docs get... a human reading them whenever they have time.
Here's how to change that.
The Problem: Documentation Review is a Bottleneck
Every docs PR in our repo sat waiting for review. Someone had to manually check:
- Are headings capitalized correctly?
- Did the author use our terminology ("click" not "select")?
- Are all the links still valid?
- Is the structure consistent with other pages?
This was tedious for reviewers and slow for contributors. Engineers would submit docs, wait days for feedback, then get a list of nitpicky style fixes.
We decided to automate the mechanical stuff.
What We Automated
| Check | Before | After |
|---|---|---|
| Style guide compliance | Manual review | Automated |
| Broken links | Occasional spot checks | Every PR |
| Terminology consistency | "I think we use X?" | Enforced |
| Heading format | Manual review | Automated |
| Quality metrics | None | Per-file scores |
The Setup: GitHub Actions + EkLine
We use EkLine for automated docs review. Here's our workflow:
name: Documentation Review
on:
pull_request:
paths:
- 'docs/**'
- '*.md'
jobs:
docs-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: EkLine Docs Review
uses: ekline-io/ekline-github-action@v6
with:
content_dir: ./docs
ek_token: ${{ secrets.EKLINE_TOKEN }}
github_token: ${{ secrets.GITHUB_TOKEN }}
reporter: github-pr-review
That's it. When someone opens a PR that touches documentation, EkLine:
- Analyzes the changed files against our style guide
- Checks all links
- Validates terminology
- Leaves inline comments directly on the PR
What the Feedback Looks Like
Instead of a wall of linter output in CI logs, contributors get comments exactly where issues are:
The feedback is actionable: "Define 'MCP', if it's unfamiliar to the audience." with a suggestion to fix it.
Configuring Your Style Rules
EkLine comes with presets (Google, Microsoft), but you can customize:
# .ekline/config.yaml
rules:
headings:
capitalization: sentence-case
voice:
prefer: active
terminology:
banned:
- utilize # use "use"
- leverage # use "use"
- click # use "select"
required:
- API # not "api" or "Api"
Results After 3 Months
| Metric | Before | After |
|---|---|---|
| Avg. review cycles per docs PR | 2.4 | 1.4 |
| Time to first feedback | 1-3 days | Instant |
| Style-related review comments | ~60% | ~10% |
| Broken links shipped | Monthly | Rare |
The biggest win wasn't efficiency—it was contributor confidence. Engineers now get instant feedback, fix issues themselves, and submit cleaner PRs. They're not waiting days just to learn they used the wrong heading style.
Bonus: Automating the "What Needs Updating?" Problem
Automated review catches issues in what you submit. But there's a harder problem: knowing what should be submitted after a product change.
EkLine also has a Docs Agent that addresses this. You can prompt it:
"The user invitation flow changed from 2 steps to 3 steps"
And it will:
- Scan your docs repo for all files mentioning invitations
- Draft updated content
- Create a PR with the changes
This shifts documentation maintenance from "hope someone remembers" to "tell the agent what changed." We're still rolling this out, but early results show it dramatically reduces docs drift.
Alternatives to Consider
If EkLine doesn't fit your needs:
- Vale — The underlying linter many tools use. More DIY, but very flexible.
- alex — Focused on inclusive language checking.
- markdownlint — Basic Markdown formatting rules.
The difference with EkLine is the GitHub integration (inline PR comments) and managed style guide configs. If you want to build your own setup, Vale is excellent.
Should You Automate Docs Review?
Yes, if:
- Multiple people contribute to documentation
- You have (or want) a style guide
- Review cycles are slowing down releases
- You're already using docs-as-code
Maybe not, if:
- Solo writer on a small project
- Docs are in Confluence/Notion (no Git integration)
- Your review process works fine
Getting Started
- Sign up at ekline.io — free for public repos, 30-day trial on Standard ($50/user/month)
- Add the GitHub Action to your repo
- Open a PR with docs changes
- See the automated review
Full setup guide: docs.ekline.io
What's in Your Docs CI?
I'm curious what other teams are doing for documentation quality. Are you:
- Running any automated checks?
- Using different tools?
- Still doing everything manually?
Drop a comment—I'd love to learn from your setup.
Bipin works on documentation tooling at EkLine. He's interested in how teams scale documentation quality without scaling review burden.

Top comments (0)