Coding & Software
Explain Unfamiliar Code
Explains code you did not write at the level you ask for, tracing the data flow and flagging what it cannot tell from the snippet alone.
- Customizable fields
- 4 fields
Coding & Software
Document an API Endpoint
Writes reference documentation for one API endpoint from its code, covering parameters, responses, errors and a working example.
Designed for general-purpose AI assistantsPublished November 2026
Customize
Fill in the fields and the prompt updates. What you type stays in this page and is never saved or sent.
Preview
Write reference documentation for the API endpoint below, based only on the code and notes I provide.
API name and audience: developers integrating with our public API
Documentation format: Markdown
Authentication in use: not stated
Conventions to follow (style, naming, existing docs example): none
Endpoint code (handler, route definition, validation and response code):
{{endpoint code}}
Related types, schemas or error definitions: none
Document the endpoint with:
1. A one-sentence description of what it does and when to use it.
2. Method and path, with any version prefix.
3. Authentication and permissions required, or "not stated in the code" if I did not give them.
4. Parameters in a table: name, location (path, query, header, body), type, required or optional, default, constraints and description. Take constraints such as length, format and allowed values directly from the validation code.
5. Request example with realistic fake data. Mark invented values clearly as examples.
6. Success response: status code, fields and types, and a sample body.
7. Errors: every status code and error condition visible in the code, with the cause and what the caller should do.
8. Behavior worth knowing: idempotency, rate limits, pagination, ordering, side effects, anything asynchronous. Only include what the code shows.
9. Open questions: anything you could not determine from the code, for the author to answer. Never fill a gap with a guess.
Rules: do not describe behavior that is not in the code. If the code and my notes disagree, point out the conflict. Do not invent rate limits, scopes or error codes.1 required field is empty and will stay as a {{placeholder}} in the copied text.
How to use it
- Paste the handler plus the validation code and error handling, not only the route definition. Constraints and errors live in those places.
- Give an existing page of your docs under conventions so the new page matches its structure and wording.
- Answer the open questions section and regenerate. Those are the facts a reader will ask about first.
- Test the example request yourself before publishing. Documentation with a broken example is worse than no example.
Example output
Illustrative only. Real answers depend on your input and the assistant you use.
POST /v1/projects
Creates a project in the authenticated workspace. Use it when you need to create projects programmatically.
Authentication: not stated in the code. [open question]
Parameters (body)
| Name | Type | Required | Constraints | Description |
|---|---|---|---|---|
| name | string | yes | 1-80 characters, unique within the workspace | Display name |
| visibility | string | no | "private" or "team"; default "private" | Who can see it |
Example request
POST /v1/projects
{"name": "Website relaunch", "visibility": "team"}
Success: 201 Created, returns id, name, visibility, created_at.
Errors
- 400 invalid_name: name is empty or longer than 80 characters.
- 409 name_taken: a project with this name exists. Choose another name.
Behavior: not idempotent; sending the same request twice returns 409 the second time.
Open questions: what permissions are required? Is there a rate limit?Tips
Reference docs should list what the code does, not what the author hopes it does. The open-questions list is where the gaps between the two show up.
Generate docs for one endpoint at a time and review each against the code. A batch of endpoints tends to copy mistakes from one page to the next.
If you maintain an OpenAPI file, ask for the same endpoint in OpenAPI YAML as a second step, then validate it with your usual tooling.
Related prompts
Coding & Software
Write a Pull Request Description
Turns a diff and a ticket into a pull request description with context, changes, risk and a test plan that reviewers can follow.
- Customizable fields
- 6 fields
Coding & Software
Debug a Flaky Test
Finds why a test passes sometimes and fails other times, ranks the likely causes and gives an experiment to prove each one.
- Customizable fields
- 8 fields