helm-add-gwapi-route

helm-add-gwapi-route

Add or modernize Gateway API *Route resources inside a Helm chart. The skill only edits files — git operations (branch, commit, push, PR) are left to the caller.

When to invoke

Invoke proactively (without an explicit user command) when any of these hold:

• cwd is a Helm chart (Chart.yaml with apiVersion: v2) that has templates/ingress.yaml but no templates/*route.yaml — candidate for add-mode.
• cwd has templates/httproute.yaml / grpcroute.yaml / tlsroute.yaml declaring gateway.networking.k8s.io/v1beta1 or v1alpha2 for resources that are now GA at v1 — candidate for update-mode.
• cwd has *Route templates whose rules lack the name field (named rules are best practice since Gateway API v1.4).
• The user mentions migrating a chart from Ingress to Gateway API, adding HTTPRoute/GRPCRoute/TLSRoute support, "gwapi", or modernizing existing routes.

Do not invoke when:

• The chart already has current-spec routes with nothing to modernize.
• cwd is not a Helm chart (no Chart.yaml with apiVersion: v2).
• The scope is a standalone Kubernetes manifest, not a Helm chart.
• The user is working on an unrelated task — do not interrupt.

Arguments

Parse $ARGUMENTS:

• First positional = chart-path. Default: cwd.
• --type=<list> — comma-separated subset of httproute,grpcroute,tlsroute,tcproute,udproute, or auto (default). Controls which route kinds to add (add-mode) or update (update-mode).
• --mode=add|update|auto — default auto. See Phase 3.
• --with-backend-tls — also generate BackendTLSPolicy for the chart's Service (useful when the backend Service terminates TLS itself).

Phase 1 — Locate and validate the chart

1. Resolve chart-path. If not provided, walk upward from cwd looking for a directory that contains Chart.yaml. If multiple Chart.yaml files exist under charts/* (umbrella chart), ask the user via AskUserQuestion which chart to operate on; multi-select is allowed — process each selected chart independently.
2. Read Chart.yaml. Require apiVersion: v2. Capture chart name and version.
3. Inventory templates/:
   • note which of these exist: ingress.yaml, service.yaml, deployment.yaml, statefulset.yaml, _helpers.tpl
   • note which route templates already exist: httproute.yaml, grpcroute.yaml, tlsroute.yaml, tcproute.yaml, udproute.yaml, backendtlspolicy.yaml
4. Note whether tests/ exists (used in Phase 8 to decide whether to add helm-unittest tests).
5. Parse values.yaml:
   • extract the ingress: block — record its indent style (2 vs 4 spaces), field naming (host vs hostname, path vs paths, className style), whether helm-docs # -- description comments are used, and the values of any CORS/auth/rate-limit annotations (these are migration targets in update-mode)
   • extract the service: block — port number, port name, protocol, appProtocol, type
   • detect any existing httpRoute:, grpcRoute:, tlsRoute:, tcpRoute:, udpRoute: top-level blocks (flat style is canonical; if a chart already uses a nested gateway: block, preserve its structure in update-mode rather than flattening)
6. Read _helpers.tpl. Extract the exact helper template names the chart defines — typically <chart>.fullname, <chart>.labels, <chart>.selectorLabels, <chart>.serviceAccountName. Use the actual names in generated templates; do not assume the prefix matches the directory name.