Getting Started
What is Workover?
Workover is the AI-native document editor for teams that publish product documentation, internal wikis, marketing content, and everything in between. Before you dive in, a few things you should know:
We have a long road ahead of us and a lot more that we plan to build (both for ourselves and the companies we work with), but we’d much rather ship it with you now than spend another three years building it in private.
If something you need is missing, tell us.
We’re here and always happy to help.
Your workspace is the source of truth for your content.
It holds projects, usually one per website, and each project holds the documents destined for that site along with the connection Workover uses to reach it. See core concepts.
The editor is where the work happens. Several people can write in the same document at once, with threaded comments, version history, and AI suggestions all in the same place. A document can be split into tabs, and one tab is the one that syncs to your site.
Your site stays where it is. Workover connects to your existing WordPress site through the WordPress REST API using credentials you provide, and you can disconnect at any time without affecting what is already published.
Browser editor ──┐
├──▶ Document ◀── publish / pull ──▶ Your WordPress site
Claude Code ─────┘ │
(CLI and MCP) ▼
Monitor watches
Editing content
There are two ways to work on a document, and you can use both on the same document.
- In the browser: real-time editing with live cursors, threaded comments, and version history with names attached, so you can see what changed and roll back.
- From an agent: point Claude Code or another agent at Workover through the CLI and MCP server. It can search your documents, read them, and propose changes.
Anything an agent proposes arrives as a suggestion for a person to accept or reject. Agents cannot publish. That stays with someone signed in through the browser.
AI features
Built-in AI features draft your content and help you keep it current. Everything they produce is reviewable before it lands.
Drafting writes a first draft from a brief. What makes it useful is not the model but what it is allowed to see: your style guide at workspace and project level, the rest of your documentation, and optionally a GitHub repository, read-only, so a technical page describes how your product actually works. Repository code is read directly from GitHub by the model provider and is never copied onto or stored by Workover’s servers.
The screenshots are captured from your live product wherever a draft calls for one, and placed inline. See screenshots in drafts.
The suggestions are how every AI edit arrives. You get a proposal, not a result: accept or reject each change, one at a time or all at once.
The support signals turn the questions your team keeps answering into the documents you have not written yet. Connect Plain, Help Scout or Freshdesk, read-only.
Publishing and sync
Connect a WordPress site to a project, and a finished document becomes a real post or page, with the slug, categories, excerpt, featured image, and SEO fields you set in Workover.
Sync runs both ways. On connection, your existing posts come into Workover as documents, and changes made on the WordPress side can be pulled back, so the two do not quietly drift apart. Custom blocks and ACF fields survive the round trip untouched.
Monitoring
Once a page is published, Monitor crawls it on a schedule and compares each crawl against the last: titles, meta descriptions, canonicals, robots directives, sitemaps, structured data, internal links, and TLS certificate expiry, among many, many others (a list that is constantly growing).
It answers what changed and whether it matters, rather than what a page looks like, so you hear about a broken link from us rather than from a customer.
Next steps
Quickstart: your first document: connect a site, write a document, and publish it, end to end.
Related topics
Still need help?
Can’t find what you’re looking for? Our team is here to help.