What this prompt does
This prompt asks the AI to build a composable HTTP middleware system for a Go [framework] application, implementing exactly [middleware_count] layers drawn from [middlewares]. Every middleware follows the standard func(http.Handler) http.Handler wrapper pattern, gets functional options for configuration, injects context values for downstream handlers, and ships with documented ordering rules so you know which layer must run before which and why. The output also covers panic, timeout, and invalid-request handling per middleware, plus httptest-based tests that exercise how the layers interact.
The structure works because it forces the model to treat ordering and composition as first-class concerns rather than an afterthought. By pinning [middleware_count] and listing [middlewares] explicitly, you avoid a vague "add some middleware" answer and get a defined stack. The fluent chain builder (Use(logging).Use(auth).Use(cors)), per-route application, and conditional logic keyed on [conditional_criteria] mean not every layer hits every route, which is how real request pipelines actually behave.
When to use it
- You are standing up the HTTP layer for a new Go backend and want auth, CORS, rate limiting, and tracing to compose cleanly from day one.
- You inherited a router where middleware ordering bugs keep surfacing and you want the ordering rules written down.
- You need per-route middleware so public and authenticated routes share infrastructure without sharing every layer.
- You want functional-options configuration so each middleware is tunable without breaking its signature.
- You are benchmarking request overhead and want to see the cost each layer adds.
- You are onboarding a team and want a readable, testable pipeline instead of nested closures.
Example output
Expect a set of Go source files: one per middleware following the handler-wrapper pattern, a chain builder exposing the fluent Use(...) API, per-route registration examples, and a complete main-style example with all middleware composed. Alongside the code you get ordering documentation, httptest interaction tests, and benchmark stubs showing per-layer overhead.
Pro tips
- Set
[framework]to the router you actually use —chi,gin, or net/http — so the wrapper signatures and route registration match your project. - Keep
[middleware_count]and[middlewares]consistent; if you list eight names, ask for eight, or the model may quietly drop one. - Be specific with
[conditional_criteria]: "route path prefix" behaves very differently from "request header presence", and naming it shapes the conditional logic you get. - Ordering matters most for auth and rate limiting — push the model to justify why request ID and logging come first so panics are still traced.
- If the generated tests only cover middleware in isolation, ask explicitly for interaction tests where two layers run together.
- Iterate on the benchmarks separately; the first pass often returns stubs, so request real
testing.Bcases once the stack compiles.
