What this prompt does
This prompt implements a specific Go concurrency pattern for a real use case rather than a textbook toy. You set [pattern_name] such as Worker Pool, Fan-Out/Fan-In, or Pipeline, and [use_case], and the AI produces a runnable main.go with a goroutine-lifecycle ASCII diagram, an implementation using the [concurrency_primitives] you choose, context propagation for cancellation and timeouts, and errgroup-based error handling across goroutines. It front-loads exactly the parts where concurrency bugs hide, instead of just spawning goroutines and hoping nothing leaks.
The variables tune the implementation to your workload. [concurrency_primitives] picks the building blocks like channels, sync.WaitGroup, context, and errgroup, [buffer_size] sets the backpressure behavior of buffered channels, and [benchmark_size] drives a sequential-versus-concurrent benchmark so you can see the actual speedup rather than assuming one. The prompt also requires graceful shutdown that drains in-flight work, lightweight metrics covering goroutine count, processing rate, and queue depth, race-detector cleanliness, and production notes on max-goroutine limits and deadlock prevention.
When to use it
- Building a Go service that processes large batches against a rate-limited external API
- Implementing a worker pool or pipeline with correct, drain-on-shutdown semantics
- Adding context-based cancellation and timeouts to existing concurrent work
- Getting backpressure right with buffered channels under sustained load
- Benchmarking concurrent versus sequential throughput before committing to a design
- Hardening concurrent code so it passes the race detector cleanly before shipping
Example output
You get a full, runnable main.go with comments explaining each decision: an ASCII goroutine-lifecycle diagram, the chosen pattern implemented with your primitives, context propagation throughout, errgroup error handling, and a graceful drain-on-shutdown path. It includes buffered-channel backpressure sized by [buffer_size], lightweight metrics, a benchmark comparing sequential and concurrent runs over your [benchmark_size] dataset, and production notes on goroutine limits, memory usage, and deadlock avoidance.
Pro tips
- Match
[pattern_name]to the real shape of your work; a pipeline and a worker pool solve genuinely different problems - Describe
[use_case]concretely, including any rate limits, so the implementation reflects your real constraints - Tune
[buffer_size]to your throughput; too large hides backpressure, too small starves the workers and stalls - Always run the result under the race detector before trusting it, even when the logic looks obviously correct
- Treat the graceful-drain path as non-negotiable; that is precisely where lost work and goroutine leaks hide
- Wire the metrics on goroutine count and queue depth so you can see backpressure building rather than guessing
- Set a sensible max-goroutine limit in production so a sudden burst of input cannot exhaust memory and crash the process
- Use a
[benchmark_size]close to your real volume so the reported speedup numbers actually mean something in practice
