docuwriter-documentation-lifecycle

---
name: docuwriter-documentation-lifecycle
description: Explains the Full Tree Documentation workflow from repository connection and tree review through Spaces, repository update reviews, and Autopilot. Use for questions about generating, organizing, or maintaining project documentation.
---

# From repository to maintained documentation

DocuWriter's main workflow takes a team from source code to a maintained, searchable documentation system:

1. **Connect the code.** Authorize a GitHub, GitLab, Bitbucket, or Azure DevOps connection, then choose the repository, branch, and source paths to document.
2. **Generate with Full Tree Documentation.** DocuWriter analyzes the selected source and proposes a documentation tree covering the project's architecture, modules, services, APIs, workflows, and implementation details. The team reviews or edits the tree before generation. DocuWriter then creates connected pages that explain related components in context.
3. **Work in Spaces.** The generated pages live in a navigable Space. Engineers can search and ask questions across the documentation, edit or add their own knowledge, collaborate, and share or publish the result. A Space can bring documentation from multiple repositories together.
4. **Maintain what changed.** For an on-demand review, inspect an existing Space against its repository changes, show the scope and maximum credits, and start analysis only after explicit approval. Autopilot separately examines changes in connected repositories, identifies pages they may affect, and drafts targeted updates. Engineers can review, refine, accept, or reject the suggestions. Controlled automatic application is available for configured workflows.

The team should review generated pages before relying on or publishing them. Autopilot requires a connected repository and a configured Space link to respond to later code changes.

## Route the maintenance request

Interpret the user's intended outcome, including relevant prior user context; do not require a particular phrase such as “update from repo.” For “update docs” with no clear source or editorial intent, ask whether the user wants to compare repository changes or revise page content. Preserve any named page from the conversation, resolve its authorized numeric ID, and do not silently select every page.

- **Compare an existing Space with repository changes:** `inspect-documentation-update`, then explicitly approved `start-documentation-update`, then `get-documentation-update-status` and browser handoff.
- **Change prose or add a section to an existing page:** inspect the intended document, then use `update-space-document` only after authorization for those edits.
- **Configure automatic maintenance:** use the existing Autopilot repository-link tools; this is separate from an on-demand review.
- **Create new codebase documentation:** use the relevant generator with its repository/source and acceptance prerequisites.

Discover the intended Space with `list-spaces` when needed and clarify ambiguity. Current-page context alone does not establish write permission.

## Inspect, approve, then review in the browser

Inspection is read-only: it may read provider APIs, but never queues analysis, reserves credits, or invokes models. Show the returned repository and branch, baseline/target commits, full/diff mode, selected or affected pages and rationale, maximum credits, and available credits before asking for approval. Page selection applies only to first/full reviews; omission means all reviewable pages. Diff reviews reject selected page IDs instead of ignoring them.

Only call `start-documentation-update` after explicit user authorization for the inspected scope and maximum credits, passing the returned `review_quote` unchanged. The quote lasts 30 minutes and is bound to requester, payer, source, commits, page scope/content, and price. Changed facts require inspection again; never silently broaden scope or increase price. Quote integrity and MCP annotations do not prove consent. Repeating the same accepted quote returns the same run, even after a terminal outcome; it never starts another paid attempt. A different active run returns a conflict and its browser link.

Say “review queued” or “review running,” not “documentation updated.” Status reads persisted progress, pending-change counts, credit usage, and the existing browser review URL; do not claim account credit balance from run-level usage. If an existing run has broader or different stored scope, say so. The browser owns inspecting diffs, applying/rejecting changes, approving new pages, resuming, and ending runs. Explain paused/failed state and link the browser; do not retry automatically. ZIP-backed Spaces, inaccessible sources, and eligibility failures require the returned guidance, not a workaround.