What this prompt does
This prompt creates a Go gRPC microservice around a service domain rather than a bare proto file. You set [service_domain] and the AI produces proto3 definitions (service, messages, and enums), a buf.yaml for proto management and breaking-change detection, and a server implementation with the [server_features] you specify. The interceptor stack covering logging, auth, recovery, validation, and metrics, together with a circuit-breaking client, is what keeps one slow dependency from cascading delays across the entire mesh.
The variables shape the runtime and the deployment. [server_features] defines the RPC styles such as unary, server streaming, and deadlines, [k8s_features] drives the Kubernetes manifest with liveness and readiness probes, HPA, and service-mesh readiness, and [go_version] pins the toolchain so generated code stays consistent. The prompt also includes a pooled, retrying client with a circuit breaker, server reflection for grpcurl debugging, the gRPC health-checking protocol, a gRPC-Gateway for REST compatibility so browsers are not locked out, bufconn integration tests, and a Makefile with proto-generation targets.
When to use it
- Building services that need a strict contract and low-latency communication between them
- Standing up gRPC with a full interceptor stack rather than bare, unguarded handlers
- Adding a circuit-breaking, connection-pooled client to prevent cascading failures
- Exposing a REST surface via gRPC-Gateway for browsers and REST-only clients
- Wiring health checks and Kubernetes probes for a real production deployment
- Generating in-process bufconn integration tests alongside the service implementation
Example output
You get proto3 service and message definitions, a buf.yaml with breaking-change detection, and a Go server implementing the requested RPC styles with the full interceptor stack. It includes a resilient client with pooling, retries, and a circuit breaker, server reflection for debugging, health checking, a gRPC-Gateway for REST, bufconn integration tests, a Kubernetes deployment with the chosen [k8s_features], and a Makefile covering proto generation, build, test, and lint targets. The gRPC-Gateway exposes the same RPCs as REST endpoints, so browser and REST-only clients can reach the service without ever speaking gRPC directly.
Pro tips
- Define
[service_domain]precisely; the proto messages and RPCs are only as good as the domain description you give - Choose
[server_features]deliberately; server streaming and deadlines change both the proto and the handler design - Keep the gRPC-Gateway even for internal services so browsers and REST tools are not locked out of the API
- Pin
[go_version]to match your CI so generated code and the toolchain stay consistent across machines - Tune the circuit-breaker thresholds in the client; the defaults rarely match your real latency profile
- Implement the health-checking protocol properly so Kubernetes liveness and readiness probes route traffic only to healthy pods
- Run buf breaking-change detection in CI so proto changes never silently break downstream consumers of the service
