Continuous AI: How We Keep Our tapes.dev Docs Current

tapes is our open source telemetry layer for AI agent sessions—it creates durable, auditable records of every tool call, decision, and state change your agents make. We open sourced it earlier this month and the response has been strong. The codebase lives in a public repo. The docs site at tapes.dev lives in a private repo. That separation is intentional—the docs have their own build pipeline, their own deploy, their own review process. But it also means there’s no automated connection between a code change landing and the corresponding doc page getting updated. That gap is where things rot.

We wired Continue into our workflow to close it.

The Setup

The pipeline watches the tapes repo. When a PR merges that touches public-facing surfaces (CLI flags, API endpoints, configuration schemas) it evaluates whether the docs need updating. If they do, it opens a PR against the docs repo with the relevant changes. If they don’t, nothing happens.

That’s the whole idea. Here’s the agent prompt that drives it from the Continue inbox feature:

# Your Job

You write documentation for Tapes. When code changes in a PR, you decide if docs need updating and make those updates if needed.

Write clearly and stay technical. Don't invent features or behavior that aren't in the PR.

# Execution Context

You're reviewing a PR in the Tapes repository. Documentation lives in the papercomputeco/tapes.dev repo in /src/pages.

You have access to:
- the current PR's diff, description, comments, and metadata
- gh (GitHub CLI)
- git

You must discover all needed context from the current PR.

# Workflow

## Step 1: Review the PR

Look for changes that affect what users see, configure, or need to understand:
- New or changed config options, env vars, or defaults
- New features or removed features
- Changed behavior in existing features
- Setup or installation changes
- New permissions or requirements
- Breaking changes or migrations
- Changed error messages or warnings

Internal changes that don't affect users (refactors, test updates, internal APIs) don't need docs.

## Step 2: Check current documentation

Review what's already documented in papercomputeco/tapes.dev /src/pages. Search for mentions of anything this PR changes. If the PR adds a new config option, search for that section. If it changes behavior, find where that behavior is documented.

## Step 3: Decide if docs need updating

Docs need updating if:
- This PR adds something users need to know about that isn't documented
- This PR changes how something documented currently works
- This PR removes something that's currently documented
- This PR contradicts what the docs currently say

Docs don't need updating if:
- The change is purely internal
- The behavior already matches what's documented
- The change is experimental or feature-flagged and not user-facing

Make your decision. If no docs update is needed, comment on the PR explaining why and stop here.

The implementation is straightforward: the agent has access to both repos, understands the mapping between code and doc pages, and produces targeted diffs rather than full rewrites.

A Concrete Example

We recently merged tapes#109, which added provider selection for OpenCode sessions. The PR introduced --provider and --model CLI flags, an interactive selection prompt, and config persistence to config.toml. Three providers: Anthropic, OpenAI, and Ollama.

That’s the kind of change that touches multiple doc pages. The CLI reference needs the new flags. The OpenCode guide needs updated instructions. The configuration reference needs the new [opencode] section. In practice, this is exactly the update that gets deferred indefinitely because no single page feels urgent enough to prioritize.

The pipeline picked up the merge and opened a docs PR. You can see the result in the OpenCode guide. The PR hit all three pages:

• 01.CLI reference — Added --provider and --model flag documentation, a new “OpenCode Provider Selection” section explaining the preference resolution flow, and updated the config keys table.
• 02.OpenCode guide — Removed the “Work in Progress” warning (the feature was complete now), added an interactive prompt example, and documented the provider flag usage with examples.
• 03.Configuration reference — Added the [opencode] section to the example config.toml.

Three files, 100 additions, 39 deletions. A team member reviewed and merged it the same day. The docs were accurate before any user had a chance to notice they weren’t.

This wasn’t a one-off. A few days earlier, tapes#98 landed the tapes auth command—credential storage in ~/.tapes/credentials.toml, auto-injection of API keys when launching agents via tapes start, and a Codex-specific workaround that temporarily patches ~/.codex/auth.json during sessions. That’s a feature with real footguns (personal project keys don’t work, you need service account keys) and the kind of nuance that absolutely needs to be in the docs.

The resulting docs PR added a full tapes auth section to the CLI reference with usage examples, flag documentation, provider-specific environment variables, and the service account key requirement. 75 additions across 2 files. Reviewed, merged, done.

Takeaway

It’s a pragmatic fix for a specific operational problem: keeping reference docs in sync across repos when the team is small and shipping fast. The creative writing still happens manually. The mechanical syncing doesn’t have to.

Doc updates are just one agent. The same pattern works for other checks you want running on every PR. We also run an “Anti-Slop” agent that flags AI-generated boilerplate and an “Accessibility” agent that reviews for a11y issues. Each one is a lightweight agent that triggers on PR merge and either opens a follow-up or comments with “no changes needed.”

The docs are at tapes.dev. The code is at github.com/papercomputeco/tapes. If you’re running a similar setup with code and docs in separate repos, this pattern is worth trying.