[Amendary]
← Help Center

Document types

Amendary works with four kinds of page. They are generated differently, kept current differently, and your review mode means something slightly different for each. This page compares them.

Which type should I pick?

  • Prose documentation (the default): explain how something works or how to use it. Technical docs for engineers, or help-center articles for customers.
  • On-call runbook: how to run, check, roll back and escalate a system. For whoever is paged at 3am.
  • Incident how-to-fix playbook: one entry per known failure mode, with symptom, diagnosis, fix, verification and prevention.
  • Product updates changelog: a dated, customer-facing record of what shipped that grows on its own as you ship.

Prose documentation

  1. What it is. The default type. Ordinary explanatory pages, either technical docs for engineers or help-center articles for customers. This is what most of your watched pages are.
  2. How it is generated. You can write these yourself in Notion and just watch them, or use the docs-from-scratch wizard to draft a page set from a repo’s README, file tree and key source files. The wizard proposes an outline, generates one free sample page for you to judge, then the rest, and you review each page before it is published. Docs from scratch is a paid add-on.
  3. How it is kept current. The maintenance loop corrects them. When a code change makes a sentence on a page stale, Amendary drafts the fix with the evidence attached. Engineering-type pages follow commits on the repo’s default branch. Help-center pages follow the repo’s change trigger (commits by default, or a branch, GitHub Releases, or tags; see Pages & mapping).
  4. What your settings do for it. In auto mode, a change that is confident and fully grounded in the code publishes on its own. In review mode, everything waits in the Queue for you. A workspace on the free trial always waits in the Queue, whatever the mode, until it is on a paid plan (a sponsored workspace follows its mode like a paid one).

On-call runbook

  1. What it is. An operational page for the person on call: prerequisites and access, how to start and stop, health checks, common alerts and what to do about them, rollback, escalation. Written to be read under pressure, action first.
  2. How it is generated. Through the docs-from-scratch wizard, choosing the runbook type. It reads the repo and also any repos you marked as supporting (infrastructure, config, scripts), because that is where the real commands live. Grounding is stricter than for prose: any command, path, flag or default the page uses that is not found in the repo is listed as a warning for you to check before publishing, and a step with no exact command in the repo is written conceptually and marked TODO rather than guessed.
  3. How it is kept current. Corrected by the maintenance loop like prose, following default-branch commits. For a runbook a changed command, path, environment variable, default or flag counts as real staleness even if the surrounding text still reads fine, so those get corrected too.
  4. What your settings do for it. In auto mode, a change that is confident and fully grounded in the code publishes on its own. In review mode, everything waits in the Queue for you. A workspace on the free trial always waits in the Queue, whatever the mode, until it is on a paid plan (a sponsored workspace follows its mode like a paid one). Runbook generation is part of the docs-from-scratch add-on and is behind a feature flag that is not on for every team yet.

Incident how-to-fix playbook

  1. What it is. One page per known failure mode, each structured the same way: symptom (what you see), diagnosis (how to confirm it), fix (the steps), verification (how to know it worked), prevention. For the same on-call reader as a runbook.
  2. How it is generated. Through the docs-from-scratch wizard, choosing the incident type. It proposes one page per failure mode the code actually evidences (an error it raises, a known limit, a fragile dependency) and never invents failure modes to fill the set. Same strict grounding as runbooks: unverified commands and paths are flagged for review, and missing exact steps are marked TODO.
  3. How it is kept current. Corrected by the maintenance loop like prose and runbooks, following default-branch commits, with the same rule that a stale command, path or default is a correction worth making.
  4. What your settings do for it. In auto mode, a change that is confident and fully grounded in the code publishes on its own. In review mode, everything waits in the Queue for you. A workspace on the free trial always waits in the Queue, whatever the mode, until it is on a paid plan (a sponsored workspace follows its mode like a paid one). Incident playbook generation is part of the docs-from-scratch add-on and is behind a feature flag that is not on for every team yet.

Product updates changelog

  1. What it is. A customer-facing record of what shipped, kept in Notion. You choose a parent page; under it Amendary keeps one child page per month (or per week if you pick that), named by the period (for example September 2026), each holding that period’s entries under short dated headings. Entries are deliberately short and written for customers: one to three bullets, calling out breaking API or MCP changes and anything that needs a UI update, and skipping internal refactors, tests and tooling.
  2. How it is generated. Two ways, and they do not overlap. Day to day it is generated from shipped changes: each time a repo ships a change (per its change trigger) Amendary writes a short customer-facing entry for it. One entry per shipped change, never one per commit, and at most a few entries per repo per day. You turn that on from the Pages tab: set a page’s type to Product updates and map the repo to it, and that page becomes the changelog parent. Separately, the docs-from-scratch wizard can write a first Product updates page from the repo’s recent history in one go; every workspace gets one free Product updates run for that. The two are independent: neither uses up the other.
  3. How it is kept current. This type grows instead of being corrected. A new entry is added for each shipped change: same-day changes are appended to that day’s page, a new day gets a new page. Past entries are history. The maintenance loop does not go back and rewrite them; if an old entry needs a change, edit it in Notion.
  4. What your settings do for it. Your review mode decides whether new changelog entries publish on their own or wait for you. Auto mode: an entry publishes to its Notion page automatically and shows up in Activity with a link; it never enters the corrections list. A changelog entry only adds a short “what shipped” note, so unlike a doc correction it publishes even when the change was large, without waiting for review. Review mode: every entry waits in its own “Product updates awaiting review” section on the Queue page for you to publish or dismiss. A workspace on the free trial always waits until it is on a paid plan (a sponsored workspace follows its mode). The one thing still held for you in auto mode is an entry that names a specific version, path or URL the change does not back up, since that could be a made-up “we shipped X”. The changelog is behind a feature flag that is not on for every team yet.

Common questions about the changelog

How do I turn it on for a repo? On the Pages tab, find the page you want as the changelog home (or add it by link), open its map form, set the type to Product updates, and pick the repo. That page becomes the parent and the period pages are created under it. The Repos tab shows a read-only pointer to where each repo’s updates go. To move a repo’s updates, map it to a different Product updates page (Amendary confirms first, since it stops entries at the old one). If the Product updates type is missing, the feature is not enabled for your team yet.

What counts as a shipped change? Whatever the repo’s change trigger says: commits on the default branch, commits on a branch you name, a published GitHub Release, or a new git tag. It is the same signal that drives corrections to your help-center pages.

Why one page per date? Pages use the change’s own date, so a release published on the 9th lands on the 9th’s page even if Amendary processes it later. Several changes on one day are appended to that day’s page in order, which keeps the history easy to scan and stops the parent filling with near-duplicate pages.

Why did no entry appear? Usually one of these: the repo’s change trigger has no signal yet (for example Releases is chosen but none has been published; the Repos tab shows a warning with the fix); no page is set to Product updates for that repo, or the feature is not enabled for your team; the change was judged not relevant to customers (a refactor, tests, tooling); the repo already reached its daily entry cap; or, in review mode or on a free trial that is not sponsored, the entry is waiting in the Queue’s “Product updates awaiting review” section rather than published to the page.

Can Amendary write docs to GitHub instead of (or as well as) Notion?

Yes. On the Pages tab, choose Add destination and pick GitHub. Select the repo and where docs go: a folder in the repo (default docs) or the repo wiki. For the folder you can commit directly or open a pull request you review and merge. The destination then appears beside your Notion workspaces on the Pages tab, where an owner can remove it. Only workspace owners can add or remove GitHub destinations, since it grants write access to your repo.

It is independent of Notion: a repo can publish to Notion, to GitHub, or to both. It is off by default, and a repo with it off is never written to. Amendary only ever writes docs, never your code.

Markdown files already in that folder (or wiki) show up on the Pages tab as pages. Give them an audience and a shape, and they are checked against code changes like Notion pages; a correction is written back to the file, as a commit or a pull request depending on the destination. The dated Product updates changelog stays a Notion page.