proto-migration
Skill0 starsChanged 5 months agoMITView on GitHub
Fixes flow-frontend breakage after a proto bump — updates converters, server actions, and forms — distinguishing mechanical renames from semantic changes that must be escalated. Use when the user says "fix the proto breakage", "the buf bump broke types", "migrate after the proto change", "update converters for the new protos", or "/proto-migration". User-invoked only — it is the side-effecting post-bump companion to buf-bump, gated to match.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-server-actionSkill
- brainstormingSkill
- buf-bumpSkill
- e2e-test-fixtureSkill
- frontend-testingSkill
- new-componentSkill
- new-pageSkill
- receiving-code-reviewSkill
- systematic-debugSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
Surface the full breakage: Run pnpm lint:tsc. Capture every error — do not fix the first one and re-run blind.
- Distinctive: line 31
Semantic — STOP and escalate to the user: Do not invent a fix:
- Very specific: line 39
Fix mechanical changes at the edges: All proto↔form mapping lives in converters and server actions, never in components (the protobuf rule, …
- Distinctive: line 45
Add a canary for any workaround you couldn't avoid: If you had to special-case something, add a positive assertion (test or runtime guard) …
≈ “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
/proto-migration
The "fix the breakage" companion to buf-bump. After generated @bufteam/* packages change,
this restores the consuming code: rpcToForm* / formToRpc* converters, server actions, and
forms. The hard part is judgment — telling a mechanical rename (safe to apply) from a semantic
change (must be escalated). Applying a default or null-check to paper over a removed field hides
lost data; that is the silent-failure trap this skill exists to prevent.
Runs in flow-frontend, after a bump has already landed (via buf-bump). If the protos
aren't bumped yet, use buf-bump first.
Steps
- Surface the full breakage. Run
pnpm lint:tsc. Capture every error — do not fix the first one and re-run blind. The error set is the migration's scope. Triage each error into one of two buckets:
Mechanical — apply directly:
- Field renamed → update the field name in the converter and any direct proto usage.
- Type widened, or a new optional field added → adjust the converter; default the new field only if the proto marks it optional and the form has a sensible empty value.
- Enum value renamed (same meaning) → update the mapping.
Semantic — STOP and escalate to the user. Do not invent a fix:
- A field was removed — this is a backend contract change. A removed field means the data is gone; a null-check hides that. Report it.
- An enum value was dropped — a previously valid state no longer exists; the UI handling it needs a product decision.
- A field's meaning or units changed, or required↔optional flipped — semantics, not syntax. Escalate.
- Fix mechanical changes at the edges. All proto↔form mapping lives in converters and
server actions, never in components (the
protobufrule, installed at.claude/rules/protobuf.md;/add-server-action). Use*Requiredtypes fromhadrian_protoc-gen-es-requiredfor form validation. Re-check int64-as-string, RFC 3339 timestamp, and proto3-default handling — a bump can change which of these applies to a field. - Add a canary for any workaround you couldn't avoid. If you had to special-case something, add a positive assertion (test or runtime guard) that fails loudly when the contract shifts again — so the next bump can't silently re-break it. Mark load-bearing workarounds with a comment explaining why.
- Verify.
pnpm lint:tscclean, thenpnpm test. Update converter and form tests so they assert the new field shape through the real path, not the old one. - Report. List what you fixed mechanically, every semantic change you escalated (these block until the user decides), and any canary you added.
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.

