Understand docs-as-code

Promptless keeps your documentation current by opening pull requests against the repository that holds your content. That model works when your docs live in a repository as files a pull request can change — the approach known as docs-as-code. If your team is still on a hosted platform that stores content in a proprietary database or WYSIWYG editor, moving to docs-as-code is the first step to adopting Promptless.

Docs-as-code is a hard prerequisite, not a preference. Promptless publishes by committing changes to a Git repository and opening a documentation PR. A platform Promptless can’t reach through a Git repository can’t receive suggestions.

What docs-as-code means

Docs-as-code treats documentation the same way engineering teams treat source code:

• Content lives in a Git repository as source files instead of inside a proprietary CMS. Those files are often Markdown or MDX, but they can just as easily be DITA, reStructuredText, a MadCap Flare project, or another authoring format — what matters is that the source lives in Git.
• Changes go through pull requests, so every edit is reviewable, diffable, and revertable with the same tools your engineers already use.
• A static site generator builds the published site from those files, so the repository is the source of truth and the live site is a build artifact.

Because the content is versioned files rather than database rows, an automated collaborator like Promptless proposes an edit the same way a teammate would: branch, change the files, and open a PR you review before it ships.

Why Promptless requires it

Promptless integrates into your existing workflow rather than replacing it. When a trigger fires — a merged code PR, a Slack thread, a support ticket — Promptless drafts the documentation change, commits it to a branch in your docs repository, and opens a pull request with citations back to the sources that informed it. You review and merge that PR like any other.

Every part of that loop depends on the docs being versioned files in a Git repository:

• Promptless reads the current content to understand your product, voice, and structure.
• It writes changes as a branch and a reviewable diff.
• Your platform rebuilds the published site from the merged files.

Hosted editors that keep content in a proprietary store don’t expose the docs as files a PR can change, so there’s nothing for Promptless to branch from or commit to.

What “supported” looks like

Once your documentation lives in a GitHub repository, Promptless publishes to any docs-as-code platform that builds from that source. What matters is a Git-backed source, not a particular tool or file format: Promptless works with Markdown and MDX, and also with DITA, reStructuredText, MadCap Flare, and FrameMaker (through a MIP intermediary). Some platforms aren’t natively Git-based but sync or mirror their content to GitHub, and those setups are fully supported too — Promptless only needs to reach the source through a repository it can branch from. See the supported platforms list for the tools teams most often run on Promptless.

Tip

If you’re already on a Git-backed static site generator, you can skip the migration entirely — head to Doc locations & collections to connect your repository, then set up your triggers. This section is for teams still on a hosted platform that need to move first. Open-source maintainers can start from the open-source quickstart, which covers the free program.

Where to go next

If you’ve confirmed docs-as-code is the move, the rest of this section walks the migration end to end:

• Choose a platform — pick a supported static site generator that fits your team.
• Migrate to a new docs platform — move content off Doc360, ReadMe, Fern, HubSpot, or RoboHelp.
• Preserve URLs and redirects — keep existing links working after the move.