What this prompt does
This prompt instructs the model to act as a senior Go engineer and build a real, buildable microservice that exposes both gRPC and REST through Connect-go. You fill in [service], the [rpcs] you want, the [datastore], and your [module_path], and it returns proto definitions, buf.yaml / buf.gen.yaml, a wired service implementation, interceptors, OpenTelemetry tracing, a multi-stage Dockerfile, and a docker-compose for local dev.
The structure works because it forces concrete deliverables instead of advice. [rpcs] drives both the proto schema and the generated Connect handlers, so one definition serves internal gRPC callers and a plain REST surface for the frontend. [datastore] shapes the service implementation and the compose file, and [module_path] anchors the file tree and import paths so the output drops cleanly into a repo. Because the prompt demands buildable code rather than pseudocode, the model has to commit to real types, real error mapping to Connect codes, and a generation config that actually runs.
When to use it
- You're adding a new Go service to a system and want gRPC and REST from a single definition.
- You need a hot path that's fast and boring, with tracing and auth baked in from the start.
- You want buf-based codegen scaffolding without hand-wiring
buf.gen.yamlyourself. - You're standing up a service plus its datastore for local dev via docker-compose.
- You want auth and structured logging interceptors in place before handlers multiply.
- You need OpenTelemetry spans crossing the RPC boundary and into DB calls.
- You want a reproducible local stack you can hand to a teammate to run with one command.
Example output
Expect the full file tree under your [module_path] first, then the key files: the .proto for your [rpcs], the buf config, the server implementation against [datastore], the auth and logging interceptors, the multi-stage Dockerfile, and the compose file. The implementation maps datastore and validation failures to appropriate Connect error codes rather than leaking raw errors. It closes with a curl example hitting REST and a grpcurl example hitting gRPC, so you can verify both surfaces immediately.
Pro tips
- Name
[rpcs]precisely (e.g.CreateUser, GetUser, ListUsers) — they become both proto methods and Connect handlers, so vague names produce vague schemas. - Get interceptors in early. Bolting auth and tracing onto
[rpcs]later means touching every handler. - Set
[datastore]to what you'll actually run; it drives the compose service and the error mapping to Connect codes. - Use a real
[module_path]matching your VCS host so generated imports and the file tree are correct on first paste. - If the model returns pseudocode, push back and ask it to make
buf generatesucceed — the prompt's whole point is buildable output. - Ask for the curl and grpcurl examples to be runnable against the compose stack so you can smoke-test both protocols.
