---
name: API Docs
slug: api-docs
category: Writing
description: API Docs generates reference documentation for public APIs by reading the actual source code signatures, parameters, defaults, return shapes, and raised errors. Use it when you need accurate API reference or usage docs for a module, class, CLI, or endpoint.
github: "https://github.com/omnigent-ai/omnigent/tree/main/examples/scribe/skills/api-docs"
language: Python
stars: 8855
forks: 1336
install: "npx degit https://github.com/omnigent-ai/omnigent/tree/main/examples/scribe/skills/api-docs ~/.claude/skills/api-docs"
installs_to: ~/.claude/skills/api-docs
source_path: examples/scribe/skills/api-docs/SKILL.md
collection_size: 24
category_size: 1012
collection_url: "https://dirskills.com/collections/omnigent-ai/omnigent"
added: 2026-08-15T06:50:44.716Z
last_synced: 2026-08-15T06:50:44.716Z
canonical_url: "https://dirskills.com/skills/api-docs"
---

# API Docs

API Docs generates reference documentation for public APIs by reading the actual source code signatures, parameters, defaults, return shapes, and raised errors. Use it when you need accurate API reference or usage docs for a module, class, CLI, or endpoint.

**Install:**

```bash
npx degit https://github.com/omnigent-ai/omnigent/tree/main/examples/scribe/skills/api-docs ~/.claude/skills/api-docs
```

## README

# api-docs — document a public API surface from the code

Produce reference docs that match the code exactly, derived from the source, not
from assumptions about what the API "probably" does.

## Read the surface

Identify the public surface to document (a module, class, CLI command group, or
set of endpoints). Then have the researcher read it carefully:
- Dispatch the researcher (`purpose: explore`) to enumerate the public
  entry points and report each one's real signature, parameters, defaults,
  return shape, and raised errors — with file:line evidence.
- Prefer what the code declares (signatures, type hints, docstrings, default
  values) over prose descriptions. Public vs. private follows the project's
  convention (e.g. a leading underscore, or an `__all__` / export list).

## Structure

For each entry point:

    ### `<name>(<signature>)`

    <one-line summary of what it does>

    **Parameters**
    - `<name>` (`<type>`, default `<value>`) — <meaning>

    **Returns** — `<type>`: <meaning>

    **Raises** — `<Error>`: <when>

    **Example**
    ```
    <minimal, runnable usage>
    ```

## Write the entries

- Keep the summary to one line; put detail in the parameter and example
  sections.
- Document every public parameter, including defaults, in the order they appear
  in the signature.
- Give one minimal example per entry point that actually runs against the
  documented signature.
- Do not document private/internal helpers unless the user asks; a reference is
  the contract, not a code tour.

## Verify

Signatures, defaults, and error types drift fastest, so route the finished
reference through the `reviewer` (`purpose: review`) to confirm every signature
and default matches the current code.