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
- robustmq/robustmqtheir own version, first seen Oct 8, 2026
- Agenta-AI/agentatheir own version, first seen Jul 31, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- Agenta-AI/agenta★ 4.9ksame name
- robustmq/robustmq★ 1.9ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository35 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-atomic-actionSkill
- add-embodiment-componentSkill
- add-functorSkill
- add-robotSkill
- add-semantic-callSkill
- add-solverSkill
- add-task-envSkill
- add-task-programSkill
- add-testSkill
- benchmarkSkill
- implement-performanceSkill
- pre-commit-checkSkill
- project-dev-contextSkill
- prSkill
- releaseSkill
- review-prSkill
- add-atomic-actionSkill
- add-embodiment-componentSkill
- add-functorSkill
- add-robotSkill
- add-semantic-callSkill
- add-solverSkill
- add-task-envSkill
- add-task-programSkill
- add-testSkill
- benchmarkSkill
- implement-performanceSkill
- pre-commit-checkSkill
- project-dev-contextSkill
- prSkill
- releaseSkill
- review-prSkill
- update-api-docsSkill
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
- Distinctive: line 14
Run the checker in machine-readable mode:
- Distinctive: line 33
Add the export to an existing curated module page when one exists.
- Distinctive: line 35
Document a package-level re-export under its public import path, not only under the implementation module.
- Very specific: line 37
If no suitable curated page exists, add or extend the module section in
docs/source/api_reference/public_api.rst. - Distinctive: line 43
Write documentation that explains the API:
- Very specific: line 45
Add the export to the appropriate
autosummaryblock. - Very specific: line 46
Add the matching
autoclass, autofunction, autodata, or other detailed directive when the surrounding page provides detailed entries. - Distinctive: line 48
Add a concise section overview when names alone do not explain the group.
- Very specific: line 49
If the source docstring is missing or too vague for autodoc, improve it with a meaningful summary and Google-style `Args, Returns, and …
- Very specific: line 55
Keep the change scoped to documentation.
- Distinctive: line 66
Run Black on every changed Python file, then validate the documentation workflow:
- Distinctive: line 74
When source docstrings were changed, also run focused tests for those modules.
≈ “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.
Files
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
Run the checker in machine-readable mode:
python docs/scripts/check_api_docs.py --format jsonExit status 1 is expected when exports are missing. Read the JSON report; if
missing_countis zero, report that the docs are aligned and stop.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_referenceChoose 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.
Write documentation that explains the API:
- Add the export to the appropriate
autosummaryblock. - 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, andRaisessections where applicable. - Derive descriptions from the implementation and tests. Do not invent behavior, examples, guarantees, or parameter semantics.
- Add the export to the appropriate
- 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." Rerun the checker until it reports zero missing exports:
python docs/scripts/check_api_docs.pyRun 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-checkWhen 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.
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.

