@apexops/cli 0.10.0-next.0

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-adr/references/decision-record-fields.md

@@ -0,0 +1,57 @@
+# Architecture Decision Record Fields
+
+Use these fields in a typed architecture or planning decision. They are presentation and quality guidance; the accepted
+artifact schema remains authoritative.
+
+## Identity And Lifecycle
+
+Record the stable decision identifier, concise title, kernel-projected status, decision owner, deciders, decision time,
+and affected workload scope. When applicable, record `supersedes` or `superseded_by`; preserve the earlier rationale.
+
+## Context
+
+State the problem or opportunity, current state, desired outcome, constraints, assumptions, stakeholders, accepted
+evidence, affected requirement IDs, and why a decision is required now. Keep one material trade-off per decision.
+
+## Decision Drivers
+
+List measurable evaluation criteria such as availability, RTO/RPO, latency, consistency, residency, identity, network
+exposure, operability, migration effort, cost envelope, team capability, and reversibility. Mark mandatory constraints.
+
+## Selected Option
+
+State the selected option precisely. Tie it to an accepted requirement, a kernel-recorded user choice, or accepted
+evidence. Include scope and posture, not just a product name. Do not use vague statements such as "use a database".
+
+## Alternatives
+
+Record at least one viable alternative when the choice materially affects the workload. For each alternative, state its
+fit against the same drivers, benefits, drawbacks, evidence, rejection rationale, and affected WAF pillars. Do not pad
+the record with options that violate mandatory constraints unless the violation itself explains the rejection.
+
+## Consequences
+
+Record at least one positive and one negative consequence. Use measurable statements where evidence exists. Include
+neutral constraints, residual risks, migration effects, lock-in, operating burden, cost sensitivity, and follow-up
+obligations when they affect later planning.
+
+## WAF And Compliance
+
+Describe effects on Security, Reliability, Performance Efficiency, Cost Optimization, and Operational Excellence. Record
+direction, rationale, mitigation, and evidence for each material effect. Record compliance, residency, identity,
+governance, audit, and exception implications from accepted constraints; do not infer live policy.
+
+## Implementation Constraints
+
+Record binding constraints such as required module/provider family, identity model, network posture, diagnostics, or
+recovery objective. Do not include direct shell commands, role assignment snippets, secret values, or deployment steps.
+
+## Validation And Revisit
+
+Define observable acceptance signals, decision owner, review event, reversal or migration trigger, and conditions that
+would invalidate the decision. Planned validation is not evidence that validation already passed.
+
+## Provenance
+
+Reference accepted requirement, governance, pricing, availability, benchmark, and user-decision identifiers. Preserve
+unknown and deferred evidence explicitly and never fabricate a citation.

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

@@ -0,0 +1,55 @@
+---
+name: apex-azure-cloud-migrate
+description: "Assess cross-cloud workload migration intent in APEX. Use for readiness, AWS or GCP workload mapping, migration risks, staged validation, and authorized handoffs."
+user-invocable: false
+---
+
+# APEX Azure Cloud Migration Guidance
+
+Use this skill only for an active assessment, architecture, planning, or approved implementation-binding task. The
+kernel owns task state, evidence freshness, authorization, artifact acceptance, and all state-changing work.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the active task, allowed outputs, source evidence, target constraints, and evidence
+  references.
+- A bounded workload inventory or owner-supplied evidence identifies the source platform, services, runtime, interfaces,
+  data classification, and critical dependencies; otherwise return `needs_input`.
+- A migration action is available only through a kernel-authorized capability. A migration request does not authorize
+  source inspection, code conversion, file creation, testing, or deployment.
+
+## Workflow
+
+1. Produce an evidence-bounded readiness assessment. Identify unknowns, compatibility risks, security constraints,
+   continuity needs, and user-owned choices without inspecting source or querying cloud services.
+2. Map each accepted workload concern to a logical Azure target pattern. Record confidence, trade-offs, assumptions,
+   dependencies, and unresolved mapping decisions instead of asserting a one-to-one service replacement.
+3. Define staged validation intent: assessment acceptance, authorized implementation evidence, isolated functional
+   validation, integration validation, and production-readiness evidence. A failed or absent receipt blocks the next
+   stage.
+4. Submit the assessment or migration plan only through the kernel-authorized capability named in the task envelope.
+   Preserve the returned receipt or blocker in the active artifact.
+5. Handoff accepted intent to the authorized preparation, implementation, validation, or operations capability. Do not
+   state that a workload is migrated, tested, or deployed without accepted receipts for that stage.
+6. For Lambda-to-Functions requests, apply
+   [Lambda to Functions assessment](references/lambda-to-functions-assessment.md) to the accepted evidence. Return a
+   blocker when the task needs source inspection, code conversion, publishing, or cutover.
+
+## Boundaries
+
+Do not use cloud portals, CLI, SDKs, APIs, repositories, source scanning, code conversion, IaC, deployment tooling, or
+file-mutation actions. Do not discover workloads, access source, create migration output, alter environments, test,
+deploy, or handle secrets. Convert direct operational requests into bounded intent and an authorized capability handoff.
+
+## References
+
+- [Migration readiness assessment](references/migration-readiness.md) - evidence, risk, and blocker criteria.
+- [Workload mapping intent](references/workload-mapping.md) - logical service, identity, data, and observability mapping.
+- [Staged validation and handoff](references/staged-validation-handoff.md) - receipt gates and next-task routing.
+- [Lambda to Functions assessment](references/lambda-to-functions-assessment.md) - workload mapping, runtime review,
+  and blocked-operation boundary.
+
+## Output
+
+Return an evidence-bounded migration assessment or plan, requirement traces, capability receipt references, explicit
+blockers, and the next kernel-controlled task.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-cloud-migrate/references/lambda-to-functions-assessment.md

@@ -0,0 +1,29 @@
+# Lambda To Functions Assessment
+
+Use this reference to assess a proposed AWS Lambda to Azure Functions migration from accepted evidence. It is not a
+source-discovery or code-conversion procedure.
+
+## Mapping Checklist
+
+| AWS concern | Azure assessment focus |
+| --- | --- |
+| Lambda handler and event | Functions trigger, invocation model, retry, and idempotency intent |
+| API Gateway | HTTP trigger, authentication boundary, and gateway requirement |
+| S3 events | Blob and Event Grid delivery semantics, ordering, and poison handling |
+| SQS or SNS | Queue, Service Bus, or Event Grid delivery guarantees and dead-letter ownership |
+| DynamoDB streams | Cosmos DB change-feed fit, data model, and consistency assumptions |
+| CloudWatch | Application Insights and Azure Monitor evidence requirements |
+| IAM role | Managed identity and least-privilege Azure RBAC intent |
+
+## Runtime And Data Review
+
+- Identify the source runtime, dependency model, handler contract, bindings, environment configuration, and test scope.
+- Separate portable business logic from event adapters, SDK usage, and source-cloud service assumptions.
+- Record data residency, transfer, retention, recovery, cutover, rollback, and ownership constraints before any
+  transformation is considered.
+- Treat target runtime support, service limits, and provider behavior as evidence that must be current and accepted.
+
+## Blocked Operations
+
+Source-cloud reads, repository scans, code transformation, local execution, publishing, data transfer, and cutover are
+not authorized by this assessment. Return an unavailable or needs-input blocker when the task needs any of them.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-cloud-migrate/references/migration-readiness.md

@@ -0,0 +1,27 @@
+# Migration Readiness Assessment
+
+Base an assessment only on accepted requirements and owner-supplied evidence. It describes readiness, not a discovery
+result or a completed migration. Missing evidence is a blocker, not permission to inspect source or cloud resources.
+
+## Assessment Fields
+
+| Area | Capture |
+| --- | --- |
+| Workload | Source platform, business function, owner, criticality, runtime, and interfaces |
+| Data | Classification, residency, recovery needs, and transfer constraints |
+| Identity | Current trust boundary, target identity intent, and access unknowns |
+| Dependencies | External services, contracts, supportability, and ordering dependencies |
+| Operations | Availability, observability, continuity, support, and rollback expectations |
+| Risk | Compatibility, security, data, downtime, cost, and governance risk with evidence |
+
+## Readiness Decision
+
+Use `ready_for_planning` only when required evidence and ownership are accepted. Use `needs_input` for missing workload
+facts. Use a blocker for unsupported requirements, unresolved policy constraints, unsafe data movement, or a missing
+owner. Record risk mitigation as planned intent, never as completed control evidence.
+
+## Runtime Compatibility
+
+Capture the source trigger, runtime family, supported target runtime, dependency model, state assumptions, and
+unsupported feature risk. A runtime compatibility statement is an assessment input, not code conversion evidence.
+When conversion, source inspection, or runtime verification is needed, defer it to a separately authorized capability.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-cloud-migrate/references/staged-validation-handoff.md

@@ -0,0 +1,26 @@
+# Staged Validation And Handoff
+
+A migration proceeds through kernel-authorized stages. Passing an earlier stage does not prove a later stage, and no
+stage may be skipped because a plan exists.
+
+## Stages
+
+| Stage | Required evidence | Blocker condition |
+| --- | --- | --- |
+| Assessment | Accepted scope, risks, target intent, and owners | Missing source evidence or unresolved critical risk |
+| Implementation | Authorized capability receipt and trace to approved intent | Missing authorization or rejected output |
+| Functional validation | Accepted isolated behavior evidence | Failure, missing test evidence, or unsupported runtime |
+| Integration validation | Accepted interface, identity, data, and observability evidence | Contract or access mismatch |
+| Production readiness | Accepted governance, recovery, operations, and approval evidence | Unaccepted gate or incomplete ownership |
+
+## Handoff Rules
+
+Preserve the producing capability, receipt identifier, status, evidence reference, blockers, and next task. Route work
+only to the capability named by the active task envelope. Do not execute, simulate, or claim a handoff, validation, or
+deployment.
+
+## Deferred Implementation Boundary
+
+Code migration, source-runtime inspection, local testing, and deployment are provider- or workspace-backed operations.
+Until a capability for that operation is separately qualified, record `defer-capability` with the required scope and
+acceptance evidence rather than using a CLI, SDK, repository scan, or generated migration output.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-cloud-migrate/references/workload-mapping.md

@@ -0,0 +1,27 @@
+# Workload Mapping Intent
+
+Map source capabilities to logical Azure target patterns from accepted evidence. A mapping is a design hypothesis until
+an authorized implementation and validation capability produces accepted receipts.
+
+## Mapping Dimensions
+
+| Source concern | Target intent to record |
+| --- | --- |
+| Compute and triggers | Execution model, event boundary, runtime support, and scale requirements |
+| Data and messaging | Managed service pattern, consistency, retention, residency, and recovery needs |
+| Identity and access | Managed identity preference, least-privilege requirement, and consent or role blockers |
+| Networking | Connectivity, ingress, egress, private access, and policy constraints |
+| Observability | Logs, metrics, traces, alerts, retention, and operational ownership |
+| Delivery | Approved IaC track, environment promotion intent, validation obligations, and rollback ownership |
+
+## Confidence And Alternatives
+
+For each material mapping, record evidence source, confidence, rejected alternative, and decision owner. When no direct
+Azure analogue satisfies the accepted requirements, return a blocker or user decision rather than inventing equivalence.
+
+## Lambda-To-Functions Assessment
+
+For a Lambda-to-Functions proposal, preserve trigger semantics, event payload contracts, retry and dead-letter behavior,
+timeout and concurrency needs, runtime support, dependency packaging, configuration references, and identity boundary.
+These are mapping dimensions only. Source discovery, code conversion, local execution, and runtime deployment require a
+qualified capability and remain outside this guidance.

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

@@ -0,0 +1,58 @@
+---
+name: apex-azure-compliance
+description: "Assess APEX compliance and security evidence. Use for posture findings, configuration review, Key Vault expiration evidence, and finding prioritization."
+user-invocable: false
+---
+
+# APEX Azure Compliance Assessment
+
+Use this skill for an active APEX task that evaluates accepted posture evidence.
+It does not certify compliance, perform a scan, disclose sensitive material, or
+authorize remediation.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the target scope, applicable control source,
+  assessment question, sensitivity boundary, and freshness policy.
+- Capability-produced evidence includes its producer, evidence hash, target
+  scope, observation time, completeness, redactions, and control mapping.
+- A finding is traceable to an observed configuration or item metadata. A
+  recommendation without mapped evidence remains an observation.
+
+## Workflow
+
+1. Confirm that evidence scope matches the intended subscription, resource
+   group, resource, or vault boundary and identify omitted targets explicitly.
+2. Separate control status, security posture signal, reliability signal, and
+   cost observation. Do not turn one category into another.
+3. Correlate findings by control, affected target, severity rationale, and
+   evidence hash. Avoid counting duplicate signals as separate exposure.
+4. For expiration evidence, apply the interpretation rules in
+   [compliance finding criteria](references/compliance-finding-criteria.md).
+5. Return a triaged, redacted finding set and route remediation decisions to
+   the kernel-authorized owner. Escalate potential active exposure or outage
+   indicators without asserting exploitation or incident cause.
+
+## Boundaries
+
+- Do not run external assessments, enumerate resources, inspect vault content,
+  or request secret values. All observations are scoped capability-produced
+  evidence and must remain redacted to the task's approved boundary.
+- Do not represent a partial assessment as compliant, noncompliant, or secure.
+- Do not prescribe, apply, or validate remediation. This skill identifies the
+  evidence-backed need and escalation boundary only.
+- Route spend questions to cost assessment, live service symptoms to diagnostic
+  assessment, and policy-scope interpretation to the applicable governance task.
+
+## Output
+
+Return target scope, control basis, evidence hashes, freshness, redaction and
+coverage limits, findings, severity rationale, uncertainty, escalation need,
+and kernel-provided next action.
+
+## References
+
+- [Compliance finding criteria](references/compliance-finding-criteria.md) -
+  control categories, severity, expiration interpretation, and escalation.
+- [Operational checklist](references/operational-checklist.md) -
+   assessment coverage, finding correlation, and redaction limits.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-compliance/references/compliance-finding-criteria.md

@@ -0,0 +1,63 @@
+## Finding Integrity
+
+A compliance finding needs a control basis, an affected target within scope,
+an observed condition, evidence hash, observation time, and coverage status.
+Classify missing access, incomplete results, redacted fields, or stale evidence
+as an assessment limitation rather than an absent finding.
+
+Use categories to preserve meaning:
+
+| Category | Typical evidence-backed concern |
+| --- | --- |
+| Security | Public exposure, encryption, identity, protocol, or access posture |
+| Reliability | Redundancy, backup, recovery, or single-instance posture |
+| Operational | Diagnostics, monitoring, inventory, or tagging coverage |
+| Cost | Unused or oversized resource signal; route to cost assessment |
+
+## Severity
+
+Severity reflects impact and confidence, not the number of recommendations.
+
+| Severity | Assessment meaning | Escalation boundary |
+| --- | --- | --- |
+| Critical | Credible high-impact exposure or expired active dependency | Urgent kernel-selected security or service owner review |
+| High | Material availability or security risk with strong evidence | Priority owner review |
+| Medium | Control gap or configuration concern with bounded impact | Planned owner assessment |
+| Low | Improvement opportunity or weakly evidenced concern | Track with explicit uncertainty |
+
+Reduce confidence when the scan does not cover all targets, control applicability
+is unknown, a recommendation lacks resource context, or the source has not been
+refreshed within policy. Never infer exploitability from configuration alone.
+
+## Expiration Evidence
+
+Interpret only redacted item metadata: item type, enabled state, validity start,
+expiry, creation or update time, and the declared observation time. Do not
+include values or material identifying sensitive content.
+
+- An expiry before the assessment time is an expired-item finding, subject to
+  enabled state and consumer dependency uncertainty.
+- An expiry inside the approved warning threshold is an expiring-item finding;
+  the threshold must be stated rather than assumed.
+- Missing expiry is a policy or lifecycle-risk signal, not proof of compromise.
+- Disabled items can reduce immediate use risk but may retain governance,
+  inventory, or recovery significance.
+- Ambiguous time zone, missing timestamp, or incomplete item coverage produces
+  `indeterminate` status and requires refreshed scoped evidence.
+
+## Safe Reporting
+
+Report aggregate counts and redacted identifiers only as the task permits. Keep
+the target scope, control mapping, evidence hash, freshness, and uncertainty
+alongside every summary. Handoff asks for owner review; it does not contain
+mutation instructions or claim that a finding has been resolved.
+
+## Recommendation And Authentication Signals
+
+Classify recommendation evidence by security, reliability, operational, or cost concern before assigning severity.
+Authentication evidence should distinguish identity posture, least-privilege scope, and credential-management risk from
+proof of access. Managed identity and narrow RBAC are recommendation criteria, not instructions to create identities,
+assign roles, inspect secrets, or remediate a resource.
+
+AzQR, Resource Graph, Key Vault metadata collection, and all SDK operations are deferred provider capabilities. They
+may supply redacted evidence to this assessment only after separate qualification; this guidance never invokes them.

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

@@ -0,0 +1,24 @@
+# Compliance Operational Checklist
+
+## Assessment Coverage
+
+- State the control source, target boundary, observation time, coverage, and
+  omitted targets before interpreting a finding.
+- Keep assessment output, inventory evidence, and Key Vault item metadata
+  separate. Metadata supports expiration posture, not access to item values.
+- Treat a missing, partial, stale, or unredacted assessment as indeterminate.
+
+## Finding Discipline
+
+- Correlate repeated signals by control and affected target before assigning
+  priority; separate observations from evidence-backed findings.
+- Preserve the severity rationale, evidence hash, and redaction boundary for
+  each finding. Do not infer exploitability, incident cause, or remediation.
+- Expiration evidence requires the observed expiration state and assessment
+  policy. Missing expiry metadata is a control gap, not proof of compromise.
+
+## Escalation
+
+Route security exposure indicators to the authorized security owner and
+remediation decisions to the kernel. A scan or assessment result is not a
+compliance certification.

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

@@ -0,0 +1,36 @@
+---
+name: apex-azure-compute
+description: "Assess Azure VM and VM Scale Set choices for active APEX architecture or planning tasks. Use for compute families, capacity, pricing evidence, and VMSS trade-offs."
+---
+
+# APEX Azure Compute
+
+Use this skill only for an active architecture or planning task. It records a bounded compute recommendation; it does
+not provision, configure, or operate Azure resources.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the active task, target environment, and workload intent.
+- Workload, availability, scaling, region, operating system, and budget are known or explicitly unresolved.
+- Current pricing, quota, availability, and documentation evidence is available when the decision needs it.
+
+## Workflow
+
+1. Select a VM or VMSS model and candidate families with [Compute selection](references/compute-selection.md) and
+   [Recommendation and scale rules](references/recommendation-and-scale-rules.md).
+2. Obtain current, read-only pricing and availability evidence for the target region.
+3. Record the selected model, capacity range, evidence time, assumptions, and rejected alternatives in the typed artifact.
+4. Return missing or stale evidence as a blocker; submit no state change except through APEX MCP.
+
+## Boundaries
+
+- This skill is advisory; it does not execute commands, edit files, or invoke Azure control-plane operations.
+- A capability may supply accepted read-only evidence. Evidence never replaces governance, approval, or deployment checks.
+- CodeGen may generate IaC only after kernel authorization.
+
+## References
+
+- [Compute selection](references/compute-selection.md) - VM/VMSS and family trade-offs.
+- [Pricing evidence](references/pricing-evidence.md) - comparison method and uncertainty rules.
+- [Recommendation and scale rules](references/recommendation-and-scale-rules.md) - source-derived family, VMSS, and
+  evidence rules without price lookup operations.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-compute/references/compute-selection.md

@@ -0,0 +1,26 @@
+# Compute Selection
+
+## Hosting Model
+
+Use a single VM for a distinct, stateful, or individually configured workload. Use VM Scale Sets when the workload has
+an evidenced fleet requirement: interchangeable instances, defined minimum/maximum capacity, and metric or schedule
+scaling. Flexible orchestration suits heterogeneous fleet requirements; record why state, licensing, or networking does
+not prohibit it.
+
+## Family Candidates
+
+Evaluate at least two compatible families when the requirement permits it:
+
+- General purpose for balanced CPU and memory workloads.
+- Compute optimized for sustained CPU-bound work.
+- Memory optimized for memory-bound databases or caches.
+- Storage optimized for high local IOPS or throughput.
+- GPU or HPC families only when an explicit accelerator or interconnect requirement exists.
+
+Do not assert SKU availability, memory, CPU, or feature support from memory. Bind those claims to accepted current
+source evidence for the intended region.
+
+## Recommendation Record
+
+Record workload fit, hosting model, instance count or range, availability design, candidate SKUs, rejected alternatives,
+and unresolved risks. Regional capacity and quota are independent evidence inputs, not inferred from a published SKU.

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

@@ -0,0 +1,11 @@
+# Pricing Evidence
+
+Use the read-only ARM pricing path for current candidate comparison. Match the region, operating system, licensing,
+reservation term, meter, currency, and quantity before comparing prices.
+
+VMSS does not add a separate compute charge: compare the selected VM price multiplied by the accepted capacity model.
+Do not present a unit price as a monthly cost without recording the calculation basis and expected runtime.
+
+A recommendation must state the evidence retrieval time, query scope, candidate SKU, price basis, commitment
+assumption, quantity, and uncertainty. Pricing evidence informs cost trade-offs; it does not choose a SKU, prove quota,
+or authorize procurement.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-compute/references/recommendation-and-scale-rules.md

@@ -0,0 +1,44 @@
+# Compute Recommendation And Scale Rules
+
+Use these rules to form a bounded architecture recommendation. They do not establish regional availability, quota,
+SKU specifications, or price; bind those claims to accepted current evidence.
+
+## Recommendation Inputs
+
+Record workload type, CPU and memory demand, accelerator or local I/O requirements, operating system, region,
+availability target, budget, and expected instance range. Missing inputs are blockers rather than reasons to select a
+default SKU.
+
+## Model And Family Selection
+
+Use a single VM for a distinct, stateful, long-lived, or individually configured workload. Use VM Scale Sets for an
+interchangeable fleet with an evidenced capacity range and metric or schedule-based scaling need. A stateless web or
+API tier, parallel batch work, and homogeneous replicas are scale-set signals; a jump host, domain controller, or
+unique per-instance configuration is a single-VM signal. Prefer Flexible orchestration for a new scale set unless an
+accepted constraint requires Uniform; orchestration mode is a durable design decision.
+
+Select compatible candidates from the workload shape:
+
+- General-purpose families for balanced workloads; burstable families only when the credit and throttling trade-off is
+  acceptable.
+- Compute-optimized families for sustained CPU demand, memory-optimized families for memory-bound data workloads,
+  and storage-optimized families for high local I/O.
+- GPU, confidential-computing, or HPC families only when an explicit accelerator, isolation, or interconnect
+  requirement exists.
+- Treat Spot capacity as interruptible. It is not suitable for work that cannot tolerate eviction.
+
+## Scale And Cost Evidence
+
+For scale sets, record minimum and maximum capacity, scale triggers, cool-down intent, availability design, and the
+load-balancing or work-pull model. Do not infer production availability from a VMSS choice alone.
+
+Compare at least two viable candidates when requirements permit. Cost comparisons must identify region, operating
+system, price type, unit, collection time, candidate SKU, and instance range. VMSS cost is the underlying instance
+cost across its range; include baseline and peak estimates. Retail price lookup is capability-supplied evidence, not a
+skill operation, and a stale or incomplete result blocks a final cost claim.
+
+## Recommendation Record
+
+Record the selected model, candidate families, assumptions, rejected alternatives, capacity range, availability
+intent, current-evidence references, and unresolved risks. Escalate missing quota, capacity, or documentation evidence
+instead of treating published SKU names as deployment feasibility.

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

@@ -0,0 +1,61 @@
+---
+name: apex-azure-cost-optimization
+description: "Assess APEX cost and utilization evidence for savings opportunities. Use for cost optimization, rightsizing, orphan candidates, reservations, and Redis cost review."
+user-invocable: false
+---
+
+# APEX Azure Cost Optimization
+
+Use this skill for an active APEX assessment that evaluates spending and
+utilization evidence. It is advisory only: a capability produces evidence and
+the kernel decides whether a later task may authorize a change.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the target subscriptions, resource boundary,
+  assessment period, currency, and the cost question to answer.
+- Each evidence record identifies its producing capability, observation time,
+  freshness status, target scope, redactions, completeness, and evidence hash.
+- Cost, utilization, inventory, and pricing evidence use compatible scopes and
+  periods. Missing, stale, partial, or scope-mismatched evidence is a blocker.
+
+## Workflow
+
+1. Confirm the target scope and whether the request is portfolio-wide,
+   resource-specific, or Redis-specific. Do not expand the boundary from names,
+   tags, or model memory.
+2. Separate observed cost from observed utilization, validated price context,
+   and calculated savings. A calculated estimate is not an invoice prediction.
+3. Evaluate only evidence-backed candidates using the assessment rules in
+   [cost assessment criteria](references/cost-assessment-criteria.md).
+4. Classify each candidate as `safe to investigate`, `review required`, or
+   `high risk`. State dependencies, uncertainty, evidence hash, and freshness.
+5. Return ranked opportunities, non-actionable observations, and blockers.
+   Send any proposed configuration, purchase, scaling, or deletion decision to
+   the kernel-authorized owning workflow.
+
+## Boundaries
+
+- Do not request, run, or imply external queries, scans, direct reads, pricing
+  lookups, or resource actions. Treat all such observations as scoped
+  capability-produced evidence.
+- Do not treat an orphan candidate, an unused-looking resource, or a missing
+  tag as proof that removal or downsizing is safe.
+- Do not promise savings where pricing evidence is absent, free allowances may
+  apply, shared allocation is uncertain, or the calculation cannot be traced.
+- Escalate evidence that indicates an availability, security, compliance, or
+  active incident concern to the kernel-selected owning assessment.
+
+## Output
+
+Return the target scope, assessment period, evidence hashes and freshness,
+findings, estimated savings with method, uncertainty, classification, and
+kernel-provided next action. Use `indeterminate` when evidence cannot support
+the conclusion.
+
+## References
+
+- [Cost assessment criteria](references/cost-assessment-criteria.md) - evidence
+  rules, heuristics, Redis assessment, classification, and uncertainty.
+- [Operational checklist](references/operational-checklist.md) -
+  normalization, candidate safety, and savings traceability.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-cost-optimization/references/cost-assessment-criteria.md

@@ -0,0 +1,61 @@
+## Evidence Model
+
+Treat cost assessment as a comparison of four distinct evidence classes:
+
+| Evidence class | Establishes | Does not establish |
+| --- | --- | --- |
+| Actual cost | Charged usage in a stated period and scope | Future price or safe removal |
+| Actual utilization | Measured demand during its observation window | Demand outside that window |
+| Validated price context | Applicable rate, allowance, and commitment context | Realized savings without usage evidence |
+| Dependency evidence | Known consumers and attachment state | Absence of all dependencies unless complete |
+
+Every conclusion must carry the evidence hash, producing capability, target
+scope, observation period, freshness, completeness, and redaction boundary.
+Do not combine incompatible subscriptions, currencies, billing periods, or
+utilization windows without stating the normalization and resulting uncertainty.
+
+## General Heuristics
+
+- Prioritize high recurring cost with sustained low utilization only when both
+  measures cover the same target and a representative period.
+- Treat reservation, commitment, or license opportunities as `review required`:
+  forecast, flexibility, and existing commitments can change the result.
+- Treat unattached disks, addresses, snapshots, or similar inventory signals as
+  candidates. Require complete dependency evidence before describing removal as
+  safe to investigate.
+- For very small savings, emphasize operational simplification only when it is
+  evidence-backed; do not inflate financial impact.
+- Account for free allowances, shared services, minimum charges, data transfer,
+  and downstream performance effects before presenting net savings.
+
+## Redis Assessment
+
+Use Redis-specific signals only within the stated cache scope. A failed or
+long-creating cache, premium capacity in non-production, apparently unused
+enterprise capability, oversized non-production capacity, old test usage, or
+missing lifecycle tags are investigation signals, not action approvals.
+
+Require utilization, consumer dependency, environment classification, and
+pricing context before suggesting a tier or capacity change. Missing expiry or
+ownership metadata is a governance observation, not a savings estimate. Mark
+production caches and workloads with unknown latency, persistence, clustering,
+or availability needs as `high risk`.
+
+## Classification And Escalation
+
+| Classification | Evidence threshold | Required handoff |
+| --- | --- | --- |
+| Safe to investigate | Complete scope and reproducible low-risk observation | Authorized assessment or planning workflow |
+| Review required | Savings is plausible but dependencies, demand, or price terms are uncertain | Owner review through the kernel |
+| High risk | Production impact, data durability, availability, or unknown consumer dependency | Owning reliability, security, or service workflow |
+
+When data is stale, truncated, redacted beyond the needed fields, or missing a
+hash, return `indeterminate` and request refreshed scoped evidence through the
+authorized capability.
+
+## Capability Boundary
+
+Live pricing, Resource Graph inventory, billing exports, and source report rendering require separately qualified
+typed producers. Their absence is a blocker, not permission to substitute a browser lookup, terminal command, or a
+reference-only report outline. Keep any requested report as an assessment finding until a registered producer and
+renderer return a receipt.

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

@@ -0,0 +1,24 @@
+# Cost Assessment Operational Checklist
+
+## Normalize Evidence
+
+- Align cost, utilization, inventory, pricing context, currency, and period
+  before comparing candidates. Do not combine incompatible scopes or windows.
+- Separate observed charges, measured utilization, and calculated savings. A
+  modeled saving is not an invoice prediction or a provider commitment.
+- Preserve allocation uncertainty, free allowances, shared-resource effects,
+  and evidence freshness with every estimate.
+
+## Classify Candidates
+
+- Treat orphan-like resources, low utilization, and missing tags as candidates,
+  not removal or downsizing decisions.
+- Classify each evidence-backed item as safe to investigate, review required,
+  or high risk, with dependencies and a traceable estimate method.
+- For Redis-specific observations, retain the service boundary and workload
+  context; no general portfolio conclusion follows from one service signal.
+
+## Handoff
+
+Route purchases, configuration changes, scaling, and deletion to an authorized
+workflow. Escalate availability, security, compliance, or incident signals.