@apexops/cli 0.10.0-next.0

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-diagnostics/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: apex-azure-diagnostics
+description: "Interpret APEX diagnostic evidence for Azure service symptoms. Use for health, logs, metrics, failed requests, cold starts, image pulls, and probe analysis."
+user-invocable: false
+---
+
+# APEX Azure Diagnostics
+
+Use this skill for an active APEX task that interprets capability-produced
+diagnostic evidence. It supports evidence-based triage; it does not run
+diagnostics, alter service state, or establish a root cause without proof.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the affected target, symptom, time window,
+  environment, customer impact, and sensitivity boundary.
+- Accepted evidence records the producing capability, evidence hash, target
+  scope, query intent, observation time, freshness, completeness, and
+  redactions.
+- The requested time window is sufficient to compare an incident interval with
+  a baseline. Otherwise, retain a single-window interpretation as uncertain.
+
+## Workflow
+
+1. Define the symptom as an observable failure, degradation, or anomaly and
+   verify that the evidence window and target match it.
+2. Evaluate health, activity, logs, metrics, dependencies, and change evidence
+   as separate signals. Absence in one signal is not proof of health.
+3. Use [diagnostic interpretation](references/diagnostic-interpretation.md) to
+   classify correlations, confidence, and diagnostic gaps.
+4. Distinguish observed facts, likely contributors, and untested hypotheses.
+   Do not label a correlation as root cause without causal evidence.
+5. Return the impact summary, evidence-backed findings, uncertainty, and a
+   kernel-provided escalation or next-investigation decision.
+
+## Boundaries
+
+- Do not invoke external diagnostics, run queries, access logs, inspect live
+  service state, or attempt mitigation. Treat all observations as scoped
+  capability-produced evidence.
+- Do not expose request payloads, credentials, tokens, personal data, or stack
+  traces beyond approved redaction boundaries.
+- Escalate confirmed or suspected security exposure to the appropriate security
+  assessment. Route deployment readiness and spending questions to their owning
+  assessments.
+- A diagnostic conclusion never authorizes a configuration change, rollback,
+  scaling operation, or deployment.
+
+## Output
+
+Return the symptom, target and time scope, evidence hashes and freshness,
+observed facts, hypotheses with confidence, coverage limits, impact, escalation
+boundary, and kernel-provided next action.
+
+## References
+
+- [Diagnostic interpretation](references/diagnostic-interpretation.md) -
+  evidence sequence, KQL result meaning, service signals, and uncertainty.
+- [Operational checklist](references/operational-checklist.md) -
+  symptom framing, signal correlation, and escalation boundaries.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-diagnostics/references/diagnostic-interpretation.md

@@ -0,0 +1,42 @@
+## Evidence Sequence
+
+Interpret diagnostic evidence in this order: target identity and health,
+incident-window logs, request and dependency outcomes, performance metrics,
+then change correlation. Each signal must retain its query intent or collection
+purpose, evidence hash, time range, completeness, freshness, and redactions.
+
+Use a baseline window when available. A spike is meaningful only relative to a
+comparable normal period and can still reflect traffic mix, sampling, retention,
+or instrumentation changes.
+
+## Query Result Meaning
+
+| Signal | Supports | Does not prove |
+| --- | --- | --- |
+| Recent exceptions | Errors occurred in the observed window | The error caused the customer symptom |
+| Failed requests | Failure rate and affected operation patterns | A backend, network, or code root cause |
+| Slow requests | Latency distribution or slow operations | Capacity exhaustion or the causal dependency |
+| Failed dependencies | Downstream failure correlation | Ownership or origin of the failure |
+| Health or activity events | Control-plane or service-health context | Complete application health |
+
+Time bounds, result limits, sampling, missing diagnostics, and redacted fields
+are material uncertainty. Empty results mean only that the scoped evidence did
+not observe a match; they do not establish absence.
+
+## Service Signals
+
+For containerized services, image acquisition, startup delay, probe failures,
+port mismatch, and revision transitions are distinct hypotheses. For functions,
+invocation failures, timeout patterns, binding failures, cold starts, and
+missing configuration signals likewise need separate evidence. Preserve this
+separation in the finding set so a common symptom is not mistaken for one cause.
+
+## Confidence And Escalation
+
+Use `observed` for directly evidenced facts, `correlated` for aligned signals,
+and `hypothesis` for plausible but untested explanations. Increase confidence
+only when independent evidence sources agree on target and time window.
+
+Escalate when impact is broad, customer-facing, security-sensitive, or evidence
+is too incomplete to bound the risk. The handoff identifies the unanswered
+question and needed scoped evidence; it does not prescribe a live action.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-diagnostics/references/operational-checklist.md

@@ -0,0 +1,24 @@
+# Diagnostics Operational Checklist
+
+## Frame The Investigation
+
+- State the affected target, observable symptom, environment, impact, and
+  investigation window. A single window may establish correlation only.
+- Compare incident evidence with a compatible baseline when one exists; keep
+  the absence of a signal distinct from proof of health.
+- Keep health, activity, logs, metrics, dependencies, and change evidence as
+  separate signals before drawing a conclusion.
+
+## Interpret Safely
+
+- Classify statements as observed fact, supported contributor, or untested
+  hypothesis. Root-cause claims require causal evidence, not timing alone.
+- For image pulls, cold starts, probes, and request failures, preserve the
+  service-specific evidence and the tested configuration boundary.
+- Redact request bodies, credentials, tokens, personal data, and unapproved
+  stack details; do not reconstruct redacted values by correlation.
+
+## Escalation
+
+Return impact, evidence hashes, uncertainty, and the authorized next
+investigation. Diagnostics never authorizes scaling, rollback, or mitigation.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-governance/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: apex-azure-governance
+description: "Guide APEX planning from accepted Azure governance evidence. Use for policy constraints and blockers."
+user-invocable: false
+---
+
+# APEX Azure Governance Guidance
+
+Use this skill for an active APEX planning, architecture, or validation task
+that needs Azure Policy constraints. Only capability-produced, accepted
+governance evidence in `apex/taskContext` is authoritative.
+
+## Prerequisites
+
+- The task context identifies the target subscription and applicable
+  management-group ancestry.
+- Accepted governance evidence includes its discovery status, discovery time,
+  freshness limit, completeness signature, and scope.
+
+Return a blocker when evidence is missing, partial, failed, stale, unsigned,
+or scoped to a different subscription or management-group ancestry. Do not
+infer policy state from model memory, templates, or a prior task.
+
+## Workflow
+
+1. Confirm the evidence has a `COMPLETE` status and covers the task scope.
+2. Compare the discovery time with its declared freshness limit; route stale
+   evidence to the governance discovery capability.
+3. Treat `Deny` findings as blockers unless an accepted exemption records
+   them as informational.
+4. Account for `DeployIfNotExists` and `Modify` findings as deployment-time
+   conditions rather than silently assuming the desired result.
+5. Carry required tags, allowed locations, and relevant property-path
+   constraints into the typed planning or architecture decision.
+6. Record the evidence identifier, scope, completeness signature, and any
+   unresolved constraint in the staged artifact.
+
+## Boundaries
+
+- This skill is advisory. It does not discover policy state, query Azure,
+  refresh evidence, or modify resources, files, or task state.
+- Governance evidence constrains a design; it does not grant an exemption or
+  override an unresolved policy.
+- Send deployment and remediation decisions to their authorized capability
+  and gate, not to this skill.
+
+## References
+
+- [Evidence interpretation](references/evidence-interpretation.md) -
+  envelope checks, classification, exemptions, and blocker routing.
+- [Operational checklist](references/operational-checklist.md) -
+   resume conditions, effect handling, and evidence handoff.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-governance/references/evidence-interpretation.md

@@ -0,0 +1,58 @@
+# Governance Evidence Interpretation
+
+Use this reference after accepted governance evidence is available in the
+active task context. The evidence is a point-in-time attestation, not a
+standing authorization.
+
+## Acceptance Checks
+
+Treat the evidence as usable only when all of the following hold:
+
+- Discovery status is `COMPLETE`.
+- Discovery time is within the evidence freshness limit.
+- Subscription and management-group ancestry match the intended task scope.
+- A completeness signature is present and matches the accepted evidence
+  record.
+- A nonempty discovery result is consistent with the evidence metadata.
+
+Any failed check is a blocker. State which check failed and route the task to
+the governance discovery capability; do not continue with a guessed baseline.
+
+## Classification Rules
+
+| Policy effect | Planning interpretation |
+| --- | --- |
+| `Deny` | Block the incompatible design unless an accepted exemption applies. |
+| `DeployIfNotExists` | Model it as a deployment-time condition that the plan must accommodate. |
+| `Modify` | Model it as a deployment-time mutation that may change the final resource state. |
+| `Audit` or `AuditIfNotExists` | Preserve as informational context when present in accepted evidence. |
+| `Disabled` | Do not treat as a live constraint. |
+
+An accepted exemption retains the original policy effect but changes its
+planning classification to informational. Record its category, expiry, scope,
+and rationale. An expired, missing, or scope-mismatched exemption is not an
+override.
+
+## Planning Handoff
+
+Project only applicable constraints into the typed decision:
+
+- Required tag keys and values.
+- Allowed locations.
+- Resource-property constraints with resolvable target paths.
+- Policy identifiers, classifications, exemptions, and evidence provenance.
+
+Leave an unresolved property path explicit rather than inventing an IaC
+mapping. Authorized planning and delivery capabilities own any later
+translation or remediation.
+
+## Resume And Reconciliation
+
+On resume, repeat the acceptance checks against the current task scope and freshness limit. A prior `COMPLETE` result
+does not survive a changed subscription, management-group ancestry, evidence signature, or expiry window. When
+delivery reports policy drift or an indeterminate provider outcome, preserve the observed result and route it to the
+authorized reconciliation lifecycle. Do not rerun discovery, apply an override, or synthesize a corrected policy
+baseline from this guidance.
+
+Discovery scripts, pack execution, and terminal commands remain outside this skill until a separately qualified typed
+capability owns them.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-governance/references/operational-checklist.md

@@ -0,0 +1,25 @@
+# Governance Operational Checklist
+
+## Evidence Resume
+
+- Reuse governance evidence only when its scope, management-group ancestry,
+  completeness signature, and freshness policy still match the active task.
+- Treat a changed target, expired freshness, missing signature, `PARTIAL`, or
+  `FAILED` discovery result as a blocker requiring a new authorized discovery.
+- Preserve unresolved property paths as unresolved. Do not manufacture an IaC
+  equivalent from a policy display name or remembered convention.
+
+## Effect Handling
+
+- Treat `Deny` as a design blocker unless an accepted, in-scope exemption is
+  current and recorded with its rationale.
+- Model `Modify` and `DeployIfNotExists` as delivery-time conditions that can
+  alter the observed result; they are not evidence that remediation completed.
+- Keep `Audit`, `AuditIfNotExists`, and `Disabled` findings distinct from
+  blocking constraints and retain their evidence provenance.
+
+## Handoff
+
+Record the evidence identifier, accepted scope, constraints, exemptions, and
+unknowns in the decision. A governance result constrains later work; it never
+grants an exemption, provider access, or remediation authority.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-kusto/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: apex-azure-kusto
+description: "Interpret APEX Azure Data Explorer evidence and KQL analysis. Use for Kusto, ADX, KQL, schema, aggregation, time-series, correlation, and anomaly findings."
+user-invocable: false
+---
+
+# APEX Azure Data Explorer Analysis
+
+Use this skill for an active APEX task that interprets accepted Azure Data
+Explorer evidence and KQL analysis results. It does not discover schemas,
+execute queries, export data, or mutate clusters.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the cluster and database boundary, approved
+  table scope, analytic question, time range, result limit, and data handling
+  constraints.
+- Capability-produced evidence carries its producer, query intent or pattern,
+  evidence hash, target scope, observation time, freshness, completeness,
+  sampling or truncation status, and redaction boundary.
+- Schema evidence is accepted for the same target and sufficiently fresh for
+  the query interpretation. Do not infer columns or semantics from table names.
+
+## Workflow
+
+1. Confirm the analytic question and select the applicable interpretation
+   pattern in [KQL evidence interpretation](references/kql-evidence-interpretation.md).
+2. Verify that time bounds, filters, projections, joins, and aggregation grain
+   answer that question without silently excluding relevant records.
+3. Distinguish record retrieval, aggregate trend, correlated event, and anomaly
+   evidence. State what the pattern establishes and what it cannot establish.
+4. Carry evidence hash, target scope, time window, result completeness,
+   redactions, and uncertainty into the result.
+5. Return observations and an authorized next-assessment request when evidence
+   is insufficient. Route operational incidents to diagnostics and cost
+   questions to cost assessment.
+
+## Boundaries
+
+- Do not invoke external queries, inspect schemas, retrieve data, or export
+  results. All inputs are scoped capability-produced evidence.
+- Do not treat sampled, limited, partial, or stale results as population-wide
+  truth. Do not recover redacted values through correlation or inference.
+- Do not create mutation, retention, access, or cluster-management decisions.
+  Escalate such requests to the kernel-selected owner.
+
+## Output
+
+Return the question, target scope, query-pattern intent, evidence hashes,
+freshness, redaction and completeness limits, observations, uncertainty, and
+kernel-provided next action. Use `indeterminate` for incomplete support.
+
+## References
+
+- [KQL evidence interpretation](references/kql-evidence-interpretation.md) -
+  query pattern meaning, quality checks, and analytic limits.
+- [Operational checklist](references/operational-checklist.md) -
+  schema, query-shape, result-limit, and redaction checks.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-kusto/references/kql-evidence-interpretation.md

@@ -0,0 +1,41 @@
+## Interpretation Patterns
+
+| Pattern | Useful for | Required limits to report |
+| --- | --- | --- |
+| Retrieval | Inspecting bounded recent records | Time range, filter, projection, result limit |
+| Aggregation | Counts, distributions, and top contributors | Grouping dimensions, time bucket, omitted values |
+| Time series | Trend, latency, volume, and anomaly signals | Baseline, bucket size, sampling, seasonality |
+| Correlation | Events aligned by a declared key and interval | Join type, unmatched records, key quality |
+| Schema evidence | Understanding available fields and types | Schema freshness, permissions, partial visibility |
+
+Every interpretation begins with the question, target, and time range. A
+time-series result needs a bounded time filter; an exploratory result needs a
+declared limit. A pattern that is not present in evidence cannot be assumed.
+
+## Quality Checks
+
+- Confirm filters were applied before broad correlation or aggregation where
+  the evidence's query intent requires a constrained population.
+- Confirm projected fields contain only approved, redacted data and that
+  aggregations do not disclose protected values through small groups.
+- Confirm `bin`-style bucketing matches the decision horizon; a coarse bucket
+  can hide bursts and a fine bucket can create noise.
+- Treat joins as a relationship claim only when the correlation key, time
+  alignment, and unmatched-record behavior are documented.
+- Compare anomaly or percentile claims to an accepted baseline. A single high
+  percentile or spike does not establish a persistent trend.
+
+## Limits And Escalation
+
+Result limits, sampling, retention, late-arriving events, schema drift,
+permission-based partial visibility, and redaction can all bias a conclusion.
+State these limits with the evidence hash and freshness rather than compensating
+with assumptions. When a conclusion needs wider scope, unredacted data, a
+different time window, or causal service evidence, return `indeterminate` and
+ask the kernel to obtain the needed scoped capability evidence.
+
+## Query Capability Boundary
+
+Schema discovery, KQL execution, CLI or REST fallback, and data export are provider-backed operations. Preserve their
+query intent, scope, limits, and failure state in an evidence request, but defer execution until a qualified capability
+exists. Do not replace an unavailable query result with model-generated records or inferred schema.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-kusto/references/operational-checklist.md

@@ -0,0 +1,25 @@
+# Kusto Evidence Operational Checklist
+
+## Query Shape
+
+- Confirm accepted schema evidence for the same cluster, database, table, and
+  freshness policy before interpreting a query result.
+- Bound time-series questions by time range and result size. Filter and project
+  early, and keep joins and aggregation grain aligned with the stated question.
+- Distinguish record retrieval, aggregate trends, correlations, and anomaly
+  signals; each has different limits on the conclusions it can support.
+
+## Result Quality
+
+- Preserve query intent, target scope, time window, sampling, truncation,
+  redaction, and evidence hash with the result.
+- Treat a schema mismatch, unbounded question, partial result, or stale data as
+  indeterminate. Do not infer columns or semantics from names alone.
+- Do not recover redacted values, export data, or turn query findings into
+  retention, access, or cluster-management decisions.
+
+## Routing
+
+Route operational symptoms to diagnostics and spend questions to cost
+assessment. Request an authorized collection only when accepted evidence is
+insufficient.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-prepare/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: apex-azure-prepare
+description: "Prepare traceable Azure delivery intent in APEX. Use for requirements, architecture, implementation planning, and IaC bindings before validation."
+user-invocable: false
+---
+
+# APEX Azure Preparation
+
+Use this skill only for an active requirements, architecture, planning, or CodeGen task. It translates accepted intent
+into traceable architecture, plan, and selected-track IaC binding artifacts. The kernel owns task state, approvals,
+artifact acceptance, and every repository mutation.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the active task, its allowed outputs, target environment, and evidence references.
+- Requirements and any predecessor architecture or governance evidence are accepted and fresh for the active run.
+- A selected IaC track is present before a binding is created; otherwise return `needs_input` or a blocker.
+
+## Workflow
+
+1. Trace the accepted requirements to resource, identity, networking, data, diagnostic, recovery, and operational
+   decisions. Preserve unknowns and external dependencies as explicit blockers.
+2. For architecture tasks, record material Well-Architected trade-offs, evidence references, and user-owned choices
+   through the kernel task workflow. Do not infer subscription, policy, quota, or availability facts.
+3. For planning tasks, express deployment-neutral logical intent, dependencies, ownership, controls, and acceptance
+   obligations. Keep provider syntax and implementation details out of neutral planning intent.
+4. Bind the accepted plan to exactly one selected IaC track. Place module, provider, API, parameter, state, and
+   ownership details in that binding, while preserving the trace back to planned intent and accepted policy.
+5. Use only the kernel-authorized artifact and generation capabilities named by the task envelope. Return their typed
+   result, or a blocker when an output, evidence item, or approval is missing.
+6. For Azure Functions intent, use [Azure Functions recipe pack](references/functions-recipe-pack.md). The pack is
+   deferred: record its unavailable materialization dependency rather than reading or composing its source templates.
+
+## Boundaries
+
+- Do not write files directly; selected IaC generation and staging belong to the authorized CodeGen capability.
+- Do not run commands, contact Azure, select a subscription, retrieve secrets, preview infrastructure, or deploy.
+- Do not mark a plan approved, validated, or deployable. Those state transitions are kernel-controlled.
+- Transform a request for direct Bicep, Terraform, AZD, or deployment work into the active task's approved binding and
+  capability path. A direct-operation request is not authorization to mutate the workspace or Azure.
+
+## References
+
+- [Preparation lineage and binding](references/preparation-lineage.md) - evidence flow, artifact distinctions, and
+  handoff criteria.
+- [Azure Functions recipe pack](references/functions-recipe-pack.md) - deferred corpus status and safe design
+   checklist.
+
+## Output
+
+Return kernel-provided artifact identifiers, requirement traces, binding references, blockers, and the next task. Do
+not claim implementation is ready for deployment until validation evidence is accepted.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-prepare/references/functions-recipe-pack.md

@@ -0,0 +1,27 @@
+# Azure Functions Recipe Pack
+
+The Azure Functions recipe corpus is source-bound in
+[`config/recipe-packs.v1.json`](../../../../../config/recipe-packs.v1.json). It contains service guidance, base
+specifications, recipe templates, and evaluation fixtures, but it is not an active capability.
+
+## Availability
+
+The `azure-functions-recipes` pack is `deferred` until an authorized `recipe-materializer` capability exists. Return an
+unavailable blocker for requests to inspect, select, compose, stage, materialize, validate, or publish a recipe. Do not
+load template content from the corpus as a workaround.
+
+## Design Checklist
+
+- Establish the trigger, event source, concurrency, retry, identity, network, data, and observability requirements.
+- Select a hosting model only from accepted workload evidence. Treat runtime-version support as an external fact that
+  needs fresh evidence.
+- For Event Grid blob processing, record the required storage endpoints, identity roles, subscription ownership, and
+  startup behavior as accepted implementation obligations.
+- For Durable Functions, preserve orchestration determinism, state ownership, replay implications, and dependency
+  boundaries in architecture and test intent.
+- Keep source, target, and secret values out of task artifacts. Materialization and publishing remain unavailable.
+
+## Handoff
+
+Record the recipe family and unmet materialization dependency in the IaC binding. Continue only with an authorized
+alternative generation path or return the blocker to the kernel.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-prepare/references/preparation-lineage.md

@@ -0,0 +1,36 @@
+# Preparation Lineage and Binding
+
+## Evidence Flow
+
+The preparation lifecycle maintains a one-way evidence chain:
+
+1. Accepted requirements establish outcomes, constraints, and acceptance intent.
+2. Architecture decisions explain the selected service, identity, networking, resilience, and operational approach.
+3. The implementation plan turns those decisions into logical resources, dependencies, ownership, controls, and
+   verification obligations.
+4. A selected IaC binding expresses the track-specific module, provider, API, parameter, and state details needed for
+   a bounded generation capability.
+
+Every artifact must retain requirement IDs and accepted evidence references. An unresolved policy, quota, availability,
+cost, ownership, or environment input remains unresolved; it must not become an assumed implementation value.
+
+## Artifact Boundaries
+
+| Artifact | Owns | Must Not Own |
+| --- | --- | --- |
+| Architecture | Decision rationale and material trade-offs | Provider syntax or direct resource definitions |
+| Plan | Logical resources, controls, dependencies, and acceptance obligations | Track-specific implementation syntax |
+| IaC binding | Track-specific module and configuration intent | New architecture or policy decisions |
+| Generated batch | Kernel-authorized implementation output | Approval, validation, or deployment authority |
+
+## Handoff to Validation
+
+Preparation is complete only when the task's required artifacts are staged and accepted, the selected binding is
+unambiguous, and all known constraints have a trace. This is evidence of preparation, not proof that the output is
+valid, current, or deployable. Validation independently checks that claim.
+
+## Direct-Operation Transformation
+
+When a request asks to create infrastructure, configure Azure, or execute an IaC workflow, express the requested
+outcome as a requirement or plan change. Route implementation through the kernel-selected binding and authorized
+generation capability. Never translate it into a shell command, a direct file write, or an Azure operation.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-quotas/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: apex-azure-quotas
+description: "Guide APEX capacity planning from accepted Azure quota evidence. Use for limits and region comparisons."
+user-invocable: false
+---
+
+# APEX Azure Quota Guidance
+
+Use this skill for an active APEX planning or validation task that needs a
+capacity decision. Only capability-produced, accepted quota and availability
+evidence in `apex/taskContext` is authoritative.
+
+## Prerequisites
+
+- The task specifies the resource demand, provider, candidate region, and
+  target subscription.
+- Accepted evidence identifies the quota resource, limit, usage, observation
+  time, and scope for each evaluated region.
+
+Return a blocker when quota evidence is missing, stale, incomplete, or outside
+the requested provider, subscription, region, or resource boundary. Do not
+assume a quota value or infer a quota resource name from an ARM resource type.
+
+## Workflow
+
+1. Confirm the evidence scope matches the deployment intent and each candidate
+   region.
+2. Verify the capability resolved the provider-specific quota resource rather
+   than relying on an ARM type-name assumption.
+3. Calculate available capacity as `limit - (usage + requested demand)` for
+   each applicable quota.
+4. Treat a nonpositive result as a capacity blocker; distinguish it from a
+   service hard limit or an unavailable quota surface.
+5. Compare only regions with equally fresh, compatible evidence and preserve
+   the selected region's evidence identifier in the typed decision.
+6. Route insufficient capacity to an authorized quota-request or deployment
+   planning path; do not request increases from this skill.
+
+## Boundaries
+
+- This skill does not discover quotas, check live usage, select subscriptions,
+  request increases, configure alerts, or alter resources or files.
+- Quota sufficiency is not a deployment approval, price estimate, or service
+  availability guarantee.
+- A capacity claim may not be extended beyond the accepted provider, region,
+  resource family, subscription, and observation time.
+
+## References
+
+- [Capacity decision rules](references/capacity-decision-rules.md) - scope,
+  resource-name mapping, calculation, and outcomes.
+- [Operational checklist](references/operational-checklist.md) -
+   mapping, capacity comparison, and unavailable-surface handling.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-quotas/references/capacity-decision-rules.md

@@ -0,0 +1,48 @@
+# Quota Capacity Decision Rules
+
+Use accepted quota evidence as a scoped snapshot. The evidence must identify
+the provider, subscription, region, quota resource, limit, usage, unit, and
+observation time.
+
+## Resource Mapping
+
+An ARM resource type does not have a universal one-to-one relationship with a
+quota resource. One resource type can consume a family quota, a regional
+resource-count quota, or multiple quotas. Accept only capability-produced
+mapping evidence that names the evaluated quota resource and its unit.
+
+Treat the following as blockers:
+
+- No resolved quota resource for the requested demand.
+- A mapping for a different provider, resource family, or region.
+- Ambiguous units between demand, usage, and limit.
+- Evidence that has passed its declared freshness limit.
+
+## Capacity Calculation
+
+For each required quota, calculate:
+
+`remaining capacity = limit - (current usage + requested demand)`
+
+Capacity is sufficient only when every required quota has positive remaining
+capacity after the requested demand. Preserve the inputs and result in the
+typed planning decision so later validation can repeat the interpretation.
+
+## Decision Outcomes
+
+| Evidence outcome | Planning result |
+| --- | --- |
+| Every required quota is sufficient | Record a bounded capacity decision for the evaluated scope. |
+| A quota is insufficient | Record a blocker and route to an authorized request or region decision. |
+| A quota is fixed by a service limit | Record the blocker; do not call it an adjustable quota. |
+| Provider or quota surface is unsupported | Record an evidence gap and require a capability result. |
+
+Do not compare regions using different demand assumptions, units, or freshness
+windows. A regional comparison is a decision aid, not an authorization to
+change the target region.
+
+## Provider And Troubleshooting Boundary
+
+Record provider support, extension or command failure, invalid scope, unavailable quota surface, and service hard-limit
+signals as evidence gaps or blockers. CLI discovery, command execution, monitoring configuration, and quota-increase
+workflows are deferred provider capabilities. A troubleshooting note must not turn into a command or a request action.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-quotas/references/operational-checklist.md

@@ -0,0 +1,23 @@
+# Capacity Operational Checklist
+
+## Mapping And Scope
+
+- Confirm the provider-specific quota resource from accepted evidence. An ARM
+  resource type is not a reliable quota-resource name.
+- Compare only records for the same subscription, provider, region, resource
+  family, observation policy, and requested demand.
+- Separate quota capacity from service hard limits and regional availability;
+  none of these establishes deployment approval.
+
+## Decision
+
+- Compute remaining capacity from the observed limit, usage, and requested
+  demand, then retain each source value in the decision record.
+- Treat nonpositive remaining capacity as a blocker. Treat an unsupported or
+  unavailable quota surface as indeterminate, not unlimited capacity.
+- Do not compare region alternatives whose evidence freshness or scope differs.
+
+## Handoff
+
+Route capacity gaps to an authorized planning or quota-request path. This skill
+does not request an increase, select a subscription, or promise allocation.