[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PF158GZRDBDWAPQP0EJD6":3,"skill-same:01M71PF158GZRDBDWAPQP0EJD6":92},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":14,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M71PF158GZRDBDWAPQP0EJD6","qa-dashboard",null,"Build and visualize QA dashboards and reports with Allure Report, Grafana, and ReportPortal. Covers test execution visualization, stakeholder-facing quality reports, trend\u002Fflakiness panels, release-readiness gates, alerting, and CI integration for automated report generation. Use when: \"test dashboard,\" \"Allure,\" \"test report,\" \"quality dashboard,\" \"Grafana,\" \"ReportPortal,\" \"test results visualization.\" Not for: defining which KPIs to measure or how to interpret them — use qa-metrics (this skill builds the panels; qa-metrics decides what they should show). Related: qa-metrics, ci-cd-integration, ai-bug-triage.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-dashboard\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"dashboard","qa dashboard","qa","test report","bug","release","trend","how","test execution","reports","grafana","alerting","when","how to","panels","ci","allure","show","which","visualization","2026-11-10 13:02:02",false,"---\nname: qa-dashboard\ndescription: >-\n  Build and visualize QA dashboards and reports with Allure Report, Grafana, and\n  ReportPortal. Covers test execution visualization, stakeholder-facing quality\n  reports, trend\u002Fflakiness panels, release-readiness gates, alerting, and CI\n  integration for automated report generation.\n  Use when: \"test dashboard,\" \"Allure,\" \"test report,\" \"quality dashboard,\"\n  \"Grafana,\" \"ReportPortal,\" \"test results visualization.\"\n  Not for: defining which KPIs to measure or how to interpret them — use qa-metrics\n  (this skill builds the panels; qa-metrics decides what they should show).\n  Related: qa-metrics, ci-cd-integration, ai-bug-triage.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: metrics\n---\n\n\u003Cobjective>\nBuild dashboards that drive decisions, not dashboards that display data. The failure\nmode this prevents: a wall of panels showing \"5 failures\" with no link to the failures,\nno target, and no trend — a notification dressed up as a tool that everyone stops opening\nby week three. This skill delivers audience-specific QA reporting — rich HTML reports\n(Allure), real-time trend panels with regression alerts (Grafana\u002FInfluxDB), self-hosted\nAI-assisted aggregation (ReportPortal), and automated stakeholder summaries — each panel\nmapped to a question someone actually asks and every red indicator drilling down to the\nfailing test.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Already on Grafana for infra metrics | **Grafana Dashboards** — add test metrics alongside prod |\n| Test runner has a hosted dashboard (Cypress\u002FPlaywright) | **SaaS-Native Dashboards** — least plumbing |\n| Need rich HTML report, no infra to run | **Allure Report** — generate in CI, publish artifact |\n| Need self-hosted aggregation across frameworks + AI triage | **ReportPortal** |\n| Need a single view across multiple runners | **Grafana** or **Allure** (cross-runner aggregation) |\n| Need a weekly summary \u002F release verdict for stakeholders | **Stakeholder Reports** |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything answered there. Then:\n\n1. **What tool do you use for test reporting today?** Console output, JUnit XML, HTML reports, or a dedicated platform? Identifies the starting point and how much plumbing is left.\n2. **Who will look at the dashboard?** Developers need failure details and traces; QA leads need trends and flakiness; leadership needs release confidence and defect rates. Each audience needs a different view.\n3. **What decisions should the dashboard drive?** \"Is this build safe to release?\" \"Which tests need fixing?\" \"Is quality improving sprint over sprint?\" Dashboards without a decision context become shelfware.\n4. **Where do test results live?** GitHub Actions artifacts, S3, a database? The storage location determines which dashboard tool is practical.\n5. **What CI platform?** GitHub Actions, GitLab CI, Jenkins? Each has different artifact and reporting integrations.\n\n---\n\n## Core Principles\n\n**1. Dashboards answer questions, they do not display numbers.** Every panel must map to a question someone actually asks. \"What is the flakiness rate?\" is a question. \"Total test count\" is trivia.\n\n**2. Different audiences need different views.** A developer debugging a CI failure needs stack traces, screenshots, and traces. A VP needs a single number: \"Are we ready to release?\" Do not force both through the same dashboard.\n\n**3. Real-time for CI, trends for leadership.** CI dashboards update on every pipeline run. Leadership dashboards aggregate weekly or per-sprint. Mixing cadences confuses both audiences.\n\n**4. Drill-down to action.** Every red indicator must link to the specific failing test, the specific flaky test, or the specific coverage gap. A dashboard that shows \"5 failures\" but does not link to the failures is a notification, not a tool.\n\n**5. Automate report generation.** Reports that require manual effort (running scripts, copying data, formatting slides) will not survive the first busy sprint. Generate reports from CI pipelines automatically.\n\n---\n\n## Allure Report\n\nAllure generates rich HTML reports from test results with history, categories, and retries built in. It works with Playwright, Jest, Vitest, pytest, and most frameworks.\n\n**Allure 2 vs Allure 3.** Two paths, and they are easy to mix up because the framework adapters (`allure-playwright`, `allure-vitest`, `allure-jest`) emit the same Allure 2 result files; only the reader differs:\n\n- **Allure 2 path** — `allure-commandline` (2.42.1, Jun 2026). `brew install allure` installs **this**, not v3. Commands: `allure generate` \u002F `allure open` \u002F `allure serve`; categories via a `categories.json` dropped into `allure-results\u002F`. Stable, frozen, dependency-bump-only now.\n- **Allure 3 path** — `allure` npm package + `allurerc.mjs` (3.9.0, May 2026). TypeScript rewrite: plugins, single-file config, real-time `allure watch`, project-wide quality gates, multi-environment reports, and **Allure Service** for server-side history. Commands: `npx allure run` \u002F `npx allure generate` \u002F `npx allure watch`; categories move into `allurerc.mjs` (the dropped-in `categories.json` is a v2 concept).\n\nChoose Allure 3 for new projects. If you follow only the `brew install allure` \u002F `allure generate` commands you are on the **v2** path — that is fine and fully supported; just know which one you are running.\n\nMinimal Playwright reporter wiring — register the adapter as `reporter: [\"allure-playwright\", { outputFolder, environmentInfo }]` so every run drops results into `allure-results\u002F` with the environment captured:\n\n```typescript\n\u002F\u002F playwright.config.ts\nreporter: [\n  [\"list\"],\n  [\"allure-playwright\", {\n    outputFolder: \"allure-results\",\n    environmentInfo: {\n      Environment: process.env.TEST_ENV ?? \"local\",\n      BaseURL: process.env.BASE_URL ?? \"http:\u002F\u002Flocalhost:3000\",\n    },\n  }],\n],\n```\n\nAdd per-test metadata (`allure.severity` \u002F `feature` \u002F `story` \u002F `tag`) to drive grouping, define failure\n`categories` to split product bugs from infra breakage, and preserve `history\u002F` across CI runs so trends\nexist at all. **Without history an Allure report is a single snapshot — no trends, no intermittent-failure\ndetection.** See `references\u002Fallure.md` for the full Playwright\u002FVitest configs, the v2 `categories.json`,\nthe v3 `allurerc.mjs` + `allure run` runnable path, and the GitHub Actions history-preservation steps.\n\n---\n\n## Grafana Dashboards\n\nGrafana gives real-time dashboards with alerting. Best when the team already runs Grafana for infrastructure and wants test metrics next to production metrics.\n\n**Data pipeline:** a post-test CI step parses results (JUnit XML, coverage JSON, timing) and pushes points to a time-series DB (InfluxDB or a Prometheus pushgateway); Grafana queries those. The push script writes two measurements — `test_execution` (one point per test, tagged by `suite`\u002F`test_name`\u002F`status`\u002F`branch`\u002F`run_id`) and `test_run_summary` (one point per run with `pass_rate`, `total`, `failed`, `avg_duration_ms`). Tag every point with `branch` and `run_id` so panels can filter to `main` and link back to a specific run.\n\nThe script runs under `if: always()`, so wrap the write loop in try\u002Fflush\u002Fclose — a throw mid-loop otherwise loses every buffered point. See `references\u002Fgrafana.md` for the full `push-test-metrics.ts` (with the flush guard) and the GitHub Actions step.\n\n### Recommended panels\n\n| Panel | Question | Query shape |\n|-------|----------|-------------|\n| **Pass Rate Trend** (time series) | Is quality improving? | `SELECT mean(\"pass_rate\") FROM \"test_run_summary\" WHERE \"branch\"='main' GROUP BY time(1d)`, thresholds at 95% (yellow) \u002F 99% (green) |\n| **Release Readiness** (stat) | Is main ready to release? | `SELECT last(\"pass_rate\") FROM \"test_run_summary\" WHERE \"branch\"='main'`, red \u003C95 \u002F yellow 95–99 \u002F green ≥99 — pair with a coverage stat ≥80 |\n| **Flakiness Top 10** (table) | Which tests waste the most time? | `SELECT \"test_name\", count(\"retries\") AS retry_count FROM \"test_execution\" WHERE \"retries\">0 AND time>now()-14d GROUP BY \"test_name\" ORDER BY retry_count DESC LIMIT 10` |\n| **CI Duration Trend** | Is the pipeline getting slower? | `avg_duration_ms` over time with a target line at 600s |\n\nFull queries plus Coverage Trend and Duration Distribution panels are in `references\u002Fgrafana.md`.\n\n### Alerting\n\nProvision alert rules as YAML under `provisioning\u002Falerting\u002F` (Grafana 11+). The one the Done When\nrequires: **main pass rate drops more than 2 percentage points in a single day.** Build it from two\nqueries (mean `pass_rate` over the last `1d` vs the day before) feeding a math expression\n`$yesterday - $today > 2`, then route via a Slack contact point (incoming-webhook URL). The full\nprovisioned rule + contact point is in `references\u002Fgrafana.md`. Also alert on: pass rate below 95%\n(10m window), CI duration above 15 min, coverage drop >2% in a week. **Dashboards are for\ninvestigation; alerts are for detection** — a dashboard no one opens catches nothing.\n\n---\n\n## ReportPortal\n\nSelf-hosted test reporting platform with ML-powered failure analysis, cross-framework aggregation, and real-time dashboards.\n\n```bash\n# Pin to a tagged release (current 26.0.x line: 26.0.3). The `master` branch may not\n# match the supported 26.x line.\ncurl -LO https:\u002F\u002Fraw.githubusercontent.com\u002Freportportal\u002Freportportal\u002F26.0.3\u002Fdocker-compose.yml\ndocker compose up -d\n# Access at http:\u002F\u002Flocalhost:8080 (default: superadmin\u002Ferebus)\n# ML auto-analysis lives in the `service-auto-analyzer` container — confirm it is running.\n```\n\nAs of 26.0.3 ReportPortal also ingests **agentic** test results (launches carry an `AGENTIC` vs\n`AUTOMATION` execution-type badge) — relevant if part of your suite runs through Claude Code or another agent.\n\n### Playwright integration\n\n```typescript\n\u002F\u002F playwright.config.ts\nreporter: [\n  [\"list\"],\n  [\"@reportportal\u002Fagent-js-playwright\", {\n    apiKey: process.env.RP_API_KEY,\n    endpoint: process.env.RP_ENDPOINT ?? \"http:\u002F\u002Flocalhost:8080\u002Fapi\u002Fv1\",\n    project: \"my-project\",\n    launch: `E2E Tests - ${process.env.CI ? \"CI\" : \"local\"}`,\n    attributes: [\n      { key: \"branch\", value: process.env.GITHUB_HEAD_REF ?? \"local\" },\n      { key: \"build\", value: process.env.GITHUB_RUN_ID ?? \"dev\" },\n    ],\n  }],\n],\n```\n\nInstall with `npm i -D @reportportal\u002Fagent-js-playwright`.\n\n| Feature | What it does |\n|---------|--------------|\n| **Auto-analysis** | ML failure classification: product bug, test bug, system issue, or to-investigate |\n| **Defect type mapping** | Custom defect categories with sub-types for your project |\n| **Flaky test detection** | Tests that flip pass\u002Ffail across launches |\n| **Merge launches** | Combine sharded CI runs into one unified view |\n| **Quality gates** | Pass\u002Ffail criteria per launch (max failures, min pass rate) |\n| **Comparison** | Side-by-side of two launches to spot regressions |\n\nQuality gates are queryable after a run (`GET \u002Fapi\u002Fv1\u002F$PROJECT\u002Flaunch\u002F$LAUNCH_ID\u002Fquality-gate`) — use the\nstatus as a CI gate and fail the pipeline if it is not `PASSED`.\n\n### Allure TestOps (managed alternative)\n\nIf self-hosting feels heavy, **Allure TestOps** (26.2.x line, 2026) is the SaaS path: Allure 3 quality\ngates, named environments, global attachments, and Allure 3-style flaky detection (flags a test once it\nshows ≥3 status transitions across its last 10 runs). Its **MCP server is in public beta (26.1.1)**, letting\nAI agents query launches and quality gates directly — relevant when your QA workflow runs through Claude\nCode \u002F Cursor.\n\n---\n\n## SaaS-Native Test Dashboards\n\nIf your test runner has a first-class hosted dashboard, prefer it over Allure\u002FGrafana for that runner's native data — less plumbing, more retention, built-in PR comments. Cross-pollinate with Allure\u002FGrafana only for cross-runner aggregation.\n\n| Platform | Test runner | Native data + PR comments |\n|----------|-------------|---------------------------|\n| **Cypress Cloud** | Cypress | Test replay, parallelization, flake detection; AI add-on (Auto Heal, Bug Triage) |\n| **Currents.dev** | Cypress, Playwright | OSS-friendly Cypress Cloud alternative; lower price point |\n| **Playwright HTML + `--reporter=blob`** | Playwright | Free, self-hosted; combine shards with `merge-reports` |\n| **Datadog Test Optimization** | Any (CI-side) | Flaky Test Management (now with Bits AI auto-fix), TIA, native APM |\n| **Allure TestOps** | Any | Allure 3 quality gates, named environments, MCP server beta |\n\n**Combining sharded Playwright runs (free, native).** Have each shard emit a blob report, then merge into\none HTML report — the no-cost answer to \"combine sharded CI runs\":\n\n```bash\n# each shard: npx playwright test --reporter=blob   (uploads blob-report\u002F as an artifact)\nnpx playwright merge-reports --reporter html .\u002Fblob-reports\n```\n\nUse Allure or Grafana when you need one dashboard across multiple runners, or when a SaaS option's pricing\u002Fdata-residency does not fit. Otherwise the SaaS-native dashboard is usually the cheapest path to PR-level signal.\n\n---\n\n## Stakeholder Reports\n\n**Weekly QA Summary** — automate via a scheduled CI job. Include: pass rate + trend, new vs fixed failures, top 5 flaky tests, coverage delta, avg CI duration. Classify health: STABLE (>= 98%), NEEDS ATTENTION (>= 95%), CRITICAL (\u003C 95%). Post to Slack automatically.\n\n**Release Quality Report** — generate before each release. Gate on: E2E pass rate >= 99%, unit pass rate 100%, branch coverage >= 80%, zero critical bugs, major bugs \u003C= 2, and the Core Web Vitals budget. Output a READY \u002F NOT READY verdict with a per-gate pass\u002Ffail breakdown.\n\nCore Web Vitals \"good\" thresholds for the perf gate (current as of 2026): **LCP \u003C 2500ms, INP \u003C 200ms, CLS \u003C 0.1.** Gate on INP, not FID — INP replaced FID as a Core Web Vital on 2024-03-12 and FID was fully retired on 2024-09-09.\n\n---\n\n## Recommended Dashboard Panels\n\nA practical set covering the most common questions teams ask.\n\n| Panel | Question It Answers | Data Source | Audience |\n|-------|-------------------|-------------|----------|\n| **Pass\u002FFail Trend** | Is quality improving or degrading? | CI test results over time | Everyone |\n| **Flakiness Top 10** | Which tests waste the most time? | Tests with retries in last 14 days | Developers, QA |\n| **Coverage Heatmap** | Where are we blind? | Coverage by module\u002Fdirectory | Developers |\n| **Defect Escape Trend** | Are bugs reaching production? | Incidents tagged as test escapes | QA leads, Leadership |\n| **CI Duration** | Is the pipeline getting slower? | Pipeline duration over time | DevOps, Developers |\n| **Test Velocity** | Tests proportional to features? | New tests added per sprint | QA leads |\n| **Failure Categories** | Product bugs or test infra? | Categorized failure reasons | QA leads |\n| **Release Readiness** | Can we ship? | Composite score from all gates | Leadership |\n\n---\n\n## Anti-Patterns\n\n**Dashboard with 30 panels.** No one reads it. Start with 5–6 panels that answer the most urgent questions; add panels only when someone asks one the dashboard cannot answer.\n\n**Metrics without context.** \"Pass rate: 97%\" means nothing without \"target: 99%\" and \"last week: 98.5%.\" Every metric needs a target and a trend to be actionable.\n\n**Manual report generation.** If the weekly summary needs someone to SSH in, run queries, and paste into slides, it stops happening by week 3. Automate it into CI.\n\n**Same dashboard for developers and leadership.** Developers need failure details, stack traces, and repro steps; leadership needs one traffic light. Build separate views.\n\n**Reporting test counts as progress.** \"We added 200 tests\" says nothing about quality. Report critical-path coverage, defect escape rate, and mean time to detect regressions instead.\n\n**No alerting on regressions.** A dashboard no one checks is useless. Alert on pass-rate drops, coverage decreases, and CI-duration increases. Dashboards are for investigation; alerts are for detection.\n\n**Allure without history.** A single Allure report is a snapshot — no trends, no intermittent-failure detection, no measure of improvement. Always preserve `history\u002F` across CI runs (or use Allure 3 \u002F Allure Service for server-side history).\n\n**Mixing the Allure 2 and 3 code paths.** Following the v3 callout in prose but copying `brew install allure` + `allure generate` + a dropped-in `categories.json` lands you on v2 with v2 categories. Pick one path and use its commands end to end.\n\n---\n\n## Verification\n\nProve the report\u002Fdashboard actually renders before calling it done. Smallest checks first:\n\n```bash\n# Allure: a report builds and the trend widget shows >1 run (history preserved)\nnpx allure generate allure-results --clean -o allure-report && npx allure open allure-report\n#   -> Overview page loads; the \"Trend\" widget shows more than one run.\n\n# Grafana push: the summary point landed in InfluxDB\ninflux query 'from(bucket:\"test-results\") |> range(start:-1d) |> filter(fn:(r)=> r._measurement==\"test_run_summary\")'\n#   -> returns at least one row with a pass_rate field for branch=main.\n\n# Grafana alert: the provisioned rule loaded\ncurl -s http:\u002F\u002Flocalhost:3000\u002Fapi\u002Fv1\u002Fprovisioning\u002Falert-rules -u admin:admin | jq '.[].title'\n#   -> includes \"Main pass rate dropped >2pp in a day\".\n```\n\n---\n\n## Done When\n\n- Dashboard is published to a known location that returns HTTP 200 for the team (CI artifact URL, Grafana URL, or hosted SaaS link) — no local setup or manual report run required.\n- Test execution trends (pass rate, failure count, duration) are visible over at least 2 weeks of historical data.\n- Flakiness panel is configured showing the top flaky tests with retry counts over a rolling 14-day window.\n- A stakeholder report template is generating automatically — **either** a weekly summary with a STABLE\u002FNEEDS ATTENTION\u002FCRITICAL health label **or** a per-release quality report with a READY\u002FNOT READY verdict and per-gate breakdown (one or both is acceptable).\n- An alert is configured and routed (Slack or equivalent) that fires when the main-branch pass rate drops by more than 2 percentage points in a single day.\n\n## Related Skills\n\n- **qa-metrics** — Defining quality KPIs, measurement frameworks, and metric interpretation. Go there to decide *what* to measure; come here to *visualize* it.\n- **ci-cd-integration** — Pipeline configuration for automated report generation and artifact management.\n- **ai-bug-triage** — AI-powered failure classification that feeds into dashboard failure categories.\n\n## Reference Files (in `references\u002F`)\n\n- **allure.md** — full Playwright\u002FVitest adapter configs, per-test metadata, the v2 `categories.json`, the v3 `allurerc.mjs` + `allure run` runnable path, and the CI history-preservation workflow.\n- **grafana.md** — the `push-test-metrics.ts` script (with flush guard), all panel queries, and the provisioned \">2pp pass-rate drop\" alert rule + Slack contact point.\n","\u003Cobjective>\nBuild dashboards that drive decisions, not dashboards that display data. The failure\nmode this prevents: a wall of panels showing \"5 failures\" with no link to the failures,\nno target, and no trend — a notification dressed up as a tool that everyone stops opening\nby week three. This skill delivers audience-specific QA reporting — rich HTML reports\n(Allure), real-time trend panels with regression alerts (Grafana\u002FInfluxDB), self-hosted\nAI-assisted aggregation (ReportPortal), and automated stakeholder summaries — each panel\nmapped to a question someone actually asks and every red indicator drilling down to the\nfailing test.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Already on Grafana for infra metrics | **Grafana Dashboards** — add test metrics alongside prod |\n| Test runner has a hosted dashboard (Cypress\u002FPlaywright) | **SaaS-Native Dashboards** — least plumbing |\n| Need rich HTML report, no infra to run | **Allure Report** — generate in CI, publish artifact |\n| Need self-hosted aggregation across frameworks + AI triage | **ReportPortal** |\n| Need a single view across multiple runners | **Grafana** or **Allure** (cross-runner aggregation) |\n| Need a weekly summary \u002F release verdict for stakeholders | **Stakeholder Reports** |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything answered there. Then:\n\n1. **What tool do you use for test reporting today?** Console output, JUnit XML, HTML reports, or a dedicated platform? Identifies the starting point and how much plumbing is left.\n2. **Who will look at the dashboard?** Developers need failure details and traces; QA leads need trends and flakiness; leadership needs release confidence and defect rates. Each audience needs a different view.\n3. **What decisions should the dashboard drive?** \"Is this build safe to release?\" \"Which tests need fixing?\" \"Is quality improving sprint over sprint?\" Dashboards without a decision context become shelfware.\n4. **Where do test results live?** GitHub Actions artifacts, S3, a database? The storage location determines which dashboard tool is practical.\n5. **What CI platform?** GitHub Actions, GitLab CI, Jenkins? Each has different artifact and reporting integrations.\n\n---\n\n## Core Principles\n\n**1. Dashboards answer questions, they do not display numbers.** Every panel must map to a question someone actually asks. \"What is the flakiness rate?\" is a question. \"Total test count\" is trivia.\n\n**2. Different audiences need different views.** A developer debugging a CI failure needs stack traces, screenshots, and traces. A VP needs a single number: \"Are we ready to release?\" Do not force both through the same dashboard.\n\n**3. Real-time for CI, trends for leadership.** CI dashboards update on every pipeline run. Leadership dashboards aggregate weekly or per-sprint. Mixing cadences confuses both audiences.\n\n**4. Drill-down to action.** Every red indicator must link to the specific failing test, the specific flaky test, or the specific coverage gap. A dashboard that shows \"5 failures\" but does not link to the failures is a notification, not a tool.\n\n**5. Automate report generation.** Reports that require manual effort (running scripts, copying data, formatting slides) will not survive the first busy sprint. Generate reports from CI pipelines automatically.\n\n---\n\n## Allure Report\n\nAllure generates rich HTML reports from test results with history, categories, and retries built in. It works with Playwright, Jest, Vitest, pytest, and most frameworks.\n\n**Allure 2 vs Allure 3.** Two paths, and they are easy to mix up because the framework adapters (`allure-playwright`, `allure-vitest`, `allure-jest`) emit the same Allure 2 result files; only the reader differs:\n\n- **Allure 2 path** — `allure-commandline` (2.42.1, Jun 2026). `brew install allure` installs **this**, not v3. Commands: `allure generate` \u002F `allure open` \u002F `allure serve`; categories via a `categories.json` dropped into `allure-results\u002F`. Stable, frozen, dependency-bump-only now.\n- **Allure 3 path** — `allure` npm package + `allurerc.mjs` (3.9.0, May 2026). TypeScript rewrite: plugins, single-file config, real-time `allure watch`, project-wide quality gates, multi-environment reports, and **Allure Service** for server-side history. Commands: `npx allure run` \u002F `npx allure generate` \u002F `npx allure watch`; categories move into `allurerc.mjs` (the dropped-in `categories.json` is a v2 concept).\n\nChoose Allure 3 for new projects. If you follow only the `brew install allure` \u002F `allure generate` commands you are on the **v2** path — that is fine and fully supported; just know which one you are running.\n\nMinimal Playwright reporter wiring — register the adapter as `reporter: [\"allure-playwright\", { outputFolder, environmentInfo }]` so every run drops results into `allure-results\u002F` with the environment captured:\n\n```typescript\n\u002F\u002F playwright.config.ts\nreporter: [\n  [\"list\"],\n  [\"allure-playwright\", {\n    outputFolder: \"allure-results\",\n    environmentInfo: {\n      Environment: process.env.TEST_ENV ?? \"local\",\n      BaseURL: process.env.BASE_URL ?? \"http:\u002F\u002Flocalhost:3000\",\n    },\n  }],\n],\n```\n\nAdd per-test metadata (`allure.severity` \u002F `feature` \u002F `story` \u002F `tag`) to drive grouping, define failure\n`categories` to split product bugs from infra breakage, and preserve `history\u002F` across CI runs so trends\nexist at all. **Without history an Allure report is a single snapshot — no trends, no intermittent-failure\ndetection.** See `references\u002Fallure.md` for the full Playwright\u002FVitest configs, the v2 `categories.json`,\nthe v3 `allurerc.mjs` + `allure run` runnable path, and the GitHub Actions history-preservation steps.\n\n---\n\n## Grafana Dashboards\n\nGrafana gives real-time dashboards with alerting. Best when the team already runs Grafana for infrastructure and wants test metrics next to production metrics.\n\n**Data pipeline:** a post-test CI step parses results (JUnit XML, coverage JSON, timing) and pushes points to a time-series DB (InfluxDB or a Prometheus pushgateway); Grafana queries those. The push script writes two measurements — `test_execution` (one point per test, tagged by `suite`\u002F`test_name`\u002F`status`\u002F`branch`\u002F`run_id`) and `test_run_summary` (one point per run with `pass_rate`, `total`, `failed`, `avg_duration_ms`). Tag every point with `branch` and `run_id` so panels can filter to `main` and link back to a specific run.\n\nThe script runs under `if: always()`, so wrap the write loop in try\u002Fflush\u002Fclose — a throw mid-loop otherwise loses every buffered point. See `references\u002Fgrafana.md` for the full `push-test-metrics.ts` (with the flush guard) and the GitHub Actions step.\n\n### Recommended panels\n\n| Panel | Question | Query shape |\n|-------|----------|-------------|\n| **Pass Rate Trend** (time series) | Is quality improving? | `SELECT mean(\"pass_rate\") FROM \"test_run_summary\" WHERE \"branch\"='main' GROUP BY time(1d)`, thresholds at 95% (yellow) \u002F 99% (green) |\n| **Release Readiness** (stat) | Is main ready to release? | `SELECT last(\"pass_rate\") FROM \"test_run_summary\" WHERE \"branch\"='main'`, red \u003C95 \u002F yellow 95–99 \u002F green ≥99 — pair with a coverage stat ≥80 |\n| **Flakiness Top 10** (table) | Which tests waste the most time? | `SELECT \"test_name\", count(\"retries\") AS retry_count FROM \"test_execution\" WHERE \"retries\">0 AND time>now()-14d GROUP BY \"test_name\" ORDER BY retry_count DESC LIMIT 10` |\n| **CI Duration Trend** | Is the pipeline getting slower? | `avg_duration_ms` over time with a target line at 600s |\n\nFull queries plus Coverage Trend and Duration Distribution panels are in `references\u002Fgrafana.md`.\n\n### Alerting\n\nProvision alert rules as YAML under `provisioning\u002Falerting\u002F` (Grafana 11+). The one the Done When\nrequires: **main pass rate drops more than 2 percentage points in a single day.** Build it from two\nqueries (mean `pass_rate` over the last `1d` vs the day before) feeding a math expression\n`$yesterday - $today > 2`, then route via a Slack contact point (incoming-webhook URL). The full\nprovisioned rule + contact point is in `references\u002Fgrafana.md`. Also alert on: pass rate below 95%\n(10m window), CI duration above 15 min, coverage drop >2% in a week. **Dashboards are for\ninvestigation; alerts are for detection** — a dashboard no one opens catches nothing.\n\n---\n\n## ReportPortal\n\nSelf-hosted test reporting platform with ML-powered failure analysis, cross-framework aggregation, and real-time dashboards.\n\n```bash\n# Pin to a tagged release (current 26.0.x line: 26.0.3). The `master` branch may not\n# match the supported 26.x line.\ncurl -LO https:\u002F\u002Fraw.githubusercontent.com\u002Freportportal\u002Freportportal\u002F26.0.3\u002Fdocker-compose.yml\ndocker compose up -d\n# Access at http:\u002F\u002Flocalhost:8080 (default: superadmin\u002Ferebus)\n# ML auto-analysis lives in the `service-auto-analyzer` container — confirm it is running.\n```\n\nAs of 26.0.3 ReportPortal also ingests **agentic** test results (launches carry an `AGENTIC` vs\n`AUTOMATION` execution-type badge) — relevant if part of your suite runs through Claude Code or another agent.\n\n### Playwright integration\n\n```typescript\n\u002F\u002F playwright.config.ts\nreporter: [\n  [\"list\"],\n  [\"@reportportal\u002Fagent-js-playwright\", {\n    apiKey: process.env.RP_API_KEY,\n    endpoint: process.env.RP_ENDPOINT ?? \"http:\u002F\u002Flocalhost:8080\u002Fapi\u002Fv1\",\n    project: \"my-project\",\n    launch: `E2E Tests - ${process.env.CI ? \"CI\" : \"local\"}`,\n    attributes: [\n      { key: \"branch\", value: process.env.GITHUB_HEAD_REF ?? \"local\" },\n      { key: \"build\", value: process.env.GITHUB_RUN_ID ?? \"dev\" },\n    ],\n  }],\n],\n```\n\nInstall with `npm i -D @reportportal\u002Fagent-js-playwright`.\n\n| Feature | What it does |\n|---------|--------------|\n| **Auto-analysis** | ML failure classification: product bug, test bug, system issue, or to-investigate |\n| **Defect type mapping** | Custom defect categories with sub-types for your project |\n| **Flaky test detection** | Tests that flip pass\u002Ffail across launches |\n| **Merge launches** | Combine sharded CI runs into one unified view |\n| **Quality gates** | Pass\u002Ffail criteria per launch (max failures, min pass rate) |\n| **Comparison** | Side-by-side of two launches to spot regressions |\n\nQuality gates are queryable after a run (`GET \u002Fapi\u002Fv1\u002F$PROJECT\u002Flaunch\u002F$LAUNCH_ID\u002Fquality-gate`) — use the\nstatus as a CI gate and fail the pipeline if it is not `PASSED`.\n\n### Allure TestOps (managed alternative)\n\nIf self-hosting feels heavy, **Allure TestOps** (26.2.x line, 2026) is the SaaS path: Allure 3 quality\ngates, named environments, global attachments, and Allure 3-style flaky detection (flags a test once it\nshows ≥3 status transitions across its last 10 runs). Its **MCP server is in public beta (26.1.1)**, letting\nAI agents query launches and quality gates directly — relevant when your QA workflow runs through Claude\nCode \u002F Cursor.\n\n---\n\n## SaaS-Native Test Dashboards\n\nIf your test runner has a first-class hosted dashboard, prefer it over Allure\u002FGrafana for that runner's native data — less plumbing, more retention, built-in PR comments. Cross-pollinate with Allure\u002FGrafana only for cross-runner aggregation.\n\n| Platform | Test runner | Native data + PR comments |\n|----------|-------------|---------------------------|\n| **Cypress Cloud** | Cypress | Test replay, parallelization, flake detection; AI add-on (Auto Heal, Bug Triage) |\n| **Currents.dev** | Cypress, Playwright | OSS-friendly Cypress Cloud alternative; lower price point |\n| **Playwright HTML + `--reporter=blob`** | Playwright | Free, self-hosted; combine shards with `merge-reports` |\n| **Datadog Test Optimization** | Any (CI-side) | Flaky Test Management (now with Bits AI auto-fix), TIA, native APM |\n| **Allure TestOps** | Any | Allure 3 quality gates, named environments, MCP server beta |\n\n**Combining sharded Playwright runs (free, native).** Have each shard emit a blob report, then merge into\none HTML report — the no-cost answer to \"combine sharded CI runs\":\n\n```bash\n# each shard: npx playwright test --reporter=blob   (uploads blob-report\u002F as an artifact)\nnpx playwright merge-reports --reporter html .\u002Fblob-reports\n```\n\nUse Allure or Grafana when you need one dashboard across multiple runners, or when a SaaS option's pricing\u002Fdata-residency does not fit. Otherwise the SaaS-native dashboard is usually the cheapest path to PR-level signal.\n\n---\n\n## Stakeholder Reports\n\n**Weekly QA Summary** — automate via a scheduled CI job. Include: pass rate + trend, new vs fixed failures, top 5 flaky tests, coverage delta, avg CI duration. Classify health: STABLE (>= 98%), NEEDS ATTENTION (>= 95%), CRITICAL (\u003C 95%). Post to Slack automatically.\n\n**Release Quality Report** — generate before each release. Gate on: E2E pass rate >= 99%, unit pass rate 100%, branch coverage >= 80%, zero critical bugs, major bugs \u003C= 2, and the Core Web Vitals budget. Output a READY \u002F NOT READY verdict with a per-gate pass\u002Ffail breakdown.\n\nCore Web Vitals \"good\" thresholds for the perf gate (current as of 2026): **LCP \u003C 2500ms, INP \u003C 200ms, CLS \u003C 0.1.** Gate on INP, not FID — INP replaced FID as a Core Web Vital on 2024-03-12 and FID was fully retired on 2024-09-09.\n\n---\n\n## Recommended Dashboard Panels\n\nA practical set covering the most common questions teams ask.\n\n| Panel | Question It Answers | Data Source | Audience |\n|-------|-------------------|-------------|----------|\n| **Pass\u002FFail Trend** | Is quality improving or degrading? | CI test results over time | Everyone |\n| **Flakiness Top 10** | Which tests waste the most time? | Tests with retries in last 14 days | Developers, QA |\n| **Coverage Heatmap** | Where are we blind? | Coverage by module\u002Fdirectory | Developers |\n| **Defect Escape Trend** | Are bugs reaching production? | Incidents tagged as test escapes | QA leads, Leadership |\n| **CI Duration** | Is the pipeline getting slower? | Pipeline duration over time | DevOps, Developers |\n| **Test Velocity** | Tests proportional to features? | New tests added per sprint | QA leads |\n| **Failure Categories** | Product bugs or test infra? | Categorized failure reasons | QA leads |\n| **Release Readiness** | Can we ship? | Composite score from all gates | Leadership |\n\n---\n\n## Anti-Patterns\n\n**Dashboard with 30 panels.** No one reads it. Start with 5–6 panels that answer the most urgent questions; add panels only when someone asks one the dashboard cannot answer.\n\n**Metrics without context.** \"Pass rate: 97%\" means nothing without \"target: 99%\" and \"last week: 98.5%.\" Every metric needs a target and a trend to be actionable.\n\n**Manual report generation.** If the weekly summary needs someone to SSH in, run queries, and paste into slides, it stops happening by week 3. Automate it into CI.\n\n**Same dashboard for developers and leadership.** Developers need failure details, stack traces, and repro steps; leadership needs one traffic light. Build separate views.\n\n**Reporting test counts as progress.** \"We added 200 tests\" says nothing about quality. Report critical-path coverage, defect escape rate, and mean time to detect regressions instead.\n\n**No alerting on regressions.** A dashboard no one checks is useless. Alert on pass-rate drops, coverage decreases, and CI-duration increases. Dashboards are for investigation; alerts are for detection.\n\n**Allure without history.** A single Allure report is a snapshot — no trends, no intermittent-failure detection, no measure of improvement. Always preserve `history\u002F` across CI runs (or use Allure 3 \u002F Allure Service for server-side history).\n\n**Mixing the Allure 2 and 3 code paths.** Following the v3 callout in prose but copying `brew install allure` + `allure generate` + a dropped-in `categories.json` lands you on v2 with v2 categories. Pick one path and use its commands end to end.\n\n---\n\n## Verification\n\nProve the report\u002Fdashboard actually renders before calling it done. Smallest checks first:\n\n```bash\n# Allure: a report builds and the trend widget shows >1 run (history preserved)\nnpx allure generate allure-results --clean -o allure-report && npx allure open allure-report\n#   -> Overview page loads; the \"Trend\" widget shows more than one run.\n\n# Grafana push: the summary point landed in InfluxDB\ninflux query 'from(bucket:\"test-results\") |> range(start:-1d) |> filter(fn:(r)=> r._measurement==\"test_run_summary\")'\n#   -> returns at least one row with a pass_rate field for branch=main.\n\n# Grafana alert: the provisioned rule loaded\ncurl -s http:\u002F\u002Flocalhost:3000\u002Fapi\u002Fv1\u002Fprovisioning\u002Falert-rules -u admin:admin | jq '.[].title'\n#   -> includes \"Main pass rate dropped >2pp in a day\".\n```\n\n---\n\n## Done When\n\n- Dashboard is published to a known location that returns HTTP 200 for the team (CI artifact URL, Grafana URL, or hosted SaaS link) — no local setup or manual report run required.\n- Test execution trends (pass rate, failure count, duration) are visible over at least 2 weeks of historical data.\n- Flakiness panel is configured showing the top flaky tests with retry counts over a rolling 14-day window.\n- A stakeholder report template is generating automatically — **either** a weekly summary with a STABLE\u002FNEEDS ATTENTION\u002FCRITICAL health label **or** a per-release quality report with a READY\u002FNOT READY verdict and per-gate breakdown (one or both is acceptable).\n- An alert is configured and routed (Slack or equivalent) that fires when the main-branch pass rate drops by more than 2 percentage points in a single day.\n\n## Related Skills\n\n- **qa-metrics** — Defining quality KPIs, measurement frameworks, and metric interpretation. Go there to decide *what* to measure; come here to *visualize* it.\n- **ci-cd-integration** — Pipeline configuration for automated report generation and artifact management.\n- **ai-bug-triage** — AI-powered failure classification that feeds into dashboard failure categories.\n\n## Reference Files (in `references\u002F`)\n\n- **allure.md** — full Playwright\u002FVitest adapter configs, per-test metadata, the v2 `categories.json`, the v3 `allurerc.mjs` + `allure run` runnable path, and the CI history-preservation workflow.\n- **grafana.md** — the `push-test-metrics.ts` script (with flush guard), all panel queries, and the provisioned \">2pp pass-rate drop\" alert rule + Slack contact point.\n",{"name":5,"license":15,"metadata":57,"description":7},{"author":58,"version":59,"category":60},"kindlmann","2.0","metrics","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fqa-dashboard","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add pattanation\u002FNorvik --skill qa-dashboard",{"tool":74,"command":75},"bunx","bunx skills add pattanation\u002FNorvik --skill qa-dashboard",{"tool":77,"command":78},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill qa-dashboard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-dashboard\u002FSKILL.md",true,[82,88],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fallure.md","REFERENCE","参考文档",6780,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-dashboard\u002Freferences\u002Fallure.md",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fgrafana.md",6235,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-dashboard\u002Freferences\u002Fgrafana.md",[93,123,149,172,194,209],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":97,"licenseFileUrl":98,"sourceHtmlUrl":99,"categories":100,"keywords":105,"publishedAt":52},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[101,102],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"webapp","testing","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":97,"licenseFileUrl":127,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":52},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[130],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[132,133,134,119,135,136,137,109,138,139,112,140,141,142,143,144,145,146,147,148],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":153,"sourceHtmlUrl":154,"categories":155,"keywords":157,"publishedAt":52},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[156],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[158,159,160,161,162,163,164,165,166,167,168,169,170,171],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":176,"sourceHtmlUrl":177,"categories":178,"keywords":181,"publishedAt":52},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[179,180],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[182,107,183,169,184,118,185,186,187,164,188,109,189,190,191,141,192,170,193],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":198,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":52},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[201],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[203,169,204,184,205,187,206,164,192,207,208],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":213,"sourceHtmlUrl":214,"categories":215,"keywords":217,"publishedAt":52},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[216],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[218,169,184,219,161,220,221,222,203,223,224,225,226,227,228,109,229,141,230,231],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]