api-docs
Document a module or public API surface (functions, classes, CLI commands, endpoints) from the code itself. Use when the user asks for API reference, to document a module, or to write usage docs for a public interface.
git clone --depth 1 https://github.com/omnigent-ai/omnigent /tmp/api-docs && cp -r /tmp/api-docs/examples/scribe/skills/api-docs ~/.claude/skills/api-docsSKILL.md
# 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.Spin up a live local Omnigent server and exercise the Antigravity (Gemini) SDK harness end-to-end — build antigravity agents, run real turns, smoke-test, and bug-bash. Load when developing, testing, or debugging the antigravity harness (omnigent/inner/antigravity_executor.py, antigravity_harness.py, omnigent/onboarding/antigravity_auth.py) or its auth / model / tool-bridge behavior.
Spin up a live local Omnigent server and exercise the Cursor SDK harness end-to-end — build cursor agents, run real turns, smoke-test, and bug-bash. Load when developing, testing, or debugging the cursor harness (omnigent/inner/cursor_executor.py, cursor_harness.py, cursor_auth.py) or its auth / model / tool-bridge behavior.
Run the Omnigent server as a Docker compose stack (server + Postgres) on any Docker host — your laptop, a VPS, EC2 by hand, or as the base layer of any container-platform deploy. Invoke when the user wants to build the image, bring up the compose stack, debug the stack on a host they already have, or extend the stack for a new platform.
Have the Claude and GPT partners critique each other's answers across a configurable number of rounds (default 1) before converging on a synthesis. Use when the user wants the two perspectives stress-tested against each other, not just shown side by side.
Verify an implementer's diff with an INDEPENDENT, different-vendor sub-agent (diff plus contract only); turn blocking issues into fix-tasks and loop until clean.
Run independent subtasks in parallel — one git worktree and one implementation sub-agent per task, each opening its own PR — then cross-review every PR. polly never merges; the human does.
Delegate read-only investigation, debugging, audit, search, or code-understanding tasks to sub-agents; synthesize only from their structured reports.
Patterns and templates for generating valid Omnigent agent directories. Load when ready to create files.