Create your first documentation Space

This walkthrough takes you from a repository to an editable documentation Space. Use a project you know so you can assess whether the first result describes its behavior correctly.

Before you start

Sign in to DocuWriter, confirm you can access the repository in its Git provider, and check that your account or team can start documentation generation. You need the exact branch name. A branch called main is common, but it is not universal.

1. Connect the repository

Open Git Connections and connect GitHub, GitLab, Bitbucket or Azure DevOps. Complete the provider's authorization, then add the repository and select its branch. Wait for the import to finish before using an imported repository in another generator.

If provider authorization is unavailable, Full Tree Documentation also accepts a one-time project ZIP. A ZIP does not provide ongoing synchronization.

2. Choose the intended reader

Open Full Tree Documentation. Select the source and output language, then choose an audience. Internal technical docs is a useful starting point for engineering teams; Developer onboarding prioritizes setup and the first flows a new engineer should learn.

Add a short project description that explains the product and the reader's goal. Use factual context, such as “This service processes subscription renewals; readers are backend engineers joining the team.”

3. Review the outline

Check the proposed sections before starting the full build. Put orientation and setup first, then the main workflows and reference material. Rename unclear headings, remove irrelevant topics and add missing context. See Review and customize the outline.

The dedicated generator includes an outline review before you start the build. Onboarding may continue an accepted, entitled plan directly into generation; follow the progress shown in that flow.

4. Inspect the generated Space

Open the resulting Space from Spaces. Wait for generation to complete and check the page statuses. Read the overview, one important workflow and one detailed reference page against your project. Correct mistakes in the editor before sharing.

A useful first result explains what the project does, how to get started, and how its main components fit together. An attractive outline alone is not the finished documentation.

5. Decide how to share and maintain it

Keep the Space private while reviewing. Invite the right teammates or publish it publicly after checking its contents. For a connected Git project, set up Autopilot to review future documentation changes.

If a step fails, keep the Space or repository name and the visible error. Use connection troubleshooting or generation troubleshooting rather than repeatedly starting new runs.