Docs
Keeps your documentation complete and accurate against your code, one reviewable pull request at a time — and stands a docs site up from scratch when you don't have one yet.
The docs loop keeps your documentation in sync with what your product actually does. On a schedule it clones your repo, reads the real implementation, builds a coverage map of every user-facing surface, and opens a single pull request that deepens thin pages, documents missing ones, or fixes drift. Your merge is what publishes. This very site is produced by it.
Prerequisites
- A connected GitHub repo — the docs live in your repo as MDX content, and the loop reads your code to ground every page.
What it does each run
It picks one of three modes from what it finds in your repo:
- Expand — when coverage has real gaps, it takes the highest-value coherent area and brings it fully to the quality bar: several new pages, or substantial rewrites of shallow ones. It will rewrite a vague page, not just append to it.
- Sync — when coverage is already complete, it fixes drift (a page that contradicts the current code) and makes targeted corrections.
- Scaffold — when your repo has no docs area at all, it stands one up: a small, grounded starter (one to three real pages) plus a Docs link added to your site's nav, all in one PR. It never leaves you a "set it up yourself" note.
Whichever mode, it keeps each run to one coherent area of at most ~5–6 pages and ships it, listing the remaining gaps in the PR body so the next run continues where it left off.
The quality bar
The loop's enemy is shallow, plausible-sounding, marketing-flavored docs. Every page it writes has to be:
- Task-oriented and grounded — it leads with what you want to accomplish, in second person, with no hype.
- Concrete and code-derived — real UI labels, env var names, defaults, limits, and file paths, each traced to a file it actually read that run. If it can't verify a detail, it omits it rather than inventing one.
- Backed by a real example — a command, a code block, or a concrete walkthrough with actual values.
- Deep in proportion to the feature, consistently structured, and cross-linked into the nav.
What you get
A single pull request against your repo's docs content. Merging is what publishes — the hosted docs pipeline builds and serves the MDX; the loop only ever adds content, never a docs framework. Review the prose and structure on GitHub like any other change.
When the loop scaffolds a new docs site, the PR also adds a Docs link to your product's site pointing at where the docs publish (your <slug>.docs.1mn.app address, or your active custom domain).
Cadence
The docs loop runs on its own roughly every 7 days, and you can trigger it any time by asking the dispatcher (for example, "improve my docs" or "my docs are out of date"). After a scaffold PR merges, the next scheduled run finds the new content directory and switches to normal expand/sync maintenance — it never re-scaffolds.
Notes & limits
- It skips honestly. If GitHub isn't connected, or the product is too new to have any real surface to document, or coverage is already complete with no recent code change, the run skips with a one-line reason rather than padding a hollow page.
- The PR body is the handoff — it lists what was added, deepened, or fixed, plus the prioritized remaining coverage gaps for the next run.
Error triage & investigation
Turn a captured client-side crash or a reported symptom into a proven root cause — and a fix pull request when the cause is clear and the fix is small and low-risk.
Feature inventory & QA
A canonical, always-current map of every feature in your product — and a browser-based QA loop that re-verifies the ones that matter as your code changes.