Write clear API reference docs straight from source code

Documentation drifts from code the moment it's written by hand. Generating reference docs directly from source keeps them anchored to reality—provided the model documents only what's actually there. That's the discipline this prompt enforces: describe behavior present in the code, and mark anything ambiguous as TODO instead of inventing it. It produces structured docs (purpose, parameters with types and constraints, return values, errors/status codes, a minimal example) in whatever format your project uses—Markdown, JSDoc, docstrings, or OpenAPI-style prose. Tell it the audience so the tone and examples fit: internal teammates need different detail than external API consumers. The closing list of undocumented behaviors and edge cases is the most valuable part for a reviewer—it surfaces the gaps a human should fill. Feed it one module or set of related endpoints at a time for accuracy, and always read the examples it generates against the real signatures before publishing.

What you can expect back

### `createUser(input)`

Creates a new user record and returns the persisted user.

| Parameter | Type | Required | Notes |
|-----------|------|----------|-------|
| `input.email` | string | yes | Must contain '@'; otherwise throws. No further format validation. |
| `input.age` | number | no | Defaults to `null` when omitted. |

**Returns:** `Promise<User>` — the inserted user record.

**Throws:** `ValidationError('invalid email')` when `email` has no '@'.

**Example:**
```ts
const user = await createUser({ email: '[email protected]', age: 31 });
```

Needs clarification:
- TODO: Behavior on duplicate email is not handled here—does `db.users.insert` reject?
- TODO: Email check is minimal ('@' only); is stricter validation expected upstream?
- TODO: No constraint documented for `age` range (negative numbers accepted as written).

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Document one module or endpoint group at a time so the model can be precise instead of broad.
• 02Treat every TODO it emits as a real action item—those are the genuine doc gaps.
• 03Verify generated examples compile/run; the model can produce plausible-but-wrong example calls.
• 04Set [AUDIENCE] explicitly so internal jargon is either kept or explained appropriately.

Adapt it for your case