Scaffold a new service or library

Starter templates fail in two directions. Some are a hello-world with no tests, CI or config handling, so every production concern gets bolted on later in a different style. Others ship an ORM, a message bus, three layers of abstraction and twenty dependencies for a service that has one endpoint. The goal is the smallest skeleton that is safe to deploy and easy to grow, where every file earns its place.

Scaffold a new [LANGUAGE_OR_FRAMEWORK] project:

[DESCRIPTION]

Deploy target: [DEPLOY_TARGET] (if empty, treat it as undecided and keep the skeleton deploy-neutral).

1. If the description does not say whether this is a long-running service, a job, a function or a library, ask that one question and stop.
2. Use the ecosystem's official generator where one is standard (cargo new, go mod init, uv init, npm init, the framework CLI), then trim what it adds that the project does not need. Follow the ecosystem's conventional layout.
3. Include only these, adapted to the ecosystem:

• A manifest with a lockfile and a pinned runtime or toolchain version.
• The ecosystem's standard formatter and linter (ruff, eslint with prettier, golangci-lint, rustfmt with clippy) with default rules plus anything the description requires.
• A test runner with one real test of real behaviour.
• Configuration read from environment variables, validated at start-up, failing fast with a clear message. Include a .env.example with no secrets.
• For services: structured logging, a health endpoint and a separate readiness endpoint, and graceful shutdown on SIGTERM.
• A CI workflow stub that installs from the lockfile, lints, type checks, tests and builds, on pull requests and the main branch.
• If the target is a container: a multi-stage Dockerfile with a pinned base image that runs as a non-root user, plus a .dockerignore.
• .gitignore, .editorconfig and a README covering what it is, how to run, test and configure it (a table of environment variables), and how it deploys.

1. Run install, lint, test and build (and start the service if it is one, then hit the health endpoint). Fix anything that fails.

• No database layer, auth, queue, DI container or generic "utils" module unless the description requires it.
• Do not choose a licence; leave a README note asking the owner to add one.
• Pin versions you know are current and supported. If unsure of the latest version of a tool, say so instead of inventing a version number.
• Use no placeholder code that pretends to work. Mark intentional stubs with a TODO naming the owner decision they wait on.
• Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
• If you could not run a check, say so plainly and say which one.

Tree

The file tree.

Files

Each file in its own code block, headed by its path. Generated lockfiles are summarised in one line, not printed.

Why each piece

| File or tool | Why it is here | What to change later |

Left out on purpose

Common additions you did not include and when to add them.

Verification

Each command run and its actual result.