feat: GHA, OpenShift deploy skills and modify azure networking skill (#10)

* feat: GHA skills and modify azure networking skill

* chore: add more runners to the list

* feat: add openshift-deployment skill

* fix: hpa, pdb

* fix: skills

Author: mishraomp

.github/skills/skill-author/SKILL.md

@@ -27,6 +27,7 @@ description: Scaffolds a new skill profile in this repo and fills in the require
 - Always set the new skill's starting `version` to `0.1.0` in `package.json`, never in the `SKILL.md` frontmatter. (Why: version lives only in package.json to avoid drift between two sources of truth.)
 - Always keep the package `name` scoped as `@bcgov/skill-<skill-name>` matching the folder. (Why: the publish workflow derives the npm package identity from this and consumers install by it.)
 - Never invent a new section order or rename a section. (Why: the validator matches the seven section titles exactly and the PR check will fail.)
+- Always keep `## Use When` as situational triggers (when to reach for this skill at all) and `## Workflow` as the numbered procedure (how to do the work). Never let a Use When bullet paraphrase a Workflow step — if a bullet starts with "Always ship…", "Set X to Y", or restates a procedural detail, it belongs in Workflow, not Use When. (Why: the two sections serve different reader intents — routing vs. execution — and duplicating content between them bloats the agent's context, makes routing fuzzier, and drifts out of sync on every edit.)
 
 ## Examples
 - "I want to add a skill for looking up land parcels" → scaffold `skills/parcel-lookup/`, fill the template, validate.

skills/azure-networking/SKILL.md

@@ -22,6 +22,8 @@ tags: [azure, networking, terraform, bicep, subnets, private-endpoints, nsg]
 - Provisioning AKS networking (CNI Overlay, private API server) — use upstream `azure-kubernetes`.
 - General azd-style app prep that happens to need a subnet — use upstream `azure-prepare`.
 
+*The upstream Microsoft `azure-*` skills referenced above live in the Microsoft `agent-skills` catalogue — install separately if not already in your agent environment.*
+
 ## Workflow
 1. **Anchor to the BC Gov Azure Landing Zone networking rules first — critical, must be followed.** Source of truth: [BC Gov Azure Landing Zone — Networking](https://raw.githubusercontent.com/bcgov/public-cloud-techdocs/refs/heads/main/docs/azure/design-build-deploy/networking.md). These platform constraints **override anything below if they conflict**:
    - **Platform-protected, do not create or modify** — VNets, VNet address space, VNet DNS settings, VNet peerings, ExpressRoute / VPN / NAT / Local Gateways, **Route Tables**, and the `setbypolicy` diagnostic setting. Request changes via the [Public Cloud Service Request](https://citz-do.atlassian.net/servicedesk/customer/portal/3).
@@ -50,7 +52,7 @@ tags: [azure, networking, terraform, bicep, subnets, private-endpoints, nsg]
 - Always set `privateEndpointNetworkPolicies = "Disabled"` on PE subnets. (Why: NSG enforcement on PE NICs requires the subnet flag to be off; otherwise PE traffic is silently dropped.)
 - Always size PE subnets for the **worst-case** service that will land on them. (Why: Cosmos DB PE consumes 2 IPs — one global + one regional endpoint; Azure AI Services "AIServices" kind exposes up to 3 sub-resources = 3 IPs per PE. A `/27` fills surprisingly fast.)
 - Always expose subnet IDs as outputs (Terraform `output`, Bicep `output`) even if no downstream stack reads them yet. (Why: adding outputs later is cheap, but a downstream stack that needs the ID can't read state it isn't exposed to.)
-- Never change vnet address space or create private DNS Zone as it is controlled by the platform team centrally.
+- Never modify VNet address space or create a Private DNS Zone — both are managed centrally by the platform team (see Step 1's platform-protected list; raise a [Public Cloud Service Request](https://citz-do.atlassian.net/servicedesk/customer/portal/3) instead).
 
 ## Examples
 - "Add a Container Apps Environment subnet" → declare the subnet with a `Microsoft.App/environments` delegation (Terraform `azapi_resource` body, Bicep `delegations` array on the subnet, or `az network vnet subnet create --delegations Microsoft.App/environments`); attach an NSG that allows outbound 443 to AzureContainerRegistry, AzureMonitor, AzureActiveDirectory, and VirtualNetwork; serialize against every other subnet in the VNet.
@@ -69,7 +71,7 @@ tags: [azure, networking, terraform, bicep, subnets, private-endpoints, nsg]
 
 See [references/REFERENCE.md](./references/REFERENCE.md) for the atomic subnet+NSG body shape in Terraform, Bicep, and az CLI; full NSG rule tables per subnet type; sibling-subnet serialization examples; App Gateway route-table requirements; PE subnet capacity math; and a failure playbook keyed by Azure error code.
 
-For broader Azure topics, prefer these upstream Microsoft skills instead of duplicating their guidance here:
+For broader Azure topics, prefer these upstream Microsoft skills (in the Microsoft `agent-skills` catalogue — install separately if not already in your agent environment) instead of duplicating their guidance here:
 - VNet, hub-spoke, and landing-zone design → `azure-enterprise-infra-planner`
 - Workload preparation (Bicep/Terraform scaffolding, azd) → `azure-prepare`
 - AKS-specific networking → `azure-kubernetes`

skills/azure-networking/references/REFERENCE.md

@@ -243,7 +243,8 @@ Port 80 is intentionally not allowed — let App Gateway terminate HTTPS and ski
 ## App Gateway Route Table (Asymmetric Routing Fix)
 
 App Gateway is one of the few subnets that often needs an explicit route table — typically a `0.0.0.0/0 → Internet` route to override a UDR that a hub-spoke topology applies at the VNet level, plus any internal corp ranges that must NOT egress through ExpressRoute / VWAN.
-- create a ticket with Azure Landing Zone platform team for creating the UDRs
+
+**BC Gov Landing Zone**: Route Tables are platform-protected (see SKILL.md Step 1 and the final Rule) — do **not** attach your own. Raise a [Public Cloud Service Request](https://citz-do.atlassian.net/servicedesk/customer/portal/3) describing the required UDRs (destination prefix, next-hop type, next-hop IP); the Azure Landing Zone platform team owns the create / update.
 
 ---