agentleFS
DexForceDexForce/EmbodiChain/.agents/skills/update-api-docs/SKILL.md

update-api-docs

Skill240 starsChanged 11 days agoApache-2.0View on GitHub

Generate or update EmbodiChain Sphinx API documentation for public Python exports. Use when the API docs checker or CI reports missing __all__ exports, after adding or changing public APIs, or when asked to fill, generate, or synchronize API-reference pages and their descriptions.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the checker in machine-readable mode:

    line 14
  2. Distinctive:

    Add the export to an existing curated module page when one exists.

    line 33
  3. Distinctive:

    Document a package-level re-export under its public import path, not only under the implementation module.

    line 35
  4. Very specific:

    If no suitable curated page exists, add or extend the module section in docs/source/api_reference/public_api.rst.

    line 37
  5. Distinctive:

    Write documentation that explains the API:

    line 43
  6. Very specific:

    Add the export to the appropriate autosummary block.

    line 45
  7. Very specific:

    Add the matching autoclass, autofunction, autodata, or other detailed directive when the surrounding page provides detailed entries.

    line 46
  8. Distinctive:

    Add a concise section overview when names alone do not explain the group.

    line 48
  9. Very specific:

    If the source docstring is missing or too vague for autodoc, improve it with a meaningful summary and Google-style `Args, Returns, and …

    line 49
  10. Very specific:

    Keep the change scoped to documentation.

    line 55
  11. Distinctive:

    Run Black on every changed Python file, then validate the documentation workflow:

    line 66
  12. Distinctive:

    When source docstrings were changed, also run focused tests for those modules.

    line 74

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Update API Docs

Generate useful API documentation for every public export reported by the read-only checker. Treat static __all__ declarations as the public API contract and preserve existing hand-written documentation.

Workflow

  1. Run the checker in machine-readable mode:

    python docs/scripts/check_api_docs.py --format json

    Exit status 1 is expected when exports are missing. Read the JSON report; if missing_count is zero, report that the docs are aligned and stop.

  2. Group missing entries by module. Read each reported source file and inspect the exported definition, signature, type annotations, and docstring. Locate existing API pages with:

    rg -n "automodule:: <module>|currentmodule:: <module>" docs/source/api_reference
  3. Choose the documentation location:

    • Add the export to an existing curated module page when one exists. Follow that page's headings, autosummary groups, and detailed autodoc directives.
    • Document a package-level re-export under its public import path, not only under the implementation module.
    • If no suitable curated page exists, add or extend the module section in docs/source/api_reference/public_api.rst. This file is an agent-maintained fallback, not checker output. Keep fallback module headings sorted by import path and entries in their declared __all__ order to minimize diff churn.
  4. Write documentation that explains the API:

    • Add the export to the appropriate autosummary block.
    • Add the matching autoclass, autofunction, autodata, or other detailed directive when the surrounding page provides detailed entries.
    • Add a concise section overview when names alone do not explain the group.
    • If the source docstring is missing or too vague for autodoc, improve it with a meaningful summary and Google-style Args, Returns, and Raises sections where applicable.
    • Derive descriptions from the implementation and tests. Do not invent behavior, examples, guarantees, or parameter semantics.
  5. Keep the change scoped to documentation. Do not alter runtime behavior, signatures, or __all__ merely to silence the checker. Do not replace curated prose with generic generated text or add placeholders such as "part of the public API."
  6. Rerun the checker until it reports zero missing exports:

    python docs/scripts/check_api_docs.py
  7. Run Black on every changed Python file, then validate the documentation workflow:

    pytest tests/docs/test_check_api_docs.py -q --confcutdir=tests/docs
    python -m sphinx -b dummy docs/source docs/build/api-docs-check

    When source docstrings were changed, also run focused tests for those modules. Fix new Sphinx warnings caused by the edit; distinguish them from unrelated pre-existing warnings.

Completion Report

Report the documented import paths, the pages or docstrings updated, and the validation results. If an export cannot be documented accurately from the repository, identify the exact missing semantic information instead of guessing.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.