Manage GitBook Site

A skill for creating and maintaining entire GitBook documentation sites. Where gitbook-write covers what goes inside a single page, this skill covers everything around the pages: structure design, repo scaffolding, the GitBook REST API, and branding. Use the two skills together — this one calls into gitbook-write whenever it needs to generate or edit page content.

The fundamental constraint

The most important thing to internalize before doing anything: GitBook's REST API can do almost everything except set up Git Sync. Authorizing GitHub/GitLab, picking the repository, choosing the branch, setting the project directory for monorepo layouts, and choosing the initial sync direction are all UI-only operations. The API only lets you read the resulting Git Sync state (GET /v1/spaces/{spaceId}/git/info).

That means the cleanest end-to-end flow is always:

1. Claude scaffolds a Git repo locally (and, when tooling permits, the remote)
2. Claude creates the site, sections, and any empty spaces it can via the API
3. The user does a short, well-scripted UI step in GitBook to wire each space to its directory in the repo
4. Claude applies branding/customization via the API

The user's role in step 3 is unavoidable but should never be a surprise — generate clear, copy-paste-ready instructions for them. Reference: references/git-sync-handoff.md.

If the user explicitly does not want Git Sync, fall back to the API content path (the Imports API and template application) — covered briefly below and in references/api-cheatsheet.md.