Skip to main content

AI docs workflow

This section is for the agent-executed path.

Use it when you want an agent to perform approved repository work, not merely describe steps for you to follow. The agent should inspect the repo, edit the canonical docs and site integration, run synchronization, formatting, and verification locally, then hand back the changes with evidence.

These pages are a workflow contract. Opening this documentation does not launch an agent or mutate a repository by itself. Give the workflow and target repository to an agent that has local workspace access.

Use the manual workflow when you want to run each repository step yourself.

What this AI track covers

The AI track focuses on:

  • what context an agent needs
  • how to shape repo rules and boundaries
  • what artifacts or prompts should exist
  • which changes the agent should execute
  • how the agent verifies and hands off its work
  • how to review agent output before trusting it

Who does what

AgentHuman reviewer
Reads repo instructions and trusted sourcesSupplies missing product or ownership facts
Proposes scope and calls out risky decisionsApproves material scope or architecture choices
Edits canonical docs, generated mirrors, navigation, and testsReviews the resulting content and local diff
Runs sync, format, tests, build, and browser checksAuthorizes any deployment or Git mutation separately
Reports evidence, limitations, and unresolved risksAccepts or requests changes

The agent should stop and ask only when a missing fact, authority boundary, or product decision would materially change the result. It should not turn a well-scoped implementation request into a list of instructions for the user.

Example

A good AI-assisted setup gives an agent:

  • a clear repo summary
  • trusted source docs
  • edit boundaries
  • verification expectations
  • permission to make the approved local edits

A bad setup gives the agent only a repo name and asks it to figure everything out from scratch.

Why this matters

AI assistance works best when the repo context and execution boundary are explicit. Without them, the agent will either overreach, stop too early, or produce generic output that does not match the real integration surface.

Next steps