specgit guides
Docs as code, without asking PMs to learn Git
Engineering teams adopted docs as code because it works: docs live in the repo, change through review, and stay current with the product. The only thing stopping product teams from joining is the tooling — Git, Markdown, and pull request mechanics. specgit removes exactly that barrier.
What docs-as-code means for product
The repo is where product truth lives — the code, the reviews, and increasingly the AI agents that write code all work there. Docs as code puts the documents that shape the product's future in the same place as the code that defines its present: specs are plain Markdown files in the repository, every change has an author and a timestamp, and review happens in the open instead of in a comment thread nobody revisits.
Why Notion and Google Docs break the loop
A spec in Notion or Docs starts drifting the moment engineering picks up the work. Engineers read it once, build from the ticket, and never come back; changes made during implementation never flow into the doc; and six months later the spec describes a product that no longer exists. The doc app has its own permissions, its own search, and its own graveyard of stale pages — all disconnected from where the product is actually decided. On the blog: why specs go stale and a fair Notion vs GitHub comparison.
Shared-drive UX on the repo
specgit makes a GitHub repository feel like a shared drive. You browse files, open a doc, and write in a visual editor — formatting toolbar, inline comments, live co-editing with teammates. Behind the scenes, every save is a commit and drafts are real branches, but nobody on the product side has to know or care. Import existing Word, PowerPoint, Excel, or PDF files and they're converted to clean Markdown in your repo.
Review like a pull request
When a draft is ready, teammates review it the way engineers review code. Inline comments are pull request threads; approvals count toward branch protection and required-review rules; and publishing merges the doc to your base branch. specgit shows exactly what's blocking a publish and can publish automatically the moment required approvals land — so reviews finish instead of stalling.
AI agents read the same files
AI coding agents work in the repository — that's where they look for context. A spec that lives next to the code is context they use automatically; a spec in a separate app is invisible. Keeping docs in the repo means engineers and their agents build from the current spec, not a stale copy. specgit also includes an optional AI co-editor, specgit AI, that works on those same files — every proposed change requires your approval.
Getting started
Sign in with GitHub through the specgit GitHub App — fine-grained, repo-by-repo permissions you approve on GitHub, no separate password. Open any Markdown or HTML doc already in your repository, or create a new one from a starter template (product spec, decision record, meeting notes, and more). The Free plan needs no credit card, and there's an interactive demo on the homepage if you want to see the editor first.
Bring your product team into the repo
Write specs where engineers and AI agents already work — no Git, no Markdown syntax, no new permissions silo.
Free to start, no credit card. Your docs never leave GitHub.
By continuing, you agree to the Terms of Use and Privacy Policy.
Frequently asked questions
What is docs as code?
Docs as code means treating documentation like source code: docs are plain-text files (usually Markdown) stored in a version-controlled repository, changed through the same review workflow as code. The payoff is docs that live next to what they describe, with real history, real review, and no separate permissions silo.
Doesn't docs as code require learning Git?
Traditionally, yes — and that's why it rarely sticks for product teams. specgit removes that requirement: PMs write in a visual editor in the browser, and specgit handles the commits, branches, and pull requests behind the scenes. Nobody has to clone a repo, learn Markdown syntax, or open GitHub.
How do engineers review a spec written in specgit?
As a pull request — the exact flow they already use for code. Publishing a draft opens a review; inline comments in specgit are PR review threads; approvals, branch protection, and required reviews all work end to end. Engineers can review from GitHub or from specgit, whichever they prefer.
What do AI coding agents get out of this?
Repo-based agents (and engineers' editors) read the files in the repository. When your specs are Markdown files next to the code, agents pick them up as context automatically — no integrations, no copy-paste. A spec in a separate docs app is invisible to them.
What does it cost to try?
Nothing. The Free plan covers unlimited collaborators on 1 repository with 5 publishes per month, no credit card required. Sign in with GitHub through the specgit GitHub App and grant only the repositories you choose.