agentleFS
mark2685mark2685/agent-tools/skills/flow-frontend/proto-migration/SKILL.md

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.

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

    Surface the full breakage: Run pnpm lint:tsc. Capture every error — do not fix the first one and re-run blind.

    line 20
  2. Distinctive:

    Semantic — STOP and escalate to the user: Do not invent a fix:

    line 31
  3. Very specific:

    Fix mechanical changes at the edges: All proto↔form mapping lives in converters and server actions, never in components (the protobuf rule, …

    line 39
  4. Distinctive:

    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) …

    line 45

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

/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

  1. 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.
  2. 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.
  3. Fix mechanical changes at the edges. All proto↔form mapping lives in converters and server actions, never in components (the protobuf rule, installed at .claude/rules/protobuf.md; /add-server-action). Use *Required types from hadrian_protoc-gen-es-required for 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.
  4. 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.
  5. Verify. pnpm lint:tsc clean, then pnpm test. Update converter and form tests so they assert the new field shape through the real path, not the old one.
  6. Report. List what you fixed mechanically, every semantic change you escalated (these block until the user decides), and any canary you added.

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.