copilot-bridge

Reconcile the bridge's model catalog with GitHub Copilot's live model list — add support for a new model, or remove support for a model Copilot retired. Use this whenever the user wants to add/support a new model (e.g. "add Sonnet 5", "support gpt-5.6", "Copilot shipped opus-5"), remove/drop a model ("opus-4.6-1m is gone from Copilot, delete it"), reconcile/sync/align the catalog with Copilot, or investigate why a model 400s. This repo hard-refuses to guess a model's wire shape, so every add/remove MUST be grounded in a live probe — do NOT edit ModelProfileCatalog.cs from family-name intuition. Follow this skill.

Verify a copilot-bridge change by driving the REAL headless client (codex.exe / claude.exe) through a running bridge and reading the CLIENT'S OWN evidence — the flywheel that turns "did the client actually execute?" into the thing that drives the next fix. Use this WHENEVER you touched bridge code that affects a client (tool protocol, Codex /responses T1–T4, Claude /cc, routing, streaming, detectors), are about to ship/PR a fix, or say things like "test through real codex/claude", "verify this fix end to end", "does the client actually run the tool", "did the exec/tool call work". A bridge HTTP 200 and a green unit test are NOT proof and must never be reported as one: codex records the "incompatible payload" tool-router fatal ONLY in its own logs_2.sqlite while the bridge stays 200. Run the client on a task that hits the code path you changed, then read the client's log — that is the verdict. Do NOT skip this by claiming it "needs the desktop app" or "can't be headless"; it can, and this skill is how.

Ship a finished change end-to-end: finalize its OpenSpec artifacts, open a PR, drive the GitHub Copilot review loop to zero open comments, then squash-merge and cut a beta release. Use this whenever the user says "ship it", "open a PR and get it reviewed", "run the PR loop", "let Copilot review then merge", "cut a beta", "bump a release", or otherwise wants the whole finish-a-branch dance — even if they only name one part (e.g. "just merge and release"). This encodes a GOLDEN PATH with hard-won guardrails: OpenSpec is archived BEFORE the PR so Copilot reviews the archived spec too, review-comment polling is done through an idempotent status script (never ad-hoc `gh` in a bare loop), and every review comment is resolved after reply so the open-count is the single source of truth.