> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parsaa.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Documentation Generator

> Auto-generate Swift inline documentation for your code

## Overview

Parsaa generates inline documentation for your Swift code. Summon it with the **`@documenter`** mention in the composer, with a file focused in Xcode, and it adds documentation comments to your types, methods, and properties.

<Info>
  `@documenter` is a built-in sub-agent. Configure it in **Settings → Automation → Doc Generator**: choose the output format (DocC `///` comments or Jazzy-style Markdown), whether to include private symbols, and whether to generate usage examples — those settings are passed to the agent on each run.
</Info>

## What It Generates

<CardGroup cols={2}>
  <Card title="Function & Method Docs" icon="gear">
    Parameter descriptions, return values, and throws documentation for every function and method.
  </Card>

  <Card title="Type Overviews" icon="cube">
    High-level descriptions for classes, structs, enums, and protocols that explain their purpose and usage.
  </Card>

  <Card title="Property Documentation" icon="tag">
    Clear descriptions for properties, including their role and any constraints or expectations.
  </Card>

  <Card title="Usage Examples" icon="code">
    Inline code examples showing how to use the documented API correctly.
  </Card>
</CardGroup>

## How to Use

<Steps>
  <Step title="Enable the generator">
    Turn on **Doc Generator** in **Settings → Automation → Doc Generator** and pick your format and options.
  </Step>

  <Step title="Focus the file in Xcode">
    Open the file you want documented so it becomes the focused file.
  </Step>

  <Step title="Mention @documenter">
    In the Parsaa composer, type `@documenter`. Parsaa documents the focused file's symbols in place.
  </Step>

  <Step title="Review & apply">
    Review the generated comments in the diff, then apply. They're formatted for Xcode's Quick Help and DocC.
  </Step>
</Steps>

## Example

**Input** — a function without documentation:

```swift theme={null}
func fetchUser(by id: String, includeProfile: Bool) async throws -> User {
    let endpoint = Endpoint.user(id: id, includeProfile: includeProfile)
    let response = try await networkClient.request(endpoint)
    return try decoder.decode(User.self, from: response.data)
}
```

**Output** — with generated documentation:

```swift theme={null}
/// Fetches a user from the remote API by their unique identifier.
///
/// Retrieves the user record from the server. Optionally includes
/// the user's full profile data in the response.
///
/// - Parameters:
///   - id: The unique identifier of the user to fetch.
///   - includeProfile: Whether to include the user's full profile
///     data in the response. When `false`, only basic user info
///     is returned.
/// - Returns: The requested ``User`` instance.
/// - Throws: A network error if the request fails, or a
///   `DecodingError` if the response cannot be parsed.
func fetchUser(by id: String, includeProfile: Bool) async throws -> User {
    let endpoint = Endpoint.user(id: id, includeProfile: includeProfile)
    let response = try await networkClient.request(endpoint)
    return try decoder.decode(User.self, from: response.data)
}
```

## DocC Compatibility

Generated documentation is fully compatible with Apple's DocC documentation system.

<AccordionGroup>
  <Accordion title="Quick Help">
    Documentation appears in Xcode's Quick Help panel (Option-click on any symbol) immediately after you apply it.
  </Accordion>

  <Accordion title="Documentation Browser">
    When you build documentation with DocC, Parsaa-generated comments are included automatically — no extra configuration needed.
  </Accordion>

  <Accordion title="Symbol Links">
    Parsaa uses double-backtick syntax (e.g., ` ``User`` `) to create symbol links that DocC resolves into navigable references.
  </Accordion>
</AccordionGroup>

<Tip>
  For best results, generate documentation after your API is stable. Documenting code that's still changing means you'll need to regenerate when the interface evolves.
</Tip>