What this prompt does
This prompt scaffolds a production Go REST API on the chi router with a clean layered structure rather than a single monolithic handler file. You set the [domain] and [architecture], and the AI lays out the project (cmd/, internal/, pkg/), a chi middleware stack covering logging, recovery, CORS, rate limiting, and request ID, and a strict Handler to Service to Repository separation. That layering is what keeps a Go codebase maintainable as features pile up, instead of collapsing into one bloated package that nobody wants to touch.
The variables select the concrete tooling for the stack. [db_driver] and [migration_tool] set the database and schema-migration approach, [auth_features] shapes the JWT middleware with access plus refresh tokens and role-based checks, and [validation_approach], [logger], and [config_lib] fill in request validation, structured logging, and configuration from env vars and a config file. [test_db] drives the integration test strategy, and the prompt insists on unit tests with mocks plus integration tests against a real test database, since mocks alone hide the bugs that actually bite in production.
When to use it
- Starting a new Go backend that needs to stay maintainable as the team grows
- Standing up a layered Handler/Service/Repository structure from the very start
- Wiring a complete chi middleware stack instead of assembling it piecemeal later
- Adding JWT auth with access and refresh tokens and role-based middleware
- Setting up database migrations and integration tests against a real test database
- Generating a Makefile, Dockerfile, and docker-compose for a smooth local setup
Example output
You get a full project layout with cmd/, internal/, and pkg/ directories, a chi router with the configured middleware stack, and cleanly separated handler, service, and repository layers. It includes database integration with migrations, JWT auth middleware, request validation, structured logging, graceful shutdown with context propagation, and a test suite spanning unit, integration, and API levels, plus a Makefile, Dockerfile, and docker-compose.yml for running everything locally.
Pro tips
- Set
[domain]to your real business area so the generated handlers and models are useful rather than placeholder code - Keep
[db_driver]as pgx for PostgreSQL; it is the performant, idiomatic choice for this clean-architecture layout - Use a real test database via
[test_db]like testcontainers; mocks alone miss the integration bugs that matter - Match
[logger]to your platform; slog is a solid stdlib default that avoids pulling in an extra dependency - Confirm the
[auth_features]cover refresh-token rotation if your app needs long-lived sessions - Keep the
[validation_approach]at the handler boundary so invalid requests are rejected before they reach your service layer - Review the middleware ordering carefully, since rate limiting and request ID placement changes runtime behavior
