eg-contrib-translate

Translate Gateway CRD features into IR and Envoy xDS configurations.

3|Updated Mar 8, 2026
One-click install
npx skills add https://github.com/missBerg/envoy-skills --skill eg-contrib-translate
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eg-contrib-translate
Source: https://github.com/missBerg/envoy-skills/tree/main/gateway/contributors/skills/eg-contrib-translate
Command: npx skills add https://github.com/missBerg/envoy-skills --skill eg-contrib-translate

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Step-by-step guide to implement Gateway API to IR and IR to xDS translation for a new feature in envoyproxy/gateway.

Core Features & Use Cases

  • Structured workflow to add IR types, implement translation logic, run golden tests, and wire xDS translation for a new feature.
  • Provides guidance on maintaining deterministic IR (prefer slices over maps) and phase-based testing.
  • Real-world scenario: a contributor adds a new CRD-driven feature translation pipeline from gateway API to IR to xDS.

Quick Start

Follow the phased approach in this guide to implement a translation for a new Gateway feature from CRD to IR to xDS.

Frequently Asked Questions about eg-contrib-translate

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement Gateway API to Envoy xDS translation for a new CRD feature?

Gateway API to Envoy xDS translation requires translating a CRD-driven feature into an intermediate representation (IR), adding translation logic, and wiring it to xDS configurations across a phased workflow.

Why should IR definitions prefer slices over maps for Envoy xDS translation?

IR definitions must prefer slices over maps to maintain deterministic output during Gateway API translation, ensuring consistent Envoy xDS configuration generation and reliable golden testing.

How do I add translation logic and tests for a new Gateway API policy type?

Adding translation logic for a new Gateway API policy type requires defining IR types, wiring translation functions, running phase-based golden tests, and maintaining status conditions for invalid configurations.

What is the phased workflow for adding Gateway API to IR to xDS translation pipelines?

The phased workflow covers adding IR types, implementing translation logic, running golden tests, and wiring xDS translation, structured across Phase 1-5 to ensure complete feature implementation.

How do I handle invalid configurations when translating Gateway API CRDs to Envoy xDS?

Handling invalid configurations during Gateway API translation requires maintaining status conditions on the CRD, ensuring errors are captured and reported back during the IR to xDS pipeline execution.

Can I use this Gateway API translation workflow for any new CRD-driven feature in Envoy?

Yes, this workflow applies to developers implementing any new CRD-driven feature by adding IR types, translation logic, tests, and xDS wiring within the envoyproxy/gateway project.