# Review Envoy Gateway Pr

> Review an Envoy Gateway pull request for essential API, implementation, status, and test coverage requirements.

- Skill: `envoyproxy/review-envoy-gateway-pr` (Agent Skill)
- Install (CLI): `npx skillmds@latest add envoyproxy/review-envoy-gateway-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/envoyproxy/review-envoy-gateway-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: envoyproxy (https://skillmd.com/u/envoyproxy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/envoyproxy/review-envoy-gateway-pr

---


# Envoy Gateway PR Review Skill

## Inputs
- GitHub PR URL (e.g. review PR: https://github.com/envoyproxy/gateway/pull/8237), or
- A local diff between commits (e.g. review change: git diff 4927877a HEAD)

## Output
- Lead with findings ordered by severity.
- Include exact file and line references.
- Separate required fixes from optional follow-ups.
- If there are no findings, say that clearly and mention residual test or release-note risk.

## Review
- Check API changes, implementation changes, feature coverage, and release notes as applicable.
- Keep findings concise and actionable, with file references when possible.

## Checklist

### API changes
- Make sure changes under `api/` align with https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
- Make sure changes under `api/` are consistent with existing API patterns in the Gateway API project: https://github.com/kubernetes-sigs/gateway-api/tree/main/apis
- Make sure changes under `api/` are consistent with existing API patterns in this project.
- Try to reuse existing types.
- Keep naming consistent with this project.
- Try to add kubebuilder and CEL validations to catch errors.
- Make sure API validations are tested in `/test/cel-validation`.
- Check backward compatibility for API shape, CRD schema, defaults, versioned structs, and upgrade behavior.
- If a PR mixes API and implementation changes, say whether it should be split into separate PRs.

### Implementation changes
- For changes under `internal/gatewayapi`, check that user-visible errors are surfaced in status.
- For changes under `internal/gatewayapi`, check that status conditions follow the conventions in the Gateway API spec: https://gateway-api.sigs.k8s.io/geps/gep-1364/index.html
- For changes under `internal/gatewayapi`, check that `internal/gatewayapi/testdata` has coverage.
- For changes under `internal/xds/translator`, check that `internal/xds/translator/testdata` has coverage.

### Feature coverage
- For new user-facing features, check that `test/e2e` has coverage.
- For bug fixes, check that `test/e2e` has coverage if the bug is in user-facing code or has user-facing impact.

### Release notes
Release notes should be added as a new fragment file under `release-notes/current/<section>/<pr-number>-<slug>.md` (see `release-notes/current/README.md`) for any of the following changes. One change per file; the section directory determines the category.
- Bug fixes should be noted as "bug fix" (`bug_fixes/`) and include a brief description of the issue and the fix.
- New features should be noted as "new feature" and include a brief description of the feature.
- Any breaking changes should be noted as "breaking change" and include a clear description of the change and its impact on users.
- Any change to generated Envoy config (xDS) that moves, removes, or modifies existing config content would break EnvoyPatchPolicies and Extension Servers, so it should be noted as a breaking change. Additions to generated xDS config do not need to be called out.
- Existing API changes should be noted.
- Existing behavior changes should be noted.