@apexops/cli 0.10.0-next.5 → 0.11.0-next.1

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

@@ -1,55 +0,0 @@
----
-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

@@ -1,29 +0,0 @@
-# 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

@@ -1,27 +0,0 @@
-# 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

@@ -1,26 +0,0 @@
-# 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

@@ -1,27 +0,0 @@
-# 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

@@ -1,58 +0,0 @@
----
-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

@@ -1,63 +0,0 @@
-## 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

@@ -1,24 +0,0 @@
-# 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

@@ -1,36 +0,0 @@
----
-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

@@ -1,26 +0,0 @@
-# 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

@@ -1,11 +0,0 @@
-# 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

@@ -1,44 +0,0 @@
-# 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

@@ -1,61 +0,0 @@
----
-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

@@ -1,61 +0,0 @@
-## 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

@@ -1,24 +0,0 @@
-# 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.

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

@@ -1,59 +0,0 @@
----
-name: apex-azure-defaults
-description: "Applies projected Azure defaults safely in APEX decisions. Use for region fallback, CAF naming, tags, security, service lifecycle, AVM bindings, network planning, governance effects, and cost monitoring."
-user-invocable: false
----
-
-# APEX Azure Defaults
-
-Use this skill only for an active APEX task. Accepted governance constraints and runtime configuration are
-authoritative. Task context supplies only the values actually provided for the active task. This skill does not define
-customer policy, discover Azure state, or execute Azure operations.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the active workload, environment, target, and IaC track.
-- Governance, availability, pricing, quota, and module evidence required by the decision is accepted and current.
-- A kernel capability owns any lookup, validation, or state change the decision requires.
-
-## Precedence
-
-Apply accepted governance first, then explicit requirements and decisions, then runtime configuration. Use a baseline
-fallback only when accepted evidence establishes that no stronger contract applies. Incomplete discovery is not the
-same as an empty policy result.
-
-## Decision Workflow
-
-1. Use the environment and target only when the active task context provides them; otherwise return a blocker. Do not
-  infer a region, subscription, tag, or policy requirement from chat history.
-2. Resolve conflicts through the precedence rule and preserve the governing evidence identifier.
-3. Select service, region, network, identity, module, monitoring, and naming intent from accepted inputs.
-4. Record every fallback, exception, unknown, and deferred decision with requirement and evidence traceability.
-5. Check the bounded decision for policy coverage, lifecycle support, region/SKU fit, security, repeatability, and cost.
-6. If the check exposes a gap, revise the decision and repeat. If evidence or capability is absent, return a blocker.
-
-## References
-
-- Read [baseline fallbacks](references/baseline-fallbacks.md) only when accepted evidence permits fallback behavior.
-- Read [naming guidance](references/naming.md) when binding resource names or uniqueness inputs.
-- Read [tag precedence](references/tag-precedence.md) when policy, inheritance, casing, or fallback tags are relevant.
-- Read [security baseline](references/security-baseline.md) for identity, exposure, encryption, lifecycle, and diagnostics.
-- Read [AVM binding guidance](references/avm-binding-guidance.md) when choosing or excepting a module.
-- Read [service selection](references/service-selection.md) when comparing Azure service classes or WAF trade-offs.
-- Read [governance effects](references/governance-effects.md) when translating accepted policy into decisions.
-- Read [network planning](references/network-planning.md) when a workload requires VNet attachment or private access.
-- Read [cost monitoring](references/cost-monitoring.md) when planning budgets, alert routing, anomaly detection, or cost
-  evidence.
-- [Decision boundaries](references/decision-boundaries.md) - fallback order, matrix use, and deferred evidence.
-
-## Capability Boundaries
-
-- Do not query Azure, registries, documentation, prices, quotas, identities, or repositories from this skill.
-- Do not select a mutable version, SKU, region, price, retirement date, or provider limit from memory.
-- Do not emit Bicep, Terraform, shell commands, policy exemptions, role assignments, or deployment actions.
-- Treat missing discovery, resolver, pricing, networking, or validation capability as a blocker, not permission to guess.
-
-## Output
-
-Return bounded architecture, plan, or binding decisions with requirement IDs, evidence identifiers, source precedence,
-exceptions, unknowns, deferrals, and blockers. Never turn absent evidence into a default or a successful validation.