home / skills / bufbuild / claude-plugins / protobuf

This skill helps you design, validate, and troubleshoot Protocol Buffer schemas and buf tooling for robust gRPC and Connect services.

npx playbooks add skill bufbuild/claude-plugins --skill protobuf

Review the files below or copy the command above to add this skill to your agents.

Files (21)
SKILL.md
4.5 KB
---
name: protobuf
description: >-
  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.
filePatterns:
  - "**/*.proto"
  - "**/buf.yaml"
  - "**/buf.*.yaml"
  - "**/buf.gen.yaml"
  - "**/buf.gen.*.yaml"
  - "**/buf.lock"
---

# 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](references/best_practices.md)
- Add [protovalidate](references/protovalidate.md) constraints to every field—this is not optional for production APIs
- For service templates, see [assets/](assets/)

### 3. Verify Changes

**Always run after making changes:**

```bash
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

| Task | Reference |
|------|-----------|
| Field types, enums, oneofs, maps | [quick_reference.md](references/quick_reference.md) |
| Schema evolution, breaking changes | [best_practices.md](references/best_practices.md) |
| Validation constraints | [protovalidate.md](references/protovalidate.md) |
| Complete service examples | [examples.md](references/examples.md), [assets/](assets/) |
| buf CLI, buf.yaml, buf.gen.yaml | [buf_toolchain.md](references/buf_toolchain.md) |
| Migrating from protoc | [migration.md](references/migration.md) |
| Lint errors, common issues | [troubleshooting.md](references/troubleshooting.md) |
| Proto API review checklist | [review_checklist.md](references/review_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

| 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

1. Use next sequential field number
2. Add [protovalidate](references/protovalidate.md) 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:
   ```protobuf
   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](references/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)

Overview

This skill helps engineers design, edit, and validate Protocol Buffer schemas and Buf configuration files for production APIs. It covers .proto authoring, protovalidate constraints, buf CLI workflows, code generation templates, and troubleshooting lint or breaking-change errors. Use it to enforce consistent schema style, safe schema evolution, and reliable codegen across languages.

How this skill works

I inspect existing .proto files and Buf configs to match project conventions, then propose or modify proto definitions with required protovalidate constraints. I recommend and generate buf.yaml and buf.gen.yaml snippets for your target languages and toolchains, and I validate changes with the recommended Buf commands (format, lint, breaking). When issues appear, I diagnose lint and breaking errors and suggest minimal, safe fixes.

When to use it

  • Creating or editing .proto files for gRPC or Connect services
  • Adding protovalidate constraints to ensure production-safe inputs
  • Setting up or updating buf.yaml, buf.gen.yaml, or buf.lock for code generation
  • Verifying schema evolution and preventing breaking changes before merge
  • Troubleshooting buf lint or buf breaking errors reported in CI

Best practices

  • Match existing project style for naming, field ordering, and docs before adding new proto files
  • Add protovalidate constraints to every field (format, bounds, required) for production APIs
  • Use next sequential field numbers; reserve numbers/names when removing fields
  • Always run buf format -w && buf lint after edits; use make lint/format if provided
  • Run buf breaking --against '.git#branch=main' when modifying existing schemas

Example use cases

  • Add a new optional email field with .string.email and max length validation to a User proto
  • Create buf.gen.*.yaml config to generate Go gRPC and TypeScript Connect clients simultaneously
  • Migrate a legacy protoc-based project to Buf with buf.yaml and dependency protovalidate
  • Resolve a buf lint error by fixing a naming violation and applying buf format
  • Verify a refactor won’t break clients by running buf breaking against main

FAQ

What protovalidate rules should I add to every field?

Add type-appropriate constraints: format validators for strings (uuid, email, uri), min/max lengths, numeric ranges, enum defined_only, and mark required fields with (buf.validate.field).required = true.

How do I safely remove a field?

Reserve the field number and name using reserved, update consumers, and run buf breaking --against '.git#branch=main' to confirm no breaking changes.