protobuf
Skill17 starsChanged 6 months agoApache-2.0View on GitHub
Use when working with Protocol Buffer (.proto) files, buf.yaml, buf.gen.yaml, or buf.lock. Covers proto design, buf CLI, gRPC/Connect services, protovalidate constraints, schema evolution, and troubleshooting lint/breaking errors.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- malinskibeniamin/skillstheir own version, first seen Nov 1, 2026
- broomva/lagoword for word, first seen Apr 5, 2026
Other versions2 projects use a version of this.
Word for word · 1
- broomva/lago★ 2100% same
Edited · 0
None found.
Wrote their own version · 1
- malinskibeniamin/skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-browserSkill
- agentic-legibilitySkill
- babysit-prSkill
- better-result-adoptSkill
- code-breaking-changesSkill
- code-review-change-sizeSkill
- code-reviewSkill
- code-review-testingSkill
- drizzle-migration-conflict-resolutionSkill
- gh-pr-writingSkill
- knip-deadcodeSkill
- onequery-blog-imagesSkill
- onequery-bugSkill
- onequery-pr-bodySkill
- react-no-use-effectSkill
- tanstack-query-best-practicesSkill
- tanstack-router-best-practicesSkill
- xstateSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 30
Before writing proto code, review existing .proto files in the project.
- Distinctive: line 32
If none exists, ask the user what style should be used or an existing library to emulate.
- Distinctive: line 37
Add protovalidate constraints to every field—this is not optional for production APIs
- Very specific: line 48
Check for a Makefile first—many projects use make lint or make format.
- Very specific: line 80
Use assets/buf.yaml as starting point
- Very specific: line 81
Add buf.build/bufbuild/protovalidate as a dependency in buf.yaml and run buf dep update
- Very specific: line 82
Use assets/buf.gen.*.yaml for code generation config
- Distinctive: line 107
Use next sequential field number
- Distinctive: line 108
Add protovalidate constraints: every field should have validation appropriate to its type (format validators, length bounds, numeric …
- Very specific: line 119
Run buf breaking --against '.git#branch=main' to verify
- Distinctive: line 123
Every field in a production API should have appropriate validation.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Protocol Buffers
When You Need This Skill
- Creating or editing
.protofiles - Setting up
buf.yamlorbuf.gen.yaml - Designing gRPC or Connect services
- Adding protovalidate constraints
- Troubleshooting buf lint or breaking change errors
Core Workflow
1. Match Project Style
Before writing proto code, review existing .proto files in the project.
Match conventions for naming, field ordering, structural patterns, validation, and documentation style.
If none exists, ask the user what style should be used or an existing library to emulate.
2. Write Proto Code
- Apply universal best practices from best_practices.md
- Add protovalidate constraints to every field—this is not optional for production APIs
- For service templates, see assets/
3. Verify Changes
Always run after making changes:
buf format -w && buf lintCheck for a Makefile first—many projects use make lint or make format.
Fix all errors before considering the change complete.
Quick Reference
| Task | Reference |
| Field types, enums, oneofs, maps | quick_reference.md |
| Schema evolution, breaking changes | best_practices.md |
| Validation constraints | protovalidate.md |
| Complete service examples | examples.md, assets/ |
| buf CLI, buf.yaml, buf.gen.yaml | buf_toolchain.md |
| Migrating from protoc | migration.md |
| Lint errors, common issues | troubleshooting.md |
| Proto API review checklist | review_checklist.md |
Project Setup
New Project
- Create directory structure:
proto/ ├── buf.yaml ├── buf.gen.yaml └── company/ └── domain/ └── v1/ └── service.proto - Use
assets/buf.yamlas starting point - Add
buf.build/bufbuild/protovalidateas a dependency inbuf.yamland runbuf dep update - Use
assets/buf.gen.*.yamlfor code generation config
Code Generation Templates
| Template | Use For |
buf.gen.go.yaml | Go with gRPC |
buf.gen.go-connect.yaml | Go with Connect |
buf.gen.ts.yaml | TypeScript with Connect |
buf.gen.python.yaml | Python with gRPC |
buf.gen.java.yaml | Java with gRPC |
Proto File Templates
Located in assets/proto/example/v1/:
| Template | Description |
book.proto | Entity message, BookRef oneof, enum |
book_service.proto | Full CRUD with batch ops, pagination, ordering |
Common Tasks
Add a new field
- Use next sequential field number
- Add protovalidate constraints: every field should have validation appropriate to its type (format validators, length bounds, numeric ranges, enum constraints, etc.)
- Document the field
- Run
buf format -w && buf lint
Remove a field
- Reserve the field number AND name:
reserved 4; reserved "old_field_name"; - Run
buf breaking --against '.git#branch=main'to verify
Add protovalidate constraints
Every field in a production API should have appropriate validation. See protovalidate.md for the full reference.
Common constraints:
- String formats:
.string.uuid,.string.email,.string.uri,.string.pattern - String bounds:
.string.min_len,.string.max_len - Numeric bounds:
.int32.gte,.uint32.lte - Enum validation:
.enum.defined_only,.enum.not_in = 0 - Repeated bounds:
.repeated.min_items,.repeated.max_items - Required fields:
(buf.validate.field).required = true - Oneof required:
(buf.validate.oneof).required = true
Verification Checklist
After making changes:
- Every field has appropriate protovalidate constraints
buf format -w(apply formatting)buf lint(check style rules)buf breaking --against '.git#branch=main'(if modifying existing schemas)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

