What this prompt does
This prompt turns the model into a senior Node.js engineer that scaffolds a complete, production-ready API in TypeScript instead of toy snippets. It fixes the architecture up front — routes call services, services call repositories — so the handlers stay thin and the boring-but-critical pieces (validation, auth, logging, graceful shutdown, health checks) are wired in from the first file rather than retrofitted after an incident. Because it insists on working code over pseudocode, you get importable modules with real types, not illustrative fragments that fall apart when you connect them.
The [framework] variable swaps the HTTP layer between Express and Fastify, which changes the plugin and middleware idioms throughout. [domain] decides the example entities and routes the AI builds around, [auth] drives the JWT verification and how request.user is typed, and [node_version] pins both the language features it can use and the base image in the multi-stage Dockerfile. Naming all four narrows the output from a generic template to a service you could actually drop into your repo, with each layer demonstrating the dependency boundaries the prompt asks for.
When to use it
- Starting a brand-new Node + TypeScript backend and you want the layered skeleton correct on day one.
- Standardising how every service in a team handles validation, logging, and shutdown.
- Replacing a quick prototype that grew real traffic and now needs readiness probes and pool draining.
- Teaching a junior the difference between a demo API and one that survives a rolling deploy.
- Generating an OpenAPI spec and Dockerfile alongside the code so deployment isn't an afterthought.
- Auditing an existing service against a reference structure to find missing reliability pieces.
Example output
You get a printed file tree first, then the contents of the key files: the entry point, one route, one service, one repository, the config module, and a multi-stage Dockerfile. Request bodies, queries, and params each have a Zod schema funnelled through a single validation middleware, and request.user arrives typed after the JWT check. Structured pino logging carries a request-id for correlation, secrets are redacted, and the /healthz and /readyz endpoints sit alongside a SIGTERM handler that drains in-flight work. The shape is a coherent slice you can extend rather than a wall of disconnected fragments.
Pro tips
- Set
[framework]deliberately — Fastify's plugin model and Express's middleware chain produce noticeably different code, so don't leave it vague. - Make
[node_version]match what your CI and base image actually run; a mismatch between the pinned Dockerfile and your toolchain causes subtle build breaks. - Wire the SIGTERM drain and
/readyz(deliverable 5) before you containerise — orchestrators kill pods that report ready while still booting. - Describe
[domain]in real nouns from your product so the example route, service, and repo map onto entities you'll keep. - If
[auth]is an external provider rather than plain JWT, say so explicitly so the verification andrequest.usertyping match that provider's tokens. - Paste an existing route afterward and ask it to conform to the generated structure when you're adding to a service, not starting fresh.
