GitHub

Connect GitHub so drafts about your product are written from your code.

Installing

Workspace settings → Integrations → GitHub. You are sent to GitHub to install the Workover app and choose which repositories it may read.

Install it on the organisation, not your personal account, if the repositories belong to a company. A connection that hangs off one person’s account breaks when they change role, and reconnecting means an admin who may no longer be there.

If the app is already installed on the organisation, the connect flow takes you to authorise rather than to install again — you will not be asked to duplicate the installation.

Choosing repositories

Grant the repositories that describe the product you document. There is no benefit to granting everything, and a smaller grant is easier to justify to whoever approves it.

You can change the selection later in GitHub without reconnecting.

What Workover can do with it

Read the contents of the granted repositories: source, README files, types, comments.

That is all. It does not open pull requests, push commits, comment on issues, or read your issues and CI logs.

Using it in a draft

Reference the repository in your brief and point at the part that matters — a directory, a file, an area of the product. Specific beats general for the same reason it does with a new engineer: “the webhook payloads in apps/api/src/modules/webhooks” produces something checkable, “our webhooks” produces something plausible.

Broad passes across a whole repository take longer and stream in as they go, so a large grounding run does not time out.

Keeping docs in step with code

The habit worth building: when an API changes, re-run the draft against the changed files instead of editing the prose from memory. Changes arrive as tracked suggestions, so you review the delta rather than re-reading the page.

Disconnecting

Remove the installation in GitHub, or disconnect from Workover. Drafts already written are unaffected — they are documents like any other.