Get the FREE Ultimate OpenClaw Setup Guide →

api-reference

npx machina-cli add skill littlebearapps/pitchdocs/api-reference --openclaw
Files (1)
SKILL.md
7.4 KB

API Reference Generator Guidance

Philosophy

API reference docs are the Reference quadrant of the Diataxis framework — information-oriented, accurate, and complete. They document every public function, class, method, parameter, and return type.

This skill does not generate API docs directly — that's the job of language-specific tools (TypeDoc, Sphinx, godoc, rustdoc). Instead, it provides configuration guidance and comment conventions so those tools produce high-quality output.

Language Detection

Detect the project language to recommend the appropriate tool:

# Check for language-specific manifest files
[ -f "package.json" ] && echo "javascript/typescript"
[ -f "tsconfig.json" ] && echo "typescript (confirmed)"
[ -f "pyproject.toml" ] || [ -f "setup.py" ] && echo "python"
[ -f "go.mod" ] && echo "go"
[ -f "Cargo.toml" ] && echo "rust"

TypeScript / JavaScript (TypeDoc)

Tool: TypeDoc — generates HTML or Markdown documentation from TypeScript source code and JSDoc comments.

Installation

npm install --save-dev typedoc

Configuration

Create typedoc.json in the project root:

{
  "$schema": "https://typedoc.org/schema.json",
  "entryPoints": ["src/index.ts"],
  "out": "docs/api",
  "plugin": ["typedoc-plugin-markdown"],
  "readme": "none",
  "excludePrivate": true,
  "excludeProtected": true,
  "excludeInternal": true,
  "categorizeByGroup": true,
  "sort": ["source-order"]
}

For Markdown output (recommended for GitHub-hosted docs):

npm install --save-dev typedoc-plugin-markdown

TSDoc Comment Conventions

/**
 * Generates a marketing-friendly README from codebase analysis.
 *
 * Scans the project for features, translates them into benefit-driven
 * language, and outputs a complete README.md following the 4-question
 * framework.
 *
 * @param options - Configuration for README generation
 * @param options.projectPath - Path to the project root
 * @param options.format - Output format: 'github' | 'npm' | 'pypi'
 * @returns The generated README content as a string
 * @throws {ProjectNotFoundError} If projectPath doesn't exist
 *
 * @example
 * ```typescript
 * const readme = await generateReadme({
 *   projectPath: './my-project',
 *   format: 'github'
 * })
 * ```
 *
 * @see {@link FeatureExtractor} for the scanning workflow
 * @since 1.0.0
 */
export async function generateReadme(options: ReadmeOptions): Promise<string> {

package.json Script

{
  "scripts": {
    "docs:api": "typedoc"
  }
}

Python (Sphinx or MkDocs + mkdocstrings)

Option A: Sphinx + autodoc (traditional, feature-rich)

Installation:

pip install sphinx sphinx-autodoc-typehints sphinx-rtd-theme

Quick setup:

mkdir docs && cd docs
sphinx-quickstart --no-sep --project "Project Name" --author "Author"

conf.py additions:

extensions = [
    'sphinx.ext.autodoc',
    'sphinx.ext.napoleon',  # Google/NumPy-style docstrings
    'sphinx_autodoc_typehints',
]

autodoc_member_order = 'bysource'
autodoc_typehints = 'description'

Option B: MkDocs + mkdocstrings (modern, Markdown-native)

Installation:

pip install mkdocs mkdocs-material mkdocstrings[python]

mkdocs.yml:

site_name: Project Name
theme:
  name: material

plugins:
  - search
  - mkdocstrings:
      handlers:
        python:
          options:
            show_source: true
            show_root_heading: true

Python Docstring Conventions (Google style)

def generate_readme(project_path: str, format: str = "github") -> str:
    """Generate a marketing-friendly README from codebase analysis.

    Scans the project for features, translates them into benefit-driven
    language, and outputs a complete README.md following the 4-question
    framework.

    Args:
        project_path: Path to the project root directory.
        format: Output format. One of 'github', 'npm', 'pypi'.
            Defaults to 'github'.

    Returns:
        The generated README content as a string.

    Raises:
        ProjectNotFoundError: If project_path doesn't exist.
        PermissionError: If project_path is not readable.

    Example:
        >>> readme = generate_readme("./my-project", format="github")
        >>> print(readme[:50])
        # My Project
    """

Go (godoc)

Go has built-in documentation tooling. No extra packages needed.

Comment Conventions

// GenerateReadme produces a marketing-friendly README from codebase analysis.
//
// It scans the project at projectPath for features, translates them into
// benefit-driven language, and returns a complete README following the
// 4-question framework.
//
// The format parameter controls output: "github", "npm", or "pypi".
//
// Example:
//
//	readme, err := GenerateReadme("./my-project", "github")
//	if err != nil {
//	    log.Fatal(err)
//	}
//	fmt.Println(readme)
func GenerateReadme(projectPath, format string) (string, error) {

Running godoc

# Local documentation server
godoc -http=:6060

# Generate static HTML
go install golang.org/x/pkgsite/cmd/pkgsite@latest
pkgsite -open .

Rust (rustdoc)

Rust has built-in documentation via cargo doc. No extra packages needed.

Comment Conventions

/// Generates a marketing-friendly README from codebase analysis.
///
/// Scans the project for features, translates them into benefit-driven
/// language, and outputs a complete README following the 4-question
/// framework.
///
/// # Arguments
///
/// * `project_path` - Path to the project root directory
/// * `format` - Output format: `github`, `npm`, or `pypi`
///
/// # Returns
///
/// The generated README content as a `String`.
///
/// # Errors
///
/// Returns `ReadmeError::ProjectNotFound` if the path doesn't exist.
///
/// # Examples
///
/// ```
/// let readme = generate_readme("./my-project", "github")?;
/// println!("{}", &readme[..50]);
/// ```
pub fn generate_readme(project_path: &str, format: &str) -> Result<String, ReadmeError> {

Running rustdoc

# Generate and open docs
cargo doc --open --no-deps

Integration with Docs Hub

Once API reference docs are generated, link them from the docs hub page:

## Reference

- [API Documentation](reference/api.md) — All public functions, types, and interfaces
- [CLI Reference](reference/cli.md) — All commands, flags, and options

And from the README documentation section:

## Documentation

| Guide | Description |
|-------|-------------|
| ... | ... |
| [API Reference](docs/reference/api.md) | All public types and functions |

Anti-Patterns

  • Don't hand-write API docs — they go stale instantly. Generate from source code comments.
  • Don't mix API reference with tutorials — keep them in separate Diataxis quadrants
  • Don't document private/internal APIs — only document the public surface area
  • Don't skip examples — every non-trivial function should have a usage example in its docstring
  • Don't use @inheritdoc without checking — inherited docs may not make sense in the subclass context

Source

git clone https://github.com/littlebearapps/pitchdocs/blob/main/.claude/skills/api-reference/SKILL.mdView on GitHub

Overview

This skill helps teams set up API reference documentation by recommending the right generator (TypeDoc for TS/JS, Sphinx or MkDocs for Python, godoc for Go, rustdoc for Rust) and providing ready-made configuration templates. It detects project language and supplies concrete conventions so source-code comments produce accurate, high-quality API docs.

How This Skill Works

It first detects the project language via common manifest files, then suggests the appropriate tool. It then provides language-specific configuration templates (e.g., typedoc.json, sphinx conf.py, mkdocs.yml) and comment conventions so the chosen tool can generate consistent API docs from code comments.

When to Use It

  • Starting a new project and you want automated API docs generated from source comments.
  • Your repo is TypeScript/JavaScript and you prefer TypeDoc with Markdown output.
  • A Python project needs Sphinx or MkDocs with mkdocstrings for Markdown docs.
  • You’re working on a Go project and want to leverage godoc for API references.
  • A Rust project should use rustdoc for its API documentation.

Quick Start

  1. Step 1: Detect language by scanning manifest files (e.g., package.json, pyproject.toml, go.mod, Cargo.toml).
  2. Step 2: Apply the appropriate configuration template (typedoc.json for TS/JS, sphinx conf.py or MkDocs mkdocs.yml for Python).
  3. Step 3: Run the doc generator (e.g., npm run docs:api for TypeDoc or the tool’s standard command).

Best Practices

  • Detect the project language early by checking manifest files (package.json, pyproject.toml, go.mod, Cargo.toml).
  • Use the provided configuration templates instead of starting from scratch.
  • Align code comments with the tool’s conventions (e.g., TS: TSDoc; Python: Google/NumPy style).
  • Configure output paths and API surface (e.g., excludePrivate/Protected/Internal as appropriate).
  • Integrate docs generation into CI to ensure docs stay in-sync with code.

Example Use Cases

  • TypeScript project using TypeDoc with a typedoc.json template and Markdown output via typedoc-plugin-markdown.
  • JavaScript project adopting TypeDoc with the Markdown plugin and a package.json script (docs:api).
  • Python project using Sphinx with autodoc and napoleon in conf.py for Google-style docstrings.
  • Python project using MkDocs with mkdocstrings and a polished mkdocs.yml for Markdown docs.
  • Rust project guided to use rustdoc for API references, with language-detection ensuring the correct tool is used.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers