Better prompts for your AI coding tools

You are a terminal agent, so investigate before coding: list the repo tree and read any router or error-handling modules already present. Then build CRUD for {{resource}} in {{language}} on top of {{database}}. Routes: POST returning 201, GET by id returning 404 when absent, PATCH, DELETE returning 204, and a collection route driven by cursor and limit parameters for keyset paging. Reject malformed bodies with a 400 that itemizes each failing field; answer 409 when a unique column would collide. Also deliver a table migration, a pooled connection module, and GET /healthz that round-trips {{database}}. Place new code under src/ using conventions the project already follows, or establish sensible ones. Apply the migration, write integration coverage for a full create-read-update-delete cycle, a rejected payload, a missing id, and a cursor fetch of page two, then run everything from the shell and keep iterating until green. Close with a summary of files touched.

Have Cascade draft a short plan first, naming the modules it will create, then execute it. Goal: a {{language}} REST service over {{database}} exposing /api/{{resource}}. Handlers: create, fetch a single record, PATCH updates, delete, and a listing route accepting page, limit (never above 100), and sort. A body failing validation gets a 400 whose payload is an array of per-field messages; an unrecognized id gets 404; inserting a duplicate into a unique column gets 409. Every query must go through this repo's ORM or prepared statements; SQL assembled from strings is banned. Include a schema migration plus a seeder inserting sample rows. In the editor terminal, run the integration suite until it passes; required cases: complete CRUD flow, malformed body, id that matches no row, and a page request beyond the final page. Finish with the created-file list and the command that boots the server locally.

Working with Copilot Edits file by file inside VS Code: begin by opening src and mirroring its existing layout. Step 1: a route module in {{language}} declaring five operations for {{resource}}: collection GET paged by a cursor token plus a limit count, single-record GET, POST, PATCH, DELETE. Step 2: a service module holding business rules, and a repository that talks to {{database}} only through bound parameters or the ORM this project already ships; concatenated SQL strings are forbidden. Step 3: register the router inside the application entry file. Behavior contract: schema-check incoming JSON and reply 400 naming which fields failed, 404 when an id matches nothing, 409 for uniqueness conflicts. Step 4: integration tests for one successful round trip, one schema-violating payload, one lookup of an absent record. Run the project's test command and report each added or modified file.

Build a REST API for {{resource}} records as Next.js route handlers under app/api, backed by {{database}}. No pages or UI, route handlers only.

Endpoints:
- GET /api/{{resource}}: paginated list. Accept page and limit query params (default 20, max 100) plus sort=createdAt:desc. Respond with { data, page, total }.
- POST /api/{{resource}}: create from a JSON body. Return 201 and the created record.
- GET /api/{{resource}}/[id]: one record, or 404 with { error: "not_found" }.
- PATCH /api/{{resource}}/[id]: partial update. Unknown fields are a 400, not silently dropped.
- DELETE /api/{{resource}}/[id]: 204 on success, 404 if the id does not exist.
- GET /api/health: { ok: true } for smoke checks.

Data model: id (uuid), name (string, 1 to 120 chars), status ("active" | "archived"), createdAt, updatedAt. Define one zod schema and derive the POST and PATCH validators from it so the rules never drift apart.

Error contract: every failure is JSON { error, message } with the correct status code. Validation failures return 400 with zod's field-level issues. A malformed JSON body must also be a 400, never an unhandled 500.

Put all {{database}} access in lib/db.ts behind list, get, create, update, and remove functions; handlers never import the client directly. Finish with a README block showing one sample curl per endpoint so I can verify each route from a terminal.

Build a REST API for managing {{resource}}, implemented as Supabase Edge Functions with a minimal admin page for exercising it.

Endpoints:
- POST /{{resource}}: create a record, validate required fields, return 201 with the created row.
- GET /{{resource}}: list with pagination (limit and offset params, default 20, max 100) and a sort param.
- GET /{{resource}}/:id: return the record or a 404 JSON body.
- PATCH /{{resource}}/:id: partial update, reject unknown fields with 400.
- DELETE /{{resource}}/:id: soft delete via a deleted_at column; exclude soft-deleted rows from every read.

Data model: a {{resource}} table in Postgres with id (uuid), created_at, updated_at, deleted_at, plus whatever fields fit {{resource}}. Propose the columns and wait for my confirmation before running the migration.

Behavior:
- Require a Supabase auth JWT on every endpoint; respond 401 without one.
- Scope rows to the authenticated user with Row Level Security policies, not only WHERE clauses.
- Errors are JSON: { "error": { "code", "message" } } with correct status codes (400 validation, 401 auth, 404 missing, 500 unexpected).
- Handle malformed JSON bodies and invalid uuids without the function crashing.

These endpoints must be callable with curl from outside the app; do not implement them as supabase-js calls inside React components.

Admin page: list records, a create form, and a panel showing the raw status code and JSON of the last request.

When done, print each endpoint with an example curl command against the deployed function URLs so I can verify all five paths.