Claude Skills by VirtoCommerce

[QA Method] Risk-based test prioritization: risk matrix, severity classification, dynamic reprioritization, test depth allocation.

[VC Knowledge] Documentation lookup via VirtoOZ MCP (primary) or Context7 (fallback): architecture, modules, APIs, deployment, B2B.

On-demand self-diagnostician orchestrator for the vc-fix plugin (Tier 2 of the client→vendor feedback loop). It SPAWNS the `self-check-diagnostician` subagent to read this session's telemetry jsonl + transcript + the skill-expectations oracle and return a validated finding STRUCT — the oracle, jsonl and transcript never enter the main conversation. The orchestrator then relays a SHORT summary (the exact fields that would be sent), and if ≥1 finding is BROKEN/DEGRADED asks ONE binary AskUserQu...

[Development] Fix a Virto Commerce module's embedded Vue 3 \"shell\" sub-app (@vc-shell/framework, e.g. vc-module-pagebuilder's src/VirtoCommerce.PageBuilderModule.Web/Apps/page-builder-shell/) declared in skills/qa-fix-routing/fix-repos.json moduleFrontendSubApps. State/logic bugs (composable/store/service function) are proven red→green with the sub-app's OWN real `tsx --test` runner + plain Vue reactivity (ref/computed/watch/effectScope) — no stubbing needed, unlike angular-admin's scratch ...

[Development] Implement a minimal, idiomatic Vue 3 / TypeScript fix in the vc-frontend storefront that turns the reproduction test green while preserving BL-UI invariants and component contracts and leaving existing tests/stories untouched. Used by the fullstack-frontend developer agent in /qa-fix (Gate 3).

[Development] Reproduce a Virto Commerce vc-frontend storefront bug as a failing vitest test (red), then prove the fix turns it green — without modifying existing tests or stories. Used by the fullstack-frontend developer agent in the /qa-fix pipeline (Gate 2/G3).

Run VirtoCommerce x-module BenchmarkDotNet suites (the XAPI targets configured in perf.benchmark.xapiTargets) and turn two runs into a machine-readable performance verdict. Use to check whether a change regressed allocations or time across two revisions of this module's own source, between this module's override and the upstream stock path, or across an upstream before/after. Advisory only — never a CI gate.

Run the L2 k6 load harness against the live Aspire-hosted backend and produce a summary + optional dotnet-counters CSV. Use to answer "how does the running system behave under load" — throughput, p95 latency, GC pressure — as opposed to L1 (BenchmarkDotNet, code-level) or L3 (dotnet-trace, attribution).

Orchestrates the three-layer performance loop (bench → load → diagnose → optimize → verify) on the local Aspire-hosted backend. Use when the user asks to "run the perf loop", "load test X", "profile the backend", "where do the allocations come from", "why is this operation slow", or to verify a performance fix end-to-end. Routes to the right layer and tool; does not duplicate them. For pure BenchmarkDotNet before/after comparison use `perf-benchmark` directly.

Capture a dotnet-trace / dotnet-counters session against the live backend and parse it with perftools (allocparse/cpuparse/dbparse) to attribute WHO is responsible for what L2 observed. Use when you know load behaves a certain way (L2) and need to find the responsible code — allocation churn, on-CPU time, or DB command shape.