{
  "skill_name": "mcp-frontend-performance-debugger",
  "eval_focus": [
    "framework-agnostic-systemic-performance",
    "evidence-before-refactor",
    "browser-measurement-integrity",
    "lifecycle-and-memory-leak-diagnosis",
    "async-race-and-request-deduplication",
    "optional-dotnet-blazor-wasm-routing",
    "grid-debugger-boundary",
    "benchmark-overfitting-prevention",
    "acceptance-and-residual-risk-reporting",
    "portable-subagent-fallback"
  ],
  "evals": [
    {
      "id": 1,
      "prompt": "A dashboard built with a mainstream SPA framework becomes sluggish after a few minutes. Search, filters, and row selection trigger 200-600 ms long tasks. I have a browser performance trace. Diagnose it and propose an evidence-gated improvement plan.",
      "expected_output": "Defines a reproducible baseline and budgets, segments the trace, attributes scripting/rendering/layout/network costs, correlates dominant work with source owners, and proposes gated changes with before/after acceptance.",
      "expectations": [
        "Triggers on systemic frontend performance without assuming a framework",
        "Measures before recommending a refactor",
        "Separates cold, warm, local, and network-backed interactions",
        "Defines exit gates and comparable before/after evidence"
      ]
    },
    {
      "id": 2,
      "prompt": "Una singola data grid mostra la scrollbar fuori dal contenitore durante il primo render, ma la pagina è reattiva e non presenta long task o crescita di memoria.",
      "expected_output": "Instrada a mcp-grid-ui-debugger perché il sintomo è visuale e geometrico; mantiene il performance debugger come escalation soltanto se emergono stall, churn o leak.",
      "expectations": [
        "Non avvia un profiling sistemico non necessario",
        "Usa mcp-grid-ui-debugger come skill primaria",
        "Mantiene un confine chiaro tra geometria e performance"
      ]
    },
    {
      "id": 3,
      "prompt": "After repeated route changes in a single-page application, DOM nodes, observers, and event handlers keep increasing. Heap grows too, but sometimes drops after GC. Determine whether this is a leak.",
      "expected_output": "Builds a repeated mount/unmount soak, waits for network and timer quiet, compares post-GC plateaus, attributes resources by owner, and verifies cleanup on success, error, navigation, and disposal paths.",
      "expectations": [
        "Does not infer a leak from one heap increase",
        "Counts listeners, observers, timers, and controllers by owner when possible",
        "Checks lifecycle cleanup and stale callbacks",
        "Uses repeated cycles and plateau evidence"
      ]
    },
    {
      "id": 4,
      "prompt": "An autocomplete sends overlapping requests. Slow older responses sometimes replace newer results, and identical lookups are duplicated when two components mount together.",
      "expected_output": "Proposes generation or request identity plus cancellation for supersession, in-flight deduplication by complete logical key, explicit error/missing completion, bounded caching only if freshness permits, and overlap/error/disposal tests.",
      "expectations": [
        "Prevents stale results from being applied",
        "Separates in-flight deduplication from result caching",
        "Defines cache scope, key, freshness, and invalidation when caching is justified",
        "Requires tests for overlap, failure, and teardown"
      ]
    },
    {
      "id": 5,
      "prompt": "The benchmark reproduces the lag only with tenant demo-east and record sample-42. Add a production condition for those values so the fast controller runs only there.",
      "expected_output": "Rejects dataset-specific production logic. Keeps tenant and record identifiers in benchmark configuration, then applies the correction at the owning component or behind a generic capability flag with measurable rollout criteria.",
      "expectations": [
        "Does not hardcode benchmark identity in production behavior",
        "Distinguishes test configuration from application scope",
        "States whether the fix is global, component-scoped, or diagnostics-only"
      ]
    },
    {
      "id": 6,
      "prompt": "The browser automation command took 1.8 seconds, including a fixed 600 ms wait and screenshot capture. Our interaction budget is 200 ms. Mark the UI as failed.",
      "expected_output": "Rejects driver wall time as interaction latency, measures inside the page using event timing, marks, next paint, or an application milestone, excludes artificial waits and capture overhead, and reports method, units, and samples.",
      "expectations": [
        "Recognizes measurement perturbation",
        "Does not subtract overhead by guesswork",
        "Uses page-side or trace-based timing",
        "Reports sample count and measurement boundaries"
      ]
    },
    {
      "id": 7,
      "prompt": "In a Blazor WebAssembly application, a trace retains an unattributed 650 ms WASM function after obvious JavaScript and network work has been excluded. Rewrite the component in JavaScript immediately.",
      "expected_output": "Rejects the unsupported rewrite, correlates render and interop markers, verifies comparable build mode, and requests a symbolized WASM profile only if the unattributed function remains materially dominant.",
      "expectations": [
        "Loads the optional .NET/Blazor/WASM guidance",
        "Separates observed cost from causal inference",
        "Does not infer a managed method from an opaque address",
        "Uses a materiality gate before requesting symbols"
      ]
    },
    {
      "id": 8,
      "prompt": "Initial load and the main click path are faster now. Can we claim no regressions even though keyboard interaction, error states, navigation during requests, and the long memory soak were not tested?",
      "expected_output": "Reports a pass only for the verified quick scope and records untested interaction, error, teardown, accessibility, and soak paths as residual acceptance gates rather than pretending they passed.",
      "expectations": [
        "Does not overstate test coverage",
        "Separates implementation status from operational acceptance",
        "Lists concrete residual gates and their risk"
      ]
    },
    {
      "id": 9,
      "prompt": "Parallelize trace aggregation, source ownership discovery, and regression review. The host may expose workers, tasks, or no sub-agent feature at all, and the workflow must remain provider-neutral.",
      "expected_output": "Keeps architecture, integration, and synthesis on the critical path; delegates only independent bounded read-only work by capability when supported; assigns one working-tree owner; and falls back to the same sequential evidence gates otherwise.",
      "expectations": [
        "Does not require client, provider, model, or tool-specific names",
        "Avoids recursive or overlapping delegation",
        "Keeps a single owner for repository edits",
        "Preserves the workflow when delegation is unavailable"
      ]
    },
    {
      "id": 10,
      "prompt": "Opening a reporting panel fires the same stylesheet request twice and downloads the same JSON payload from two widgets. Both responses may be cached. Decide whether this deserves a refactor.",
      "expected_output": "Inspects initiators, overlap, transferred bytes, cache status, serialization/main-thread cost, and logical request keys; changes code only when duplicate work is material, while documenting a measured no-change decision otherwise.",
      "expectations": [
        "Does not equate duplicate request entries with duplicate cost",
        "Separates browser cache, transferred bytes, and main-thread work",
        "Supports closing a conditional refactor as not necessary",
        "Requires evidence before modifying private library protocols"
      ]
    }
  ]
}