Node.js prompts for ChatGPT, Claude and Codex

These 13 Node.js prompts help ChatGPT, Claude, Claude Code and Codex write server and tooling code that holds up under load: no blocked event loop, streams that respect backpressure, graceful shutdown, tests with the built-in node:test runner, TypeScript without a build step, and planned upgrades between Node.js versions. Each prompt is a template with blanks you fill in.

For the language itself, such as async patterns, ES modules and browser code, use the JavaScript prompts. If you searched for prompts that ask the user for input in a terminal, prompt 11 builds an interactive CLI with the built-in readline module.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{node_version:24}} means Node.js 24 unless you change it.

State your Node.js version. The Node.js releases page lists Node.js 26 as Current and Node.js 24 and 22 as LTS as of 26 October 2026. The Node.js 26.0.0 release notes say it enables the Temporal API by default and will enter long-term support in October; the Node.js release schedule sets that for 28 October 2026. The releases page also says that starting with Node.js 27, there will be one major release a year and every major version will move to LTS.

Say whether the code is CommonJS or ES modules, and which framework you use, if any. Paste the package.json with the code, since "type" and "engines" change what the model should write.

In an agent, let it run node --test or your test script after each change. For performance prompts, ask it to measure before and after rather than guess.

Which built-in Node.js features can replace dependencies?

Many prompts below ask the model to use built-in modules instead of packages. Mention your version, because these became stable at different times. Stability below is from the official Node.js API docs, read on 26 October 2026.

If you're on an older line, tell the model, and it should fall back to packages where a feature isn't stable yet.

How do you keep the event loop fast?

1. Find code that blocks the event loop

The Node.js guide Don't Block the Event Loop warns against synchronous fs, crypto and zlib APIs in servers, regular expressions with nested quantifiers like (a+)*, and unbounded JSON.parse on client input. It sums it up: "the Event Loop should orchestrate client requests, not fulfill them itself."

Our Node.js {{node_version:24}} server gets slow for every user when
one request does heavy work. Here is the request handling code:

{{code}}

Find everything that can block the event loop: synchronous fs, crypto,
zlib or child_process calls, regular expressions at risk of
catastrophic backtracking, JSON.parse or stringify on unbounded input,
and long loops. For each, give the fix: async API, input size limits,
a safer pattern, partitioning with setImmediate, or moving the work to
worker_threads. Tell me how to confirm the fix with event loop delay
measurements.

2. Move CPU-heavy work to worker threads

This function {{work:resizes images}} and takes about {{time:400 ms}}
of CPU per call:

{{code}}

Move it to worker_threads with a small fixed pool sized to the
available CPUs, not one worker per request. Pass data with transferable
objects where possible to avoid copying. Handle worker errors and
crashes, add a timeout per task, and keep the public function's
signature the same. Show the pool, the worker file and a test.

3. Process a large file with streams

This code reads a {{size:4 GB}} {{format:CSV}} file into memory and
crashes:

{{code}}

Rewrite it with streams and pipeline from node:stream/promises so
backpressure is handled and errors in any stage close every stream.
Process records one at a time, write results to {{output:a new file}},
and report progress every 100,000 rows. Keep memory flat regardless of
file size. Explain where backpressure would have broken in a manual
pipe chain.

How do you build reliable Node.js services?

4. Add graceful shutdown

Add graceful shutdown to this Node.js HTTP service that runs in
{{platform:Kubernetes}}:

{{code}}

On SIGTERM and SIGINT: stop accepting new connections, let in-flight
requests finish with a deadline of {{deadline:25 seconds}}, close
database pools and queue consumers, then exit with the right code. Fail
health checks as soon as shutdown starts. Make sure a second signal
forces exit. Show the code and a way to test it locally.

5. Handle errors and unhandled rejections

Review error handling in this Node.js service:

{{code}}

Find promises that are never awaited, callbacks that swallow errors,
and places where an error could crash the process or leave it in a bad
state. Set up process-level handlers for unhandledRejection and
uncaughtException that log with context and exit, instead of trying
to continue. Add a central error handler for {{framework:Express}}
that hides internals from clients. List every change.

6. Add timeouts and cancellation to outgoing calls

This service calls other APIs and a database without timeouts:

{{code}}

Add a timeout to every outgoing call using AbortSignal.timeout() or an
AbortController tied to the incoming request, so work stops when the
client disconnects. Retry only idempotent calls, with backoff and a
limit. Make sure aborted requests release their resources. Show the
changes and a test where the downstream service hangs.

7. Load configuration safely

The Node.js CLI docs say --env-file is no longer experimental and throws if the file doesn't exist, while --env-file-if-exists doesn't.

Clean up how this Node.js app reads configuration:

{{code}}

Replace scattered process.env reads with one config module that
validates every value at startup, applies defaults, converts types and
fails with a clear message listing all missing variables at once. Load
local values with node --env-file-if-exists=.env instead of a
dependency, and keep secrets out of logs. Show the module and the
updated start scripts.

How do you test Node.js code?

8. Write tests with node:test

The Node.js test runner docs list node:test as stable since v20.0.0, run with node --test. Code coverage with --experimental-test-coverage is still experimental.

Write tests for this module using the built-in node:test runner and
node:assert, with no other test dependencies:

{{code}}

Cover the happy path, each error path and one edge case from the code.
Use mock.fn() for callbacks, mock.timers for code that uses setTimeout,
and a temporary directory for file system work. Group with describe
and it, and give each test a name that describes behavior. Show the
package.json test script.

9. Run TypeScript directly with type stripping

The Node.js TypeScript docs say type stripping is enabled by default and stable, that Node.js ignores tsconfig.json, and that enums, namespaces with runtime code and parameter properties are unsupported. They recommend erasableSyntaxOnly and verbatimModuleSyntax in tsconfig.

We want to run our TypeScript with Node.js {{node_version:24}} type
stripping and drop the build step for {{scope:scripts and tests}}.

Our tsconfig.json and a sample of the code:
{{code}}

List everything that won't run under type stripping: enums,
namespaces with runtime code, parameter properties, imports of types
without the type keyword, missing .ts extensions in imports, and paths
aliases. Show how to rewrite each, and give a tsconfig with
erasableSyntaxOnly and verbatimModuleSyntax so the editor flags new
problems. Keep tsc for type checking only.

How do you secure, debug and upgrade Node.js apps?

10. Limit a script with the permission model

The Node.js permissions docs list the permission model as stable and call it a "seat belt" that "does not provide security guarantees in the presence of malicious code."

This Node.js script only needs to read {{read_path:./data}} and write
{{write_path:./out}}:

{{code}}

Show how to run it with --permission and the narrowest --allow-fs-read
and --allow-fs-write values, plus --allow-net or --allow-child-process
only if the code needs them. Tell me which calls would throw
ERR_ACCESS_DENIED today and why. Explain what the permission model does
not protect against, so we don't treat it as a sandbox.

11. Build an interactive CLI

The readline docs show node:readline/promises with await rl.question(), and note the interface keeps the process waiting until it is closed.

Build a Node.js CLI called {{name:setup}} with no dependencies that
does this:

{{behavior}}

Parse flags with util.parseArgs, ask for anything missing with
node:readline/promises, validate each answer and ask again on bad
input. Support --yes to skip questions and fail with a clear message
when input isn't a terminal. Exit with proper codes and print errors
to stderr. Show the file and an example session.

12. Find a memory leak in a long-running server

Our Node.js server's memory grows from {{start:300 MB}} to
{{end:2 GB}} over a day, then restarts. Here is what we have:

{{evidence}}

List the likely causes for a server: caches without limits, listeners
added per request, timers never cleared, closures holding large
objects, and growing global maps. Tell me how to take and compare heap
snapshots safely in production, what to look for in the retainers, and
how to confirm a fix with a load test.

13. Plan a Node.js version upgrade

Plan an upgrade from Node.js {{from:20}} to {{to:24}} for this project:

{{package_json_and_ci}}

List removed and deprecated APIs from the release notes between those
versions that could affect us, native addons that need rebuilding,
dependencies that need new versions, and changes to Docker base images
and CI. Give a step-by-step plan with the tests to run after each step,
and mark anything you're unsure applies.

Turn your favorite one into a skill

If you run the event loop or shutdown prompt on every service, make it a skill so Claude Code or Codex applies it when the task matches. Paste the prompt into the free SKILL.md generator to get a valid SKILL.md in your browser. For deeper tuning, the performance optimization prompts work across languages, and the TypeScript prompts help with types once your code runs.

To keep these prompts one shortcut away, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, blanks like {{node_version:24}} stay fillable, and Cmd+K finds any prompt by name or tag.