Build an API endpoint with tests

Extract the ZIP. Copy its lc-tested-api-endpoint folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.

For Claude web, use the connector or copy the prompt. Keep private details in your assistant.

Copy, paste into your assistant, then answer its questions. No form or account is required here.

Open in ChatGPT ↗

Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.

Needed before the promised result: What the endpoint should do. You can still copy the reusable prompt and provide these in your assistant.

Saved only on this device. Copy counts contain the skill ID, never your text.

## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.

### Questions to ask only when missing
- What should I use for “What the endpoint should do”? [required] Plain words are fine: what it does, who can call it, what goes in and what comes back. Add the method and path if you know them.
- What should I use for “Your repo or code”? [conditional] With a coding agent, name the repo or folder. In a plain chat, paste: one similar endpoint and its test, the router file, the validation, auth and error helpers they import, the test helpers, your API docs file (such as openapi.yaml) if you have one, and the package file. When: Required in Chat mode when no code is supplied. In Run mode use the current repository.
- What should I use for “What to leave alone”? [optional] Optional. Files or areas the change must not touch. Using the existing sign-in check, and adding a new table or column, stay allowed unless you say otherwise. Authored default: changes to authentication, billing or payment code, and changes to existing database columns or data

## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.

## Authored skill instructions
## 1. Outcome
Add the endpoint described below to this codebase, then report in the sections set out in part 6. Done means every check in part 7 passes: the endpoint is registered and works as the contract says, every input is validated, auth and errors match the neighbouring endpoints, the tests cover success and every failure case in the contract, nothing that passed before now fails, no test was weakened, the docs are updated, and the report says exactly what was run and what was not. If that can't be reached, done means stopping by the stop rule in part 5 with a report that says why.

## 2. Context
What the endpoint should do:
"""
[DESCRIBE THE ENDPOINT HERE]
"""

The repo or code: [YOUR REPO OR CODE]
Leave alone: changes to authentication, billing or payment code, and changes to existing database columns or data

Who it's for: the person who owns this code, whoever reviews the change, and the developers who will call the endpoint. They need code that looks like the rest of the codebase, a contract they can rely on, and tests that prove it.

How you work (pick one; the report says which):
- **Run mode**: you can open the files in this repo and run commands in it (a coding agent, or a chat app with code tools connected to the repo). Make the changes and run every command yourself.
- **Chat mode**: anything else, including a plain chat and a code sandbox where you can only run pasted snippets. Write every new file in full and every changed file as a diff, and for every step that runs something, give the exact command and the result the person should see. The report then starts with the line "Nothing was run here. The results below are what to expect, not what happened."
Never report a command's output that you did not see.

Blank fill-ins: a value above that still reads as a capitalised placeholder in square brackets (such as [WHAT TO LEAVE ALONE]) was left blank.
- Spec that says "see attached": use the attached file as the spec.
- No spec: reply only "No endpoint description came through. Say what it should do, who can call it and what goes in and out, and send again." Never invent an endpoint.
- No repo or code: in Run mode, use the repo you are in. In Chat mode with no code pasted, reply only "No code came through. Paste one similar endpoint and its test, the router, the helpers they import and your API docs file, and send again."
- Nothing to leave alone given: never change authentication, billing or payment code, or existing database columns or data. Using the existing auth guard and adding a new table or a new column are allowed.
- A gap in the spec: fill it with the most usual choice for this codebase and mark it "(assumed)" in the contract. Never stop to ask about a gap. The usual choices are: the same path pattern as the neighbours; PATCH for a partial update, POST to create, GET to read, DELETE to remove; and for who may call it, signed-in users only, limited to records they own when the record belongs to a user.

## 3. What to pull out
- The stack: language, framework, router, validator, database layer, test framework, and the test, lint and typecheck commands.
- The closest existing endpoints (one or two that do similar work), and how each is laid out: route, handler, service, data access, auth guard, error helper, tests and docs.
- The contract from the spec (part 6 section 2), with every gap filled and marked.
- Where the API is documented: an OpenAPI or Swagger file, a reference page, a README section, or none.

Edge cases:
- No similar endpoint to copy: follow the framework's own documented pattern and say so in the report.
- No test setup in the repo: write the tests with the language's built-in runner (for example node:test, Python's unittest, Go's testing) and add no new dependency; if the framework needs a test helper you would have to install, write the tests for it and list the install command under follow-ups.
- No API docs: in Run mode, if the repo has none, add a short section for the endpoint to the README and say "No API docs found; added a README section". In Chat mode, if no docs file was pasted, never say the repo has none: give the docs entry ready to paste and say "Docs file not given: add this to your API docs."
- A helper you need but weren't given (Chat mode): use it only by the name and arguments the pasted code already uses, mark it "(used as in <file>, not seen)" in the report, and never guess its insides.
- The spec needs a new table or a new column: write a reversible migration in the repo's migration tool. Changing or removing an existing column, or changing existing data, is on the default leave-alone list: stop (part 5).
- A write that a client may retry (payments, orders, messages): accept an idempotency key if the codebase already has a pattern for one; otherwise list it under risks.
- A list that can grow: paginate it the way the neighbours do, or with a limit (default 20, maximum 100) and a cursor or page.
- The spec conflicts with how the codebase already works (a different error shape, a different path style): follow the codebase, and list the difference under assumptions.
- Tests that already fail before you change anything: record them in the baseline; they are not yours to fix.

## 4. Steps
Each step that runs something: in Run mode, run it and record what you saw; in Chat mode, write the command and the result it should show.
1. Read the stack, the router, and the one or two closest endpoints with their helpers, tests and docs.
2. Baseline: before changing anything, run the tests, lint and typecheck, and record the pass and fail counts and the names of any failures.
3. Write the contract (part 6 section 2), with every assumption marked.
4. Write the validation schema with the project's validator: a rule per field (type, required, length or range, format), with unknown fields handled the way the neighbours do.
5. Write the handler and any service or data-access code in the same layers as the neighbours, using the existing auth guard and error helper unchanged. Register the route.
6. Write the tests, one per status code in the contract: a success case with realistic data; one test per validation rule, and at least two in total; and, where the contract has them, not signed in (401), not allowed (403), not found (404) and conflict (409). Use the project's test helpers and fixtures; mock only outside services.
7. Run the new tests and the full tests, lint and typecheck. Fix failures in your new code, then run again.
8. Update the API docs with the contract, a sample request and a sample response.
9. Compare the final run with the baseline, write the report, then run the self-check.

## 5. Rules
- Match the codebase: same layout, validator, error format, auth guard and response shape as the neighbours. Add no new pattern, library or convention.
- Validate every input at the edge, before any database or service call. Return one consistent 400 body listing each field that failed and why.
- Errors: use the project's error format. Never return stack traces, SQL, file paths, secrets or internal ids the caller may not see. If the neighbours answer "not yours" with 404 rather than 403, do the same; the contract and the tests then use 404.
- Security: parameterised queries or the ORM only, never string-built queries; respect the project's body-size limit and rate limiter if it has them; read secrets from config, never write them into code or tests.
- Never weaken, skip, delete or loosen an existing test, assertion, lint rule or type to get a pass. If a test shows a bug in existing code, report it under suspected bugs; never bend an assertion to match it.
- Scope: change only the files the endpoint needs, and nothing on the leave-alone list. If the change grows past about 8 files, explain why in the report.
- Stop rule: gaps are never a reason to stop. Stop and report only when the same failure survives 3 fix attempts, when the endpoint can't be built without a change on the leave-alone list, or when the spec asks for something the codebase's security rules forbid (such as letting signed-out callers read other people's data). Keep only new files whose tests pass, revert the rest, and set the status to "Stopped: <reason>", with what you would try next.
- Facts: name only files, functions, helpers and commands that exist here.
- Write for a reviewer: plain words, short sentences, code in fenced blocks with the language named.

## 6. Output
In Chat mode, the first line is "Nothing was run here. The results below are what to expect, not what happened." Then use these sections in this order. Write "None" under any that is empty.
1. **Status**: one line, exactly one of "Done" (Run mode only), "Endpoint written, not run" (Chat mode) or "Stopped: <reason>"; then the mode, the stack, and the commands used for tests, lint and typecheck.
2. **Contract**: method and path; who may call it; a table of inputs with the columns Field | Where (path, query, body) | Type | Required | Rule; the success response with an example body; and a table of status codes with the columns Code | When | Body. Mark each assumption "(assumed)".
3. **Conventions matched**: the endpoint you copied, and one line each for layout, validation, auth, errors and tests; any deviation with its reason.
4. **Code**: every new or changed file in this order: route, handler, validation, service or data access, migration, tests, docs. New files in full; changed files as a unified diff.
5. **Tests**: a table with the columns Test | Case | Expected status, one row per test, covering every status code in the contract.
6. **Evidence**: a table with the columns Check | Command | Baseline | After. Rows: new tests, full tests (pass and fail counts), lint, typecheck. In Run mode, fill it from what you saw. In Chat mode, put "Not run" in every result cell and add one line under the table per row saying what the person should see.
7. **Try it**: one sample request (curl, or the repo's own HTTP client file) and the response it should return.
8. **Assumptions, risks and follow-ups**: every "(assumed)" choice, helpers used but not seen, security notes, suspected bugs, and anything a person must do by hand (such as running the migration).
9. **Commit message and PR text**: a commit subject under 72 characters, then a PR description with what the endpoint does, the contract in brief and how it was tested. In Chat mode, the PR text says the tests have still to be run.

## 7. Self-check
Before replying, check each of these and fix any failure:
- The mode is right (a sandbox with pasted code is Chat mode), and in Chat mode the first line is "Nothing was run here…", the status is "Endpoint written, not run" (or "Stopped: <reason>" when a stop rule applied), and no cell claims a result.
- The route is registered, and its method and path match the contract.
- Every input in the contract has a validation rule, and every status code in the contract has a test; no test exists for a code the contract doesn't have.
- Auth and errors use the same guard and format as the endpoint you copied, and no response leaks internal details.
- The baseline was taken before any change, and every failure in the final run that is not in the baseline is fixed or explained.
- No test, assertion, lint rule or type was weakened, skipped or deleted, and nothing on the leave-alone list was changed.
- The docs are updated, or the report gives the docs entry to paste and says why.
- Every file, helper and command you name exists or is marked "not seen", and every section of part 6 is present, in order.
Then reply with the output only, ending with one line: "Checked: <Done | Endpoint written, not run | Stopped>, <METHOD> <path>, <n> tests, <n> files changed."

## 8. Setup
With a coding agent that has your repo (Claude Code, Codex, Cursor, or ChatGPT with code tools connected to the repo), it writes the endpoint, runs the tests, lint and typecheck itself and reports what it saw. In a plain chat (ChatGPT, Claude, Gemini or Grok), paste one similar endpoint and its test, the router, the validation, auth and error helpers they import, the test helpers, your API docs file and the package file: you get every file in full or as a patch, with the commands to run and what each should show, and the reply says plainly that nothing was run.

Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.