arbazkhan971/godmode/skills/grpc/SKILL.md
grpc
gRPC and Protocol Buffers skill. Proto design, code generation, streaming patterns, gRPC-web, load balancing, service mesh integration. Triggers on: /godmode:grpc, "gRPC service", "proto file", "streaming RPC", "gRPC-web".
- Source repository stars
- 26
- Declared platforms
- 0
- Static risk flags
- 1
- Last source update
- 2026-08-28
- Source checked
- 2026-08-28
Decision brief
What it does: where it fits
gRPC and Protocol Buffers skill. Proto design, code generation, streaming patterns, gRPC-web, load balancing, service mesh integration.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/arbazkhan971/godmode --skill "skills/grpc"Inspect the Agent Skill "grpc" from https://github.com/arbazkhan971/godmode/blob/18bfc31d669804856ba232f04cdbd172afbdc379/skills/grpc/SKILL.md at commit 18bfc31d669804856ba232f04cdbd172afbdc379. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Workflow
Review the “Workflow” section in the pinned source before continuing.
Review and apply the “Workflow” source section. - 02
Step 1: Discovery & Context
Review the “Step 1: Discovery & Context” section in the pinned source before continuing.
Review and apply the “Step 1: Discovery & Context” source section. - 03
Step 2: Proto File Design
Review the “Step 2: Proto File Design” section in the pinned source before continuing.
Review and apply the “Step 2: Proto File Design” source section. - 04
Step 3: Code Generation Pipeline
Review the “Step 3: Code Generation Pipeline” section in the pinned source before continuing.
Review and apply the “Step 3: Code Generation Pipeline” source section. - 05
Step 4: Streaming Patterns
Review the “Step 4: Streaming Patterns” section in the pinned source before continuing.
Review and apply the “Step 4: Streaming Patterns” source section.
Permission review
Static risk signals and limitations
Runs scripts
The documentation asks the agent to run terminal commands or scripts.
go.mod Cargo.toml package.json pyproject.toml \Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 92/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 26 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- arbazkhan971/godmode
- Skill path
- skills/grpc/SKILL.md
- Commit
- 18bfc31d669804856ba232f04cdbd172afbdc379
- License
- MIT
- Collected
- 2026-08-28
- Default branch
- master
View the original SKILL.md
gRPC — Protocol Buffers & Service Development
Activate When
- User invokes
/godmode:grpc - User says "build a gRPC service", "design proto"
- User says "add streaming", "bidirectional stream"
- User says "set up gRPC-web"
- Plan identifies gRPC or inter-service communication
Workflow
Step 1: Discovery & Context
# Detect existing proto files and tools
find . -name "*.proto" -not -path "*/node_modules/*" \
2>/dev/null | head -20
# Check for buf configuration
ls buf.yaml buf.gen.yaml 2>/dev/null
# Check gRPC dependencies
grep -r "grpc\|tonic\|grpc-go\|grpcio" \
go.mod Cargo.toml package.json pyproject.toml \
2>/dev/null
GRPC DISCOVERY:
Language: <Go|Rust|Java|Python|TypeScript>
Framework: <tonic|grpc-go|grpc-java|grpc-node>
Proto version: proto3
Consumers: <internal|mobile|browser via gRPC-web>
Patterns: <unary|server-stream|client-stream|bidi>
IF no buf.yaml: create one (not raw protoc)
IF no protos: scaffold from API requirements
IF browser clients: add gRPC-web or Connect
Step 2: Proto File Design
service <Entity>Service {
rpc Get<Entity>(Get<Entity>Request)
returns (<Entity>) {}
rpc List<Entities>(List<Entities>Request)
returns (List<Entities>Response) {}
rpc Create<Entity>(Create<Entity>Request)
returns (<Entity>) {}
rpc Watch<Entities>(Watch<Entities>Request)
returns (stream <Entity>Event) {}
}
PROTO RULES:
1. proto3 syntax always
2. Package = company.domain.v1
3. Enum zero value = UNSPECIFIED
4. Field numbers are permanent — never reuse
5. FieldMask for partial updates
6. Request/Response per RPC (never share)
7. Idempotency key on create/update
8. google.protobuf.Timestamp for time
9. Reserve removed field numbers/names
10. Keep messages < 100 fields
FILE LAYOUT:
protos/<company>/<domain>/v1/
<service>.proto, resources.proto,
enums.proto, events.proto
Step 3: Code Generation Pipeline
# Lint protos
buf lint
# Check for breaking changes
buf breaking --against '.git#branch=main'
# Generate code
buf generate
GENERATION RULES:
Generated code NEVER committed — regen in CI
Pin plugin versions in buf.gen.yaml
Run buf lint before generation
Run buf breaking before merge
Generate for ALL consumer languages in one pass
THRESHOLDS:
buf lint errors: must be 0
buf breaking regressions: must be 0
IF breaking change needed: add new field,
reserve old — never modify existing
Step 4: Streaming Patterns
| Pattern | Use Case |
|--------------|------------------------------|
| Unary | CRUD operations |
| Server stream| Feeds, watches, large data |
| Client stream| Batch uploads, aggregation |
| Bidirectional| Chat, collaboration, sync |
BEST PRACTICES:
Set deadlines on all RPCs (prevent hung conns)
Implement keepalive pings (detect dead conns)
Use flow control / backpressure (prevent OOM)
Send heartbeats on long-lived streams
Implement reconnection with resume token
THRESHOLDS:
Unary deadline: 5s default, 30s max
Stream keepalive: every 30s
Backpressure buffer: 1000 messages max
IF stream idle > 60s without heartbeat: close
Step 5: gRPC-Web for Browsers
OPTIONS:
Envoy Proxy: production, no code changes
Buf Connect: no proxy, full streaming, recommended
grpc-web npm: simple, limited streaming
LIMITATIONS:
No client or bidi streaming in browsers (HTTP/1.1)
Server streaming via chunked transfer
CORS required for cross-origin
Step 6: Load Balancing
CHALLENGE: HTTP/2 long-lived connections mean L4 LBs
route all RPCs to one backend.
SOLUTION: L7 load balancing per individual RPC.
STRATEGIES:
1. Proxy L7 (recommended): Envoy/Nginx/Traefik
2. Client-side: built into grpc-go, grpc-java
3. xDS / service mesh: Istio, Linkerd, Consul
HEALTH CHECK:
Implement grpc.health.v1.Health on every server
IF no health check: load balancer can't route
Step 7: Error Handling & Observability
STATUS CODES (use correctly):
OK, CANCELLED, INVALID_ARGUMENT, NOT_FOUND,
ALREADY_EXISTS, PERMISSION_DENIED,
UNAUTHENTICATED, RESOURCE_EXHAUSTED,
UNAVAILABLE, DEADLINE_EXCEEDED, INTERNAL
INTERCEPTOR CHAIN (in order):
Recovery → Logging → Metrics → Tracing → Auth
METRICS:
grpc_server_handled_total{method,code}
grpc_server_handling_seconds{method}
Step 8: Testing
TEST LAYERS:
Proto: buf lint + buf breaking
Unit: mocked dependencies
Integration: grpcurl / Evans against real server
Streaming: 0 msgs, 1 msg, many, cancel, error
Load: ghz benchmark tool
Contract: buf breaking before merge
STREAMING EDGE CASES:
Cancel mid-stream, error mid-stream,
connection drop, concurrent send/receive,
deadlock detection for bidi streams
Step 9: Completion
GRPC COMPLETE:
Services: <N>, RPCs: <N> unary / <M> streaming
buf lint: PASS, buf breaking: PASS
Health check: implemented
TLS: <mTLS|server-only|plaintext>
Commit: `"grpc: — RPCs, streaming
- health checks configured"`
Key Behaviors
Never ask to continue. Loop autonomously until done.
- Proto files are the contract. Design first.
- Use buf, not raw protoc.
- Every enum starts with UNSPECIFIED = 0.
- Field numbers are permanent. Never reuse.
- Request/Response per RPC. Never share.
- L7 load balancing is mandatory.
- Health checks on every server.
HARD RULES
- Always use proto3 syntax for new services.
- Every enum MUST start with UNSPECIFIED = 0.
- Never reuse field numbers. Reserve removed ones.
- Never share request/response across RPCs.
- Always use buf (not raw protoc).
- Never commit generated code. Generate in CI.
- Always use L7 load balancing for gRPC.
- Always implement grpc.health.v1.Health.
- Always set deadlines on all RPCs.
- Always use correct status codes.
Auto-Detection
1. Proto files: find . -name "*.proto"
2. Language: go.mod, Cargo.toml, package.json
3. Buf config: buf.yaml, buf.gen.yaml
4. Health check: grep grpc.health in source
5. Streaming: grep stream in .proto files
Quality Targets
- Target: <50ms p95 unary RPC latency
- Max message size: <4MB default
- Target: >99.9% RPC success rate
- Connection pool: >=2 channels per backend
Output Format
gRPC: {N} services, {M} RPCs (unary/streaming).
buf lint: {status}. Health: {status}.
LB: {strategy}. TLS: {type}.
TSV Logging
timestamp project services rpcs streaming_rpcs buf_lint breaking commit_sha
Keep/Discard Discipline
KEEP if: buf lint PASS AND buf breaking PASS
AND health check present
DISCARD if: lint error OR breaking change
OR missing health check
Stop Conditions
STOP when: buf lint 0 errors AND breaking 0
AND health check implemented AND all RPCs
have deadlines and per-RPC messages
OR user requests stop OR max 10 iterations
Error Recovery
- Proto compile fails: fix syntax, imports, types.
- buf lint errors: fix naming, structure per rules.
- Breaking change: add new fields, reserve old.
- Streaming hangs: check deadlines, keepalive config.
- UNAVAILABLE: verify address, TLS, health check.
- Stale stubs: re-run buf generate.
Frequently asked questions
What to verify before installation and use
What does the grpc source document cover?
gRPC and Protocol Buffers skill. Proto design, code generation, streaming patterns, gRPC-web, load balancing, service mesh integration.
How do I install grpc?
The source record exposes this install command: npx skills add https://github.com/arbazkhan971/godmode --skill "skills/grpc". Inspect the command and pinned source before running it.
Which permission-related actions were detected?
Static rules flagged exec-script in the source; the page lists the matching lines and excerpts.
Alternatives
Compare before choosing
vasilyu1983/AI-Agents-public
qa-testing-ios
Guides iOS testing with XCTest, XCUITest, Swift Testing, simctl, and xcresult. Use when choosing destinations, controlling flakes, or parsing test artifacts for native apps.
dotnet/skills
writing-mstest-tests
Fix, modernize, review, or explain supplied MSTest code and MSTest-specific configuration while honoring installed versions and project style. ALWAYS USE for direct corrections: expected/actual order; generic/manual assertions; exception, hard-cast, or object[] patterns; TestContext/lifecycle; timeout/cancellation; condition/retry/cleanup; parallelization; MSTest.Sdk setup; or MSTESTxxxx. Use for "review" only when corrected code or edits are wanted. DO NOT USE for new test-case design (code-tes
yonatangross/orchestkit
verify
Grade work that already exists and decide whether it can merge. Runs the project's current unit, integration, and E2E suites plus security scanning and type checking, scores every dimension 0-10, and returns a merge verdict with a VERIFIED-vs-CLAIMED evidence manifest. Writes no test files and edits no source. Use when verifying changes are ready to merge. Use /ork:cover instead when the tests still have to be written.
microsoft/Sico
android-tester
Execute Android UI workflows on a sandbox device, review results, and produce a structured execution report.