Add Copilot PR check to gateway controllers repo to validate polcies

Description

A similar skill should be added to github instruction md and integrate Copilot reviews on PR checks

---
name: apiplatform-policy-review
description: Perform end-to-end API Platform gateway policy reviews by validating policy-definition.yaml against runtime behavior, parameter naming quality, required/optional/default correctness, schema-runtime drift, and test impact. Use when auditing a policy, reviewing rename proposals, checking integration-test failures caused by validation changes, or preparing action-oriented policy review notes.
---

API Platform Policy Review

Overview

Review a policy as a contract: schema, runtime parsing/validation, and observed behavior must align. Produce concrete, action-oriented findings with precise parameter paths and code references.

Review Scope

Cover these areas unless the user narrows scope:

• Parameter naming quality
• Schema/runtime type and shape alignment
• Required/optional/default correctness
• Request vs response phase semantics
• Validation strictness and integration-test impact
• Migration and compatibility risk for proposed changes

Workflow

1. Read contract first.

• Read policies/<policy>/policy-definition.yaml.
• Identify user parameters vs system parameters.
• Capture required fields, defaults, conditionals (anyOf/allOf/if-then), and additionalProperties behavior.

2. Read runtime behavior.

• Read policy implementation (*.go) focusing on GetPolicy, parsing helpers, and OnRequest/OnResponse.
• Record exact keys runtime reads and how it handles missing/invalid values.
• Verify whether policy is request-only, response-only, or dual-flow.

3. Compare schema vs runtime.

• Flag mismatches in accepted types, requiredness, defaults, and conditional behavior.
• Flag cases where schema allows config that runtime rejects (or vice versa).
• Flag cases where docs/comments imply behavior not implemented.

4. Assess naming quality.

• Prefer explicit names over overloaded/generic keys.
• Ensure numeric params carry unit semantics when needed.
• Ensure booleans read as toggles (useX, enableX, allowX).
• Ensure identity vs display fields are clearly separated.

5. Evaluate change impact.

• Determine if proposed rename/refactor is breaking.
• Recommend alias/transitional handling only when needed.
• Note integration-test updates required by stricter validation.

6. Produce review output.

• Findings first, most severe first.
• Include exact file path + parameter path + runtime evidence.
• Keep recommendations actionable and minimal.

Naming Rules

• Use names that reflect actual runtime semantics, not aspirational schema wording.
• Include units where values are unit-bound (*Seconds, *Millis, *Bytes, *Words, *Sentences).
• Avoid ambiguous keys (name, key, target) when meaning varies by capability/type.
• Use capability-specific names when one field currently carries multiple semantics.
• Use request.* / response.* structure only when phase intent is real in behavior.

Schema Best Practices

• Keep schema and runtime accepted shapes aligned.
• Do not rely on schema defaults that runtime ignores.
• Requiredness must match runtime assumptions.
• Conditional rules must be scoped correctly (for example, avoid if conditions that match when a field is absent).
• Keep rejection behavior predictable across validation layers.

Output Formats

When producing rename sheets (CSV/Markdown):

• Every row must be standalone.
• Avoid "Same as above".
• Reason should state:
  • what is ambiguous today
  • what the new name makes explicit

When producing findings:

• Include severity, parameter path, evidence, and action.
• Prefer short, direct findings over long narrative.

Final Checks

Before finishing:

• Verify every recommendation is backed by code behavior.
• Verify parameter paths exist in current schema.
• Verify proposed text does not imply unsupported runtime behavior.
• If both CSV and Markdown summaries are updated, ensure wording is aligned.

Locate the GitHub instruction markdown and the repository's existing pull-request checks, then compare their conventions with the proposed apiplatform-policy-review skill. Read the referenced policies//policy-definition.yaml and *.go policy implementations to understand the review scope. Done means the instruction is available and Copilot review validation runs on pull requests.