---
name: review-envoy-gateway-pr
description: Review an Envoy Gateway pull request for essential API, implementation, status, and test coverage requirements.
metadata:
  short-description: Envoy Gateway PR review workflow
  version: "0.1"
---

# 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.