What this prompt does
This prompt scaffolds a production-ready Go HTTP server with the boring-but-critical infrastructure already wired in. It frames the model as a senior Go engineer who favors the standard library and returns idiomatic, working Go. It asks for six deliverables: a main.go with sensible server timeouts, structured JSON logging via slog with a request-scoped logger, graceful shutdown on SIGTERM/SIGINT, a middleware chain, health and readiness endpoints, and env-based config plus a multi-stage Dockerfile.
Four variables tailor the scaffold. [service_name] names the service and the Docker image. [router_choice] selects the router or mux the middleware chain is built on. [port] is where the server listens with proper read, write, and idle timeouts. [log_level] sets the default slog level. The emphasis is on getting graceful shutdown right first, because killed-mid-request is the bug nobody reproduces locally — exactly the kind of production gap a solid template closes. Starting every service from the same scaffold also means logging, health checks, and recovery behave identically across your fleet, which pays off the moment you're debugging one at 2am.
When to use it
- You're standing up a new Go service and want it production-shaped from day one
- You keep skipping shutdown, recovery, and health checks and getting bitten later
- You want structured JSON logging with a request-scoped logger out of the box
- You need /healthz and /readyz endpoints with a real readiness check
- You want a multi-stage Dockerfile for a small final image
- You want a consistent template every new service starts from
Example output
You get the full file tree and each file's contents: a main.go starting the server on your port with read/write/idle timeouts, slog-based structured JSON logging at your log level with a request-scoped logger, graceful shutdown on SIGTERM/SIGINT that drains in-flight requests with a deadline, a middleware chain on your chosen router with request ID, panic recovery, and request metrics, /healthz and /readyz endpoints with a real readiness check, env-based config with defaults, and a multi-stage Dockerfile.
Pro tips
- Get graceful shutdown right first; killed-mid-request is the bug nobody reproduces locally, and the deadline on draining in-flight requests is the safeguard
- Pick
[router_choice]to match your team's convention; the prompt favors the standard library, so a light router like chi keeps things idiomatic - Replace the readiness check placeholder with a real dependency ping (DB, cache) before relying on /readyz in production
- Set
[log_level]to info for production and switch to debug only when investigating, so logs stay readable - Keep
[service_name]consistent across the binary, logs, and Docker image for clean observability - Confirm the timeouts on
[port]suit your traffic; defaults are sensible starting points, not universal truths
