For teams putting agents to work
Agent-grade documentation.
Your agent already knows your code. Write down the context it can't see, and it follows the steps.
Point docpack at the Markdown in your repo. People get a fast, searchable site. Your own agent (Claude Code, Claude.ai or any MCP client) reads the same pages, follows the steps and records how it went. docpack never calls an AI model of its own.
Free to start, no card. Your docs stay in your repo as Markdown.
Or try it locally first with the free CLI.
› Set up docpack documentation for this repository, then stop at a pull request for me to review. ⏺ Found 14 Markdown docs in docs/ ⏺ Adopted them in place · docpack check passes ⏺ Opened a pull request: Add a docpack #42 ⎿ 14 pages, all Draft Each one earns Up to date once someone runs it for real.
The full prompt is on your dashboard once the App is installed. Already have a docpack? It sets itself up.
Get started
Three steps to get your agents reading.
There's no SDK, no bot to host and no glue code to maintain. Install the app, point it at your docs, and paste one line into your agent.
Install the GitHub App
Pick the repos that hold your docs. They stay in those repos as plain Markdown that you review like any other change.
Your docs become a space
A repo that already has a docpack sets itself up. If you have no docs yet, take a starter pull request or give your coding agent a short prompt.
Connect Claude
One click creates a key for the space and shows the exact setup for Claude Code and Claude.ai. Tick Record runs and Claude also logs what happens when it follows a runbook. Any other MCP client uses the same URL and key.
claude mcp add --transport http docpack-ops https://docpack.dev/o/your-team/ops/mcp --header "Authorization: Bearer dpk_…"
How it works
Your procedures get sharper every time someone uses them.
Your agent can read your code. It can't read why the migration has to run before the deploy, or which flag quietly breaks the build. Write that down once, in the repo you already have. After that your agent follows the docs: it finds the page, checks its status, runs the steps and records what happened. docpack does none of the thinking. It serves the pages, keeps the record and works out each page's status.
- 01
Write it down
Plain Markdown in your repo, holding what the code can't show: the order things must happen in, the flag that breaks the build, what to check afterwards. New runbooks can be drafted from what actually ran in a session, and existing pages or Confluence and Notion exports come in as drafts.
- 02
Check the badge
Your agent finds the procedure and reads its status before acting on it. A page marked Do not use is refused outright.
- 03
Run the exact steps
It gets each command byte for byte, never a retyped paraphrase, and checks the expected output as it goes.
- 04
Log it, fix it
Your agent records the outcome on the page. If a step was wrong, it fixes the page in the same session, and the fix comes to you for review. The next run starts from the truth.
Drafting a runbook from a session and running one end to end use two agent skills that are in early access. Reading, searching, recording runs and suggesting fixes work today.
Nobody updated the deploy page after that run. The agent that used it recorded the result.
Why teams let it near production
Every answer arrives with how much to trust it.
The risk in pointing agents at your docs is an agent acting confidently on a page that went stale two quarters ago. So nobody types a status here. It's worked out from when the page was last reviewed and how its recent runs went, and it travels with every answer.
Status is earned
A procedure has to have been reviewed recently and have worked the last time it ran. Writing "verified" at the top of a page changes nothing.
Age counts against it
Commands that still work don't prove a page says what you meant. Time alone moves a page out of the trusted tier, and your agents can see that.
Failures surface at once
When something breaks, the page says so. It drops out of what agents treat as trusted and moves to the top of the fix list.
Maintenance
Nothing quietly rots.
When your code changes and a procedure doesn't, docpack notices and turns the gap into a short, ranked list. Your existing agents can work through it and send changes back as pull requests your team reviews.
The list is empty only when the documentation is accurate.
One workspace
The same page, for everyone who needs it.
Operational knowledge usually ends up in three places: a wiki people edit, context files agents scrape, and somebody's terminal history. docpack keeps one source and gives each audience a way in.
Your agents
Point Claude, or whatever agent you already run, at a space. It finds the right procedure, gets the exact steps, and knows how far to trust the page before acting on it.
Your coworkers
The people who know the process often don't use git. They edit in the browser, and the change comes in as a pull request your team reviews.
Your engineers
It's Markdown in your repo, reviewed in your pull requests and checked in your CI. There's nothing new to learn, and your content stays portable.
The difference
Search is table stakes. Trust is what matters.
Most documentation tools now let an AI read your docs, and plenty do it for free. The better question is whether the page deserved to be read, and whether anything changed because it was.
| What you get | Markdown + an MCP server | docpack |
|---|---|---|
| Your agents can search your docs | ✓ | ✓ |
| Every answer says how far to trust it | — | ✓ |
| Using a page is what keeps it current | — | ✓ |
| An upkeep list your agents can work | — | ✓ |
Questions
Before you install.
Does docpack run its own AI?
No. docpack never calls an AI model. Your agent, whether Claude Code, Claude.ai or any MCP client, does the reading, running and fixing. docpack serves the pages, records what your agent reports and works out each page's status from review dates and run results.
Why not just keep Markdown in the repo?
You should, and docpack works on exactly that. What a plain folder lacks is a status per page: your agent can't tell a page that worked yesterday from one that went stale last spring. docpack adds the computed status, the record of runs and the list of pages that need work.
Where does our content live?
In your repo, as plain Markdown with a little frontmatter. docpack generates the site from it and never becomes the copy of record. Edits made in the browser come back as pull requests you review.
Which agents can use it?
Anything that speaks MCP. Claude.ai and Claude Code get a ready-made setup from the Connect button; any other client takes the same endpoint and key.
We don't have docs yet. Is it still worth installing?
Yes. If a repo has no docpack, you can take a starter pull request or give your coding agent a short prompt to set one up.
Can we set the status badge ourselves?
No, and that's deliberate. The badge is computed from when the page was last reviewed and how its recent runs went. Editing a trusted page without a fresh review moves it back to Needs review.
Write down the context that matters. Let your agent follow it.
Install the GitHub App and you get a hosted space for your docs, a connection for your agents, and a browser editor for people who never touch git.
Install the GitHub AppThe docpack CLI is free to install. The agent skills are in early access. Ask for access
Already set up? Sign in