agentleFS
wordbrickswordbricks/onequery/.agents/skills/protobuf/SKILL.md

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

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
  1. Very specific:

    Before writing proto code, review existing .proto files in the project.

    line 30
  2. Distinctive:

    If none exists, ask the user what style should be used or an existing library to emulate.

    line 32
  3. Distinctive:

    Add protovalidate constraints to every field—this is not optional for production APIs

    line 37
  4. Very specific:

    Check for a Makefile first—many projects use make lint or make format.

    line 48
  5. Very specific:

    Use assets/buf.yaml as starting point

    line 80
  6. Very specific:

    Add buf.build/bufbuild/protovalidate as a dependency in buf.yaml and run buf dep update

    line 81
  7. Very specific:

    Use assets/buf.gen.*.yaml for code generation config

    line 82
  8. Distinctive:

    Use next sequential field number

    line 107
  9. Distinctive:

    Add protovalidate constraints: every field should have validation appropriate to its type (format validators, length bounds, numeric …

    line 108
  10. Very specific:

    Run buf breaking --against '.git#branch=main' to verify

    line 119
  11. Distinctive:

    Every field in a production API should have appropriate validation.

    line 123

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Protocol Buffers

When You Need This Skill

  • Creating or editing .proto files
  • Setting up buf.yaml or buf.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 lint

Check for a Makefile first—many projects use make lint or make format.

Fix all errors before considering the change complete.

Quick Reference

TaskReference
Field types, enums, oneofs, mapsquick_reference.md
Schema evolution, breaking changesbest_practices.md
Validation constraintsprotovalidate.md
Complete service examplesexamples.md, assets/
buf CLI, buf.yaml, buf.gen.yamlbuf_toolchain.md
Migrating from protocmigration.md
Lint errors, common issuestroubleshooting.md
Proto API review checklistreview_checklist.md

Project Setup

New Project

  1. Create directory structure:
    proto/
    ├── buf.yaml
    ├── buf.gen.yaml
    └── company/
        └── domain/
            └── v1/
                └── service.proto
  2. Use assets/buf.yaml as starting point
  3. Add buf.build/bufbuild/protovalidate as a dependency in buf.yaml and run buf dep update
  4. Use assets/buf.gen.*.yaml for code generation config

Code Generation Templates

TemplateUse For
buf.gen.go.yamlGo with gRPC
buf.gen.go-connect.yamlGo with Connect
buf.gen.ts.yamlTypeScript with Connect
buf.gen.python.yamlPython with gRPC
buf.gen.java.yamlJava with gRPC

Proto File Templates

Located in assets/proto/example/v1/:

TemplateDescription
book.protoEntity message, BookRef oneof, enum
book_service.protoFull CRUD with batch ops, pagination, ordering

Common Tasks

Add a new field

  1. Use next sequential field number
  2. Add protovalidate constraints: every field should have validation appropriate to its type (format validators, length bounds, numeric ranges, enum constraints, etc.)
  3. Document the field
  4. Run buf format -w && buf lint

Remove a field

  1. Reserve the field number AND name:
    reserved 4;
    reserved "old_field_name";
  2. 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)

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.