[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PFBDGKAQ0P3MB90VMGQN6":3,"skill-same:01M71PFBDGKAQ0P3MB90VMGQN6":78},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M71PFBDGKAQ0P3MB90VMGQN6","qa-metrics",null,"Define, track, and act on QA metrics: test coverage percentage, flakiness rate, defect escape rate, MTTR, test execution time trends, automation ROI, quality gates, and SLAs for test suites. Includes metric formulas, realistic targets by company stage, and the action to take when each metric goes red. Use when: \"QA metrics,\" \"test metrics,\" \"quality KPIs,\" \"test health,\" \"flakiness rate,\" \"defect escape rate.\" Not for: building the dashboard UI (Allure\u002FGrafana) — use qa-dashboard; measuring coverage gaps and mutation score — use coverage-analysis. Related: qa-dashboard, coverage-analysis, ci-cd-integration, release-readiness, quality-postmortem.","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-metrics\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"qa","metrics","qa metrics","mttr","for","formulas","ci-cd","ui","act","rate","take","release","test coverage","test execution","track","grafana","mutation","ci","company","time","2026-11-10 13:02:02",false,"---\nname: qa-metrics\ndescription: >-\n  Define, track, and act on QA metrics: test coverage percentage, flakiness rate, defect\n  escape rate, MTTR, test execution time trends, automation ROI, quality gates, and SLAs\n  for test suites. Includes metric formulas, realistic targets by company stage, and the\n  action to take when each metric goes red.\n  Use when: \"QA metrics,\" \"test metrics,\" \"quality KPIs,\" \"test health,\" \"flakiness rate,\"\n  \"defect escape rate.\"\n  Not for: building the dashboard UI (Allure\u002FGrafana) — use qa-dashboard; measuring coverage\n  gaps and mutation score — use coverage-analysis.\n  Related: qa-dashboard, coverage-analysis, ci-cd-integration, release-readiness, quality-postmortem.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: metrics\n---\n\n\u003Cobjective>\nA suite with 4,000 tests where 800 are disabled and 200 are flaky looks healthy on a slide and lies in production. This skill defines the metrics that actually change behavior — each one with a formula, a target, an owner, and a concrete action when it goes red — so the dashboard becomes a feedback loop instead of decoration.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Your situation | Metric to reach for | Section \u002F reference |\n|---|---|---|\n| No metrics yet, where to start | code coverage, flakiness, defect escape | Core Principles + `references\u002Frollout.md` |\n| Bugs escaping despite high coverage | defect escape rate + mutation score | Coverage Metrics, Defect Metrics |\n| Tests flaky, devs ignore CI | flakiness rate, pass rate | Test Health Metrics |\n| Slow pipeline, stale feedback | suite duration, parallelism efficiency | Execution Metrics |\n| Justifying automation spend | automation ROI | Process Metrics |\n| Picking targets for our stage | company-stage table | Setting Realistic Targets |\n| Leadership wants delivery + quality | DORA + escape rate | Engineering Quality Metrics (DORA) |\n| Building the dashboard view | (go to `qa-dashboard`) | — |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it as the foundation and skip anything already answered there. Then:\n\n### Current State\n- What metrics are you tracking today? (Even \"we glance at CI pass rate sometimes\" counts.)\n- Where does your test data live? (CI system, coverage reports, bug tracker, spreadsheets, nowhere)\n- Do you have any dashboards already? Who looks at them, and how often?\n- What tooling runs your CI pipeline? (GitHub Actions, GitLab CI, Jenkins, CircleCI)\n\n### Stakeholders\n- Who are the stakeholders for quality metrics? (engineering, product, leadership, customers)\n- What does each care about? Engineers want flakiness; leadership wants escape trends; product wants release confidence.\n- Who will own each metric? If nobody owns it, nobody acts on it.\n\n### Quality Problems\n- What quality problems need visibility? (regressions, slow pipelines, flaky tests, coverage gaps, incidents)\n- What broke in production recently? Would a metric have caught it earlier?\n- What decisions are you making without data today?\n\n### Goals\n- What does \"healthy test suite\" mean for your team?\n- Any compliance or contractual quality requirements? (SLAs, SOC2, ISO)\n- Quick wins vs. full observability — what is the appetite for metrics infrastructure?\n\n---\n\n## Core Principles\n\n### 1. Metrics Should Drive Action, Not Just Dashboards\nA metric without an action plan is decoration. For every metric, define: what threshold triggers action, what the action is, and who takes it. If flakiness crosses 5%, the on-call engineer investigates the top 3 flaky tests that week. No ambiguity.\n\n### 2. Leading vs Lagging — Track Both, Act on Leading\nDefect escape rate and MTTR are **lagging**: you learn after users were hurt. Flakiness, coverage delta, and skipped-test count are **leading**: they predict escapes before they happen. Lagging metrics tell leadership whether quality is moving; leading metrics are where engineers spend their daily attention because they can still change the outcome.\n\n### 3. Trend Over Snapshot\nA single number is nearly useless. Coverage at 72% means nothing; coverage trending 68% → 72% over three sprints tells a story. Display metrics as time series and evaluate direction, not absolute position.\n\n### 4. Every Metric Needs a Target and an Owner\nA target makes a metric actionable; an owner makes it accountable. Without both it becomes background noise. Set targets from your team's maturity (see the targets table) and assign owners who can actually move the number.\n\n### 5. Vanity Metrics Waste Everyone's Time\n\"We have 4,000 tests\" sounds impressive until 800 are disabled and 200 flaky. Count what matters: tests that run, pass reliably, and catch real bugs. The ultimate metric is whether users hit bugs that hurt the business — work backward from there. Defect escape rate connects directly to user experience; lines of test code connects to nothing.\n\n---\n\n## Essential QA Metrics\n\nEach metric: definition, formula, recommended target, why it matters, and the action when it goes red.\n\n### Test Coverage Metrics\n*How much of our system is verified by automated tests?* (leading)\n\n#### Code Coverage Percentage\nThe percentage of code exercised by automated tests (line, branch, or statement level).\n\n```\nLine coverage   = (lines executed by tests \u002F total executable lines) × 100\nBranch coverage = (branches executed by tests \u002F total branches) × 100\n```\n\n**Targets:** Line: 70-85% for app code. Branch: 60-75%. Critical paths (payments, auth): 90%+.\n\n**Why it matters:** Coverage identifies blind spots — code never exercised by tests is where bugs hide undetected.\n\n**When it goes red:** Coverage drops on PR: block merge or flag. Low in critical module: create targeted tasks. Plateaus: check for dead code vs. genuinely untested logic.\n\n**Warning:** Coverage measures execution, not assertion quality. Pair it with mutation testing (StrykerJS v9.6+, mutmut) for a truer picture. Stryker's Vitest runner tracks recent Vitest releases — check the runner's peer-dependency before pinning a Vitest version. Use `incremental: true` in monorepo CI to keep mutation runs cheap. For deep coverage\u002Fmutation analysis, see `coverage-analysis`.\n\n#### Requirement Coverage Percentage\n```\nRequirement coverage = (features with at least one test \u002F total features) × 100\n```\n**Targets:** 100% for P0\u002FP1 features, 80%+ for P2.\n\n**Why it matters:** A feature can have zero tests even if surrounding code is well-covered. Use test tags (`@feature:checkout`, `@story:PROJ-1234`) for traceability.\n\n#### Risk Coverage Percentage\n```\nRisk coverage = (high-risk areas with automated tests \u002F total high-risk areas) × 100\n```\n**Targets:** 95%+ for high-risk areas. Maintain a risk register and cross-reference against coverage data per module.\n\n---\n\n### Test Health Metrics\n*Can we trust our test suite?* (leading)\n\n#### Flakiness Rate\nThe percentage of test runs producing inconsistent results without code changes.\n\n```\nFlakiness rate = (test runs with flaky results \u002F total test runs) × 100\n```\n\n**Targets:** Acceptable: \u003C2%. Warning: 2-5%. Critical: >5%.\n\n**Why it matters:** Flaky tests erode trust. Once developers think \"probably just flaky,\" they stop paying attention to results at all. Flakiness is the single biggest threat to a suite's credibility.\n\n**When it goes red:** Quarantine flaky tests immediately. Investigate the top 3 weekly — most flakiness comes from a small number of tests. Common causes: timing\u002Frace conditions, shared state, external dependencies, order-dependent tests. Tests flaky for 30+ days should be deleted or rewritten.\n\n**Detection:** Buildkite Test Analytics, **Datadog Test Optimization** (formerly Datadog CI Visibility — ships Flaky Test Management, Auto Test Retries, Early Flake Detection, Failed Test Replay, and Test Impact Analysis; its Bits AI Dev Agent can auto-open PRs to fix flaky tests), Trunk Flaky Tests, or a script comparing results across runs on the same commit.\n\n#### Pass Rate Trend (7-Day Rolling)\n```\nPass rate = (green CI runs \u002F total CI runs) × 100  [rolling 7 days]\n```\n**Targets:** Healthy: >95%. Warning: 90-95%. Broken: \u003C90%.\n\nThe 7-day rolling average smooths daily noise and reveals the real trend. A consistently red build means developers ignore the pipeline.\n\n#### Disabled and Skipped Test Count\nTotal tests marked `skip`, `disabled`, `pending`, `xit`, `xdescribe` or equivalent.\n\n**Target:** Trend toward zero. Skipped tests older than 2 sprints: fix or delete. Add a CI step that fails if skipped count exceeds 5% of total tests.\n\n**Why it matters:** Skipped tests are invisible coverage gaps. A suite with 500 passing and 150 skipped tests has a `150 \u002F (500 + 150) = 23%` gap that dashboards hide.\n\n#### Test Suite Duration\nWall-clock time from suite start to completion.\n\n**Targets:** Unit: \u003C5 min. Integration: \u003C10 min. E2E: \u003C15 min. Full pipeline: \u003C30 min (the stage targets are the real budget; \u003C30 min is the sum, not a separate looser bar).\n\n**Why it matters:** Slow tests break the feedback loop. 45-minute results mean developers have already context-switched.\n\n**When it goes red:** Profile slowest tests (10% often account for 50% of runtime). Increase parallelism. Move slow tests post-merge. Check for unnecessary setup\u002Fteardown. Plot duration over time and alert on step changes (>20% increase in a week).\n\n---\n\n### Defect Metrics\n*Are we catching bugs before users do?* (lagging)\n\n#### Defect Escape Rate\nThe percentage of defects found in production relative to all defects found.\n\n```\nDefect escape rate = (defects found in production \u002F total defects found) × 100\n```\n\n**Targets:** Excellent: \u003C5%. Acceptable: 5-10%. Needs work: 10-20%. Critical: >20%.\n\n**Worked example:** A release surfaces 15 total defects, 2 of them in production → `2 \u002F 15 × 100 = 13.3%` escape rate, which lands in \"needs work.\"\n\n**Why it matters:** The single most important quality metric. It directly measures whether testing catches bugs before users do.\n\n**When it goes red:** Classify escaped defects by layer (unit? integration? E2E? review?). Write a retrospective test for each. Identify if escapes cluster in specific areas — those need targeted investment.\n\n**How to track:** Tag production bugs (`escaped-defect` label). Count escaped vs. pre-release defects at sprint retros.\n\n#### Mean Time To Resolution (MTTR)\n```\nMTTR = sum(resolution_time for each defect) \u002F number of defects\n```\n**Targets:** P0: \u003C4 hours. P1: \u003C24 hours. P2: \u003C1 sprint. P3: \u003C2 sprints.\n\nHigh MTTR often signals process bottlenecks (slow review, unclear ownership, complex deploys) rather than technical difficulty. Break into phases (triage, assign, fix, deploy) to find the bottleneck. (This is your QA *defect* resolution time — distinct from the DORA recovery metric below.)\n\n#### Defect Density\n```\nDefect density = defects found \u002F KLOC  (or per feature shipped)\n```\n**Targets:** Track your own baseline; industry benchmarks are 1-10 defects per KLOC. If one module has 5x the density of others, it needs refactoring or better coverage.\n\n#### Severity Distribution\nHealthy: P0 \u003C5%, P1 10-15%, P2 40-50%, P3 30-40%. Visualize as a stacked bar over time. Heavy P0\u002FP1 concentration means testing misses critical issues.\n\n---\n\n### Execution Metrics\n*Is our CI pipeline fast, reliable, and cost-effective?* (leading)\n\n#### CI Pipeline Duration\nTotal wall-clock time by stage. **Targets:** Lint: \u003C2 min. Unit: \u003C5 min. Integration: \u003C10 min. E2E: \u003C15 min. Full: \u003C30 min (= sum of stages above, reconciled with the suite-duration budget).\n\n**When it goes red:** Optimize the slowest stage first. Split fast checks (every push) from slow checks (PR merge). Profile setup time vs. execution time. Parallelize sequential stages.\n\n#### CI Cost Per Run\n```\nCI cost per run = (compute minutes × cost per minute) + fixed costs\n```\n50 builds\u002Fday at $0.50 each = $750\u002Fmonth. Optimize by caching dependencies, using spot instances, right-sizing runners, and skipping unchanged suites.\n\n#### Parallelism Efficiency\n```\nParallelism efficiency = (total sequential time \u002F (wall-clock time × workers)) × 100\n```\n**Target:** >80%. Example: 4 workers finishing in 3, 3, 3, and 12 minutes → wall-clock 12, sequential total 21, so efficiency = `21 \u002F (12 × 4) = 44%` — well under target because three workers idled 9 minutes each. Fix by splitting by estimated duration (not file count), breaking up slow test files, and using dynamic splitting (Playwright sharding, Jest `--shard`).\n\n---\n\n### Process Metrics\n*Is our QA process improving over time?* (mix of leading and lagging)\n\n#### Automation Rate\n```\nAutomation rate = (automated test cases \u002F total test cases) × 100\n```\n**Targets:** Regression: 90%+. Smoke: 100%. Exploratory: 0% (by definition). Overall: 70-85%.\n\nManual testing does not scale. Automation compounds — once written, a test runs thousands of times. Automate the most frequently executed scenarios first.\n\n#### Test Creation Velocity\nNew automated tests added per sprint (net new, excluding refactors).\n\n**Target:** At least 3-5 automated tests per user story shipped. A sprint with 20 features and 0 new tests signals a growing coverage gap.\n\n#### Automation ROI\n```\nManual cost     = (manual time per cycle × cycles per year) × hourly rate\nAutomation cost = (write time + annual maintenance) × hourly rate\nROI             = (manual cost - automation cost) \u002F automation cost × 100\n```\n**Example:** Manual regression: 8 hrs\u002Frelease × 26 releases × $75\u002Fhr = $15,600\u002Fyr. Automation: 120 hrs to write + 40 hrs\u002Fyr maintenance × $75\u002Fhr = $12,000 year 1, $3,000\u002Fyr after. Year 1 ROI: `(15,600 - 12,000) \u002F 12,000 = 30%`. Year 2 ROI: `(15,600 - 3,000) \u002F 3,000 = 420%`. Use this to justify investment to stakeholders.\n\n---\n\n### Engineering Quality Metrics (DORA)\n\nDORA metrics are the standard vocabulary for leadership delivery dashboards. They pair with defect escape rate — DORA tracks delivery throughput; QA metrics track delivery quality.\n\n| Metric | What it measures | Benchmark (top-15%) |\n|--------|------------------|---|\n| **Lead Time for Changes** | Commit → production | \u003C 1 day |\n| **Deployment Frequency** | How often you ship | Multiple per day |\n| **Failed Deployment Recovery Time** (formerly MTTR) | Time to restore service after a *change-induced* failure | \u003C 1 hour |\n| **Change Failure Rate** | % of deploys that cause incidents | ~5% (older \"high performer\" bar was \u003C15%) |\n| **Rework Rate** | % of deploys that are unplanned fixes for a prior bad deploy | Low and falling |\n\nDORA 2025 formalized **Rework Rate** as the fifth metric and regrouped the set: the first three above are *throughput* (recovery time moved here because fast teams just ship the fix), Change Failure Rate + Rework Rate are *instability*. **Reliability** (availability, latency, error budget against your SLOs) is tracked alongside as a separate dimension — it is where QA\u002Fescape framing meets SRE, since error rate and availability are the user-facing tail of escaped defects. DORA 2025 also retired the named Elite\u002FHigh\u002FMedium\u002FLow tiers in favor of percentile distributions and seven team archetypes — read the column as a percentile benchmark, not a tier you \"are.\" The **Failed Deployment Recovery Time** rename (2023\u002F2024 reports) separates change-induced failures from external outages; it is a delivery metric distinct from your QA defect MTTR above.\n\nSource: https:\u002F\u002Fdora.dev\u002Fresearch\u002F. Tools that surface DORA from Git\u002FCI data: Sleuth, Faros, LinearB, Jellyfish, Swarmia.\n\n### Test Impact Analysis (TIA) as a Lever\n\nTIA selects which tests to run based on which code changed (using coverage data). It trades test breadth for CI cost. Track:\n\n- **% of tests skipped per PR via TIA** — higher means cheaper CI; if it climbs without coverage falling, TIA is paying off.\n- **Escaped defects from skipped tests** — the safety check. If non-zero, narrow the TIA selection or expand the always-run set.\n\nHosted: Datadog Test Optimization (TIA), CloudBees Smart Tests, NCrunch (in-IDE). Self-built: derive from coverage data + git diff. See `coverage-analysis`.\n\n---\n\n## Setting Realistic Targets\n\nTargets should match your team's maturity. Chasing enterprise metrics at a seed startup wastes effort.\n\n| Metric | Startup (seed-Series A) | Growth (Series B-C) | Enterprise (public\u002Flarge) |\n|---|---|---|---|\n| Unit test coverage | 60% | 75% | 85% |\n| Branch coverage | 45% | 60% | 75% |\n| E2E coverage (critical paths) | Top 5 flows | Top 15 flows | All P0\u002FP1 flows |\n| Flakiness rate | \u003C5% | \u003C3% | \u003C1% |\n| Pass rate (7-day) | >90% | >95% | >98% |\n| Defect escape rate | \u003C20% | \u003C10% | \u003C5% |\n| MTTR (P0) | \u003C8 hours | \u003C4 hours | \u003C2 hours |\n| CI pipeline duration | \u003C20 min | \u003C15 min | \u003C10 min |\n| Automation rate | 50% | 75% | 90% |\n| Metrics tracked | 3-5 core | 8-10 with dashboards | Full suite with alerting |\n\n**Progression path:**\n1. Start with 3 metrics: code coverage, flakiness rate, defect escape rate.\n2. Add execution metrics when CI cost or speed becomes a pain point.\n3. Add process metrics when the team grows beyond 5 engineers.\n4. Add the full suite when quality is a product differentiator or compliance requirement.\n\nFor the full phased rollout (week-by-week), the three dashboard layouts, and the data-source extraction table, see `references\u002Frollout.md` and `references\u002Fdashboards.md`.\n\n---\n\n## Anti-Patterns\n\n- **Treating coverage as quality proof.** Coverage measures execution, not verification. Pair with mutation testing for truth.\n- **Metrics without context.** \"Coverage is 74%\" is meaningless without target (80%), trend (up from 69%), and distribution (92% critical paths, 40% admin). Always present with target, trend, and breakdown.\n- **Gaming metrics.** Trivial tests to hit coverage numbers. Counter by pairing coverage with defect escape rate — if coverage is high but defects escape, the tests lack teeth.\n- **Too many metrics.** Tracking 25 means acting on none. Start with 3. Only add a metric when you can articulate the action it triggers.\n- **Measuring without acting.** A Grafana dashboard nobody opens. If a metric does not trigger action at least once per quarter, retire it (the metric half-life check in `references\u002Frollout.md`).\n- **Comparing across teams.** Coverage in a payment service vs. an admin tool is not comparable. Track improvement over time, not cross-team rankings.\n\n---\n\n## Verification\n\nThe whole point is a working feedback loop — prove the data actually flows before declaring done:\n\n1. **Coverage emits machine-readable output.** Run your coverage tool and confirm it writes JSON\u002FLCOV (`coverage\u002Fcoverage-final.json`, `lcov.info`) — not just an HTML report a human reads.\n2. **CI history is queryable.** Hit your CI provider's API for the last 7 days of run results and confirm you can compute pass rate and flakiness from it.\n3. **Escape labels exist.** Query the issue tracker for the `escaped-defect` (or equivalent) label and confirm at least the tagging convention is in place.\n4. **A gate actually blocks.** Open a throwaway PR that drops coverage or adds a `.skip` and confirm CI fails it — a gate that never fires proves nothing.\n\n---\n\n## Done When\n\n- Key metrics are defined with explicit formulas: coverage % (line and branch), flakiness rate, defect escape rate, and MTTR by severity.\n- Baseline values are established for each metric from at least 2 weeks of collected data, with targets set per the company-stage table.\n- Data collection is automated via CI integrations (coverage from test runner, flakiness from CI run history, defects from issue-tracker labels) — no manual steps.\n- Quality gates are configured in CI to block merges or deployments when flakiness exceeds threshold, coverage drops, or critical tests fail (verified by a failing throwaway PR).\n- Each metric has a named owner, and a metrics block exists in the recurring retro template (or a standing calendar invite) — a checkable artifact, not just an intention.\n\n## Reference Files (in `references\u002F`)\n\n- **dashboards.md** — the engineering (daily), leadership (monthly), and sprint-health dashboard layouts, plus the release-confidence-score example weighting.\n- **rollout.md** — the four-phase week-by-week implementation plan, the data-source extraction table, and the metric half-life retirement practice.\n\n## Related Skills\n\n- **qa-dashboard** — builds the Allure\u002FGrafana\u002FSaaS dashboard UI that surfaces these metrics; go there for the rendering, here for what to measure.\n- **coverage-analysis** — coverage gaps and mutation score in depth; the assertion-quality input to the coverage metric here.\n- **ci-cd-integration** — configures the CI pipelines that generate the raw data these metrics depend on, including Test Impact Analysis as a cost lever.\n- **release-readiness** — consumes quality gates and DORA Change Failure Rate \u002F Failed Deployment Recovery Time for go\u002Fno-go decisions.\n- **test-reliability** — runtime per-test healing for the flaky tests the flakiness rate flags.\n- **quality-postmortem** — action-item-closure-rate pairs with escape rate as the postmortem-side metric.\n- **qa-project-context** — feeds targets and baselines into metrics tracking.\n","\u003Cobjective>\nA suite with 4,000 tests where 800 are disabled and 200 are flaky looks healthy on a slide and lies in production. This skill defines the metrics that actually change behavior — each one with a formula, a target, an owner, and a concrete action when it goes red — so the dashboard becomes a feedback loop instead of decoration.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Your situation | Metric to reach for | Section \u002F reference |\n|---|---|---|\n| No metrics yet, where to start | code coverage, flakiness, defect escape | Core Principles + `references\u002Frollout.md` |\n| Bugs escaping despite high coverage | defect escape rate + mutation score | Coverage Metrics, Defect Metrics |\n| Tests flaky, devs ignore CI | flakiness rate, pass rate | Test Health Metrics |\n| Slow pipeline, stale feedback | suite duration, parallelism efficiency | Execution Metrics |\n| Justifying automation spend | automation ROI | Process Metrics |\n| Picking targets for our stage | company-stage table | Setting Realistic Targets |\n| Leadership wants delivery + quality | DORA + escape rate | Engineering Quality Metrics (DORA) |\n| Building the dashboard view | (go to `qa-dashboard`) | — |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it as the foundation and skip anything already answered there. Then:\n\n### Current State\n- What metrics are you tracking today? (Even \"we glance at CI pass rate sometimes\" counts.)\n- Where does your test data live? (CI system, coverage reports, bug tracker, spreadsheets, nowhere)\n- Do you have any dashboards already? Who looks at them, and how often?\n- What tooling runs your CI pipeline? (GitHub Actions, GitLab CI, Jenkins, CircleCI)\n\n### Stakeholders\n- Who are the stakeholders for quality metrics? (engineering, product, leadership, customers)\n- What does each care about? Engineers want flakiness; leadership wants escape trends; product wants release confidence.\n- Who will own each metric? If nobody owns it, nobody acts on it.\n\n### Quality Problems\n- What quality problems need visibility? (regressions, slow pipelines, flaky tests, coverage gaps, incidents)\n- What broke in production recently? Would a metric have caught it earlier?\n- What decisions are you making without data today?\n\n### Goals\n- What does \"healthy test suite\" mean for your team?\n- Any compliance or contractual quality requirements? (SLAs, SOC2, ISO)\n- Quick wins vs. full observability — what is the appetite for metrics infrastructure?\n\n---\n\n## Core Principles\n\n### 1. Metrics Should Drive Action, Not Just Dashboards\nA metric without an action plan is decoration. For every metric, define: what threshold triggers action, what the action is, and who takes it. If flakiness crosses 5%, the on-call engineer investigates the top 3 flaky tests that week. No ambiguity.\n\n### 2. Leading vs Lagging — Track Both, Act on Leading\nDefect escape rate and MTTR are **lagging**: you learn after users were hurt. Flakiness, coverage delta, and skipped-test count are **leading**: they predict escapes before they happen. Lagging metrics tell leadership whether quality is moving; leading metrics are where engineers spend their daily attention because they can still change the outcome.\n\n### 3. Trend Over Snapshot\nA single number is nearly useless. Coverage at 72% means nothing; coverage trending 68% → 72% over three sprints tells a story. Display metrics as time series and evaluate direction, not absolute position.\n\n### 4. Every Metric Needs a Target and an Owner\nA target makes a metric actionable; an owner makes it accountable. Without both it becomes background noise. Set targets from your team's maturity (see the targets table) and assign owners who can actually move the number.\n\n### 5. Vanity Metrics Waste Everyone's Time\n\"We have 4,000 tests\" sounds impressive until 800 are disabled and 200 flaky. Count what matters: tests that run, pass reliably, and catch real bugs. The ultimate metric is whether users hit bugs that hurt the business — work backward from there. Defect escape rate connects directly to user experience; lines of test code connects to nothing.\n\n---\n\n## Essential QA Metrics\n\nEach metric: definition, formula, recommended target, why it matters, and the action when it goes red.\n\n### Test Coverage Metrics\n*How much of our system is verified by automated tests?* (leading)\n\n#### Code Coverage Percentage\nThe percentage of code exercised by automated tests (line, branch, or statement level).\n\n```\nLine coverage   = (lines executed by tests \u002F total executable lines) × 100\nBranch coverage = (branches executed by tests \u002F total branches) × 100\n```\n\n**Targets:** Line: 70-85% for app code. Branch: 60-75%. Critical paths (payments, auth): 90%+.\n\n**Why it matters:** Coverage identifies blind spots — code never exercised by tests is where bugs hide undetected.\n\n**When it goes red:** Coverage drops on PR: block merge or flag. Low in critical module: create targeted tasks. Plateaus: check for dead code vs. genuinely untested logic.\n\n**Warning:** Coverage measures execution, not assertion quality. Pair it with mutation testing (StrykerJS v9.6+, mutmut) for a truer picture. Stryker's Vitest runner tracks recent Vitest releases — check the runner's peer-dependency before pinning a Vitest version. Use `incremental: true` in monorepo CI to keep mutation runs cheap. For deep coverage\u002Fmutation analysis, see `coverage-analysis`.\n\n#### Requirement Coverage Percentage\n```\nRequirement coverage = (features with at least one test \u002F total features) × 100\n```\n**Targets:** 100% for P0\u002FP1 features, 80%+ for P2.\n\n**Why it matters:** A feature can have zero tests even if surrounding code is well-covered. Use test tags (`@feature:checkout`, `@story:PROJ-1234`) for traceability.\n\n#### Risk Coverage Percentage\n```\nRisk coverage = (high-risk areas with automated tests \u002F total high-risk areas) × 100\n```\n**Targets:** 95%+ for high-risk areas. Maintain a risk register and cross-reference against coverage data per module.\n\n---\n\n### Test Health Metrics\n*Can we trust our test suite?* (leading)\n\n#### Flakiness Rate\nThe percentage of test runs producing inconsistent results without code changes.\n\n```\nFlakiness rate = (test runs with flaky results \u002F total test runs) × 100\n```\n\n**Targets:** Acceptable: \u003C2%. Warning: 2-5%. Critical: >5%.\n\n**Why it matters:** Flaky tests erode trust. Once developers think \"probably just flaky,\" they stop paying attention to results at all. Flakiness is the single biggest threat to a suite's credibility.\n\n**When it goes red:** Quarantine flaky tests immediately. Investigate the top 3 weekly — most flakiness comes from a small number of tests. Common causes: timing\u002Frace conditions, shared state, external dependencies, order-dependent tests. Tests flaky for 30+ days should be deleted or rewritten.\n\n**Detection:** Buildkite Test Analytics, **Datadog Test Optimization** (formerly Datadog CI Visibility — ships Flaky Test Management, Auto Test Retries, Early Flake Detection, Failed Test Replay, and Test Impact Analysis; its Bits AI Dev Agent can auto-open PRs to fix flaky tests), Trunk Flaky Tests, or a script comparing results across runs on the same commit.\n\n#### Pass Rate Trend (7-Day Rolling)\n```\nPass rate = (green CI runs \u002F total CI runs) × 100  [rolling 7 days]\n```\n**Targets:** Healthy: >95%. Warning: 90-95%. Broken: \u003C90%.\n\nThe 7-day rolling average smooths daily noise and reveals the real trend. A consistently red build means developers ignore the pipeline.\n\n#### Disabled and Skipped Test Count\nTotal tests marked `skip`, `disabled`, `pending`, `xit`, `xdescribe` or equivalent.\n\n**Target:** Trend toward zero. Skipped tests older than 2 sprints: fix or delete. Add a CI step that fails if skipped count exceeds 5% of total tests.\n\n**Why it matters:** Skipped tests are invisible coverage gaps. A suite with 500 passing and 150 skipped tests has a `150 \u002F (500 + 150) = 23%` gap that dashboards hide.\n\n#### Test Suite Duration\nWall-clock time from suite start to completion.\n\n**Targets:** Unit: \u003C5 min. Integration: \u003C10 min. E2E: \u003C15 min. Full pipeline: \u003C30 min (the stage targets are the real budget; \u003C30 min is the sum, not a separate looser bar).\n\n**Why it matters:** Slow tests break the feedback loop. 45-minute results mean developers have already context-switched.\n\n**When it goes red:** Profile slowest tests (10% often account for 50% of runtime). Increase parallelism. Move slow tests post-merge. Check for unnecessary setup\u002Fteardown. Plot duration over time and alert on step changes (>20% increase in a week).\n\n---\n\n### Defect Metrics\n*Are we catching bugs before users do?* (lagging)\n\n#### Defect Escape Rate\nThe percentage of defects found in production relative to all defects found.\n\n```\nDefect escape rate = (defects found in production \u002F total defects found) × 100\n```\n\n**Targets:** Excellent: \u003C5%. Acceptable: 5-10%. Needs work: 10-20%. Critical: >20%.\n\n**Worked example:** A release surfaces 15 total defects, 2 of them in production → `2 \u002F 15 × 100 = 13.3%` escape rate, which lands in \"needs work.\"\n\n**Why it matters:** The single most important quality metric. It directly measures whether testing catches bugs before users do.\n\n**When it goes red:** Classify escaped defects by layer (unit? integration? E2E? review?). Write a retrospective test for each. Identify if escapes cluster in specific areas — those need targeted investment.\n\n**How to track:** Tag production bugs (`escaped-defect` label). Count escaped vs. pre-release defects at sprint retros.\n\n#### Mean Time To Resolution (MTTR)\n```\nMTTR = sum(resolution_time for each defect) \u002F number of defects\n```\n**Targets:** P0: \u003C4 hours. P1: \u003C24 hours. P2: \u003C1 sprint. P3: \u003C2 sprints.\n\nHigh MTTR often signals process bottlenecks (slow review, unclear ownership, complex deploys) rather than technical difficulty. Break into phases (triage, assign, fix, deploy) to find the bottleneck. (This is your QA *defect* resolution time — distinct from the DORA recovery metric below.)\n\n#### Defect Density\n```\nDefect density = defects found \u002F KLOC  (or per feature shipped)\n```\n**Targets:** Track your own baseline; industry benchmarks are 1-10 defects per KLOC. If one module has 5x the density of others, it needs refactoring or better coverage.\n\n#### Severity Distribution\nHealthy: P0 \u003C5%, P1 10-15%, P2 40-50%, P3 30-40%. Visualize as a stacked bar over time. Heavy P0\u002FP1 concentration means testing misses critical issues.\n\n---\n\n### Execution Metrics\n*Is our CI pipeline fast, reliable, and cost-effective?* (leading)\n\n#### CI Pipeline Duration\nTotal wall-clock time by stage. **Targets:** Lint: \u003C2 min. Unit: \u003C5 min. Integration: \u003C10 min. E2E: \u003C15 min. Full: \u003C30 min (= sum of stages above, reconciled with the suite-duration budget).\n\n**When it goes red:** Optimize the slowest stage first. Split fast checks (every push) from slow checks (PR merge). Profile setup time vs. execution time. Parallelize sequential stages.\n\n#### CI Cost Per Run\n```\nCI cost per run = (compute minutes × cost per minute) + fixed costs\n```\n50 builds\u002Fday at $0.50 each = $750\u002Fmonth. Optimize by caching dependencies, using spot instances, right-sizing runners, and skipping unchanged suites.\n\n#### Parallelism Efficiency\n```\nParallelism efficiency = (total sequential time \u002F (wall-clock time × workers)) × 100\n```\n**Target:** >80%. Example: 4 workers finishing in 3, 3, 3, and 12 minutes → wall-clock 12, sequential total 21, so efficiency = `21 \u002F (12 × 4) = 44%` — well under target because three workers idled 9 minutes each. Fix by splitting by estimated duration (not file count), breaking up slow test files, and using dynamic splitting (Playwright sharding, Jest `--shard`).\n\n---\n\n### Process Metrics\n*Is our QA process improving over time?* (mix of leading and lagging)\n\n#### Automation Rate\n```\nAutomation rate = (automated test cases \u002F total test cases) × 100\n```\n**Targets:** Regression: 90%+. Smoke: 100%. Exploratory: 0% (by definition). Overall: 70-85%.\n\nManual testing does not scale. Automation compounds — once written, a test runs thousands of times. Automate the most frequently executed scenarios first.\n\n#### Test Creation Velocity\nNew automated tests added per sprint (net new, excluding refactors).\n\n**Target:** At least 3-5 automated tests per user story shipped. A sprint with 20 features and 0 new tests signals a growing coverage gap.\n\n#### Automation ROI\n```\nManual cost     = (manual time per cycle × cycles per year) × hourly rate\nAutomation cost = (write time + annual maintenance) × hourly rate\nROI             = (manual cost - automation cost) \u002F automation cost × 100\n```\n**Example:** Manual regression: 8 hrs\u002Frelease × 26 releases × $75\u002Fhr = $15,600\u002Fyr. Automation: 120 hrs to write + 40 hrs\u002Fyr maintenance × $75\u002Fhr = $12,000 year 1, $3,000\u002Fyr after. Year 1 ROI: `(15,600 - 12,000) \u002F 12,000 = 30%`. Year 2 ROI: `(15,600 - 3,000) \u002F 3,000 = 420%`. Use this to justify investment to stakeholders.\n\n---\n\n### Engineering Quality Metrics (DORA)\n\nDORA metrics are the standard vocabulary for leadership delivery dashboards. They pair with defect escape rate — DORA tracks delivery throughput; QA metrics track delivery quality.\n\n| Metric | What it measures | Benchmark (top-15%) |\n|--------|------------------|---|\n| **Lead Time for Changes** | Commit → production | \u003C 1 day |\n| **Deployment Frequency** | How often you ship | Multiple per day |\n| **Failed Deployment Recovery Time** (formerly MTTR) | Time to restore service after a *change-induced* failure | \u003C 1 hour |\n| **Change Failure Rate** | % of deploys that cause incidents | ~5% (older \"high performer\" bar was \u003C15%) |\n| **Rework Rate** | % of deploys that are unplanned fixes for a prior bad deploy | Low and falling |\n\nDORA 2025 formalized **Rework Rate** as the fifth metric and regrouped the set: the first three above are *throughput* (recovery time moved here because fast teams just ship the fix), Change Failure Rate + Rework Rate are *instability*. **Reliability** (availability, latency, error budget against your SLOs) is tracked alongside as a separate dimension — it is where QA\u002Fescape framing meets SRE, since error rate and availability are the user-facing tail of escaped defects. DORA 2025 also retired the named Elite\u002FHigh\u002FMedium\u002FLow tiers in favor of percentile distributions and seven team archetypes — read the column as a percentile benchmark, not a tier you \"are.\" The **Failed Deployment Recovery Time** rename (2023\u002F2024 reports) separates change-induced failures from external outages; it is a delivery metric distinct from your QA defect MTTR above.\n\nSource: https:\u002F\u002Fdora.dev\u002Fresearch\u002F. Tools that surface DORA from Git\u002FCI data: Sleuth, Faros, LinearB, Jellyfish, Swarmia.\n\n### Test Impact Analysis (TIA) as a Lever\n\nTIA selects which tests to run based on which code changed (using coverage data). It trades test breadth for CI cost. Track:\n\n- **% of tests skipped per PR via TIA** — higher means cheaper CI; if it climbs without coverage falling, TIA is paying off.\n- **Escaped defects from skipped tests** — the safety check. If non-zero, narrow the TIA selection or expand the always-run set.\n\nHosted: Datadog Test Optimization (TIA), CloudBees Smart Tests, NCrunch (in-IDE). Self-built: derive from coverage data + git diff. See `coverage-analysis`.\n\n---\n\n## Setting Realistic Targets\n\nTargets should match your team's maturity. Chasing enterprise metrics at a seed startup wastes effort.\n\n| Metric | Startup (seed-Series A) | Growth (Series B-C) | Enterprise (public\u002Flarge) |\n|---|---|---|---|\n| Unit test coverage | 60% | 75% | 85% |\n| Branch coverage | 45% | 60% | 75% |\n| E2E coverage (critical paths) | Top 5 flows | Top 15 flows | All P0\u002FP1 flows |\n| Flakiness rate | \u003C5% | \u003C3% | \u003C1% |\n| Pass rate (7-day) | >90% | >95% | >98% |\n| Defect escape rate | \u003C20% | \u003C10% | \u003C5% |\n| MTTR (P0) | \u003C8 hours | \u003C4 hours | \u003C2 hours |\n| CI pipeline duration | \u003C20 min | \u003C15 min | \u003C10 min |\n| Automation rate | 50% | 75% | 90% |\n| Metrics tracked | 3-5 core | 8-10 with dashboards | Full suite with alerting |\n\n**Progression path:**\n1. Start with 3 metrics: code coverage, flakiness rate, defect escape rate.\n2. Add execution metrics when CI cost or speed becomes a pain point.\n3. Add process metrics when the team grows beyond 5 engineers.\n4. Add the full suite when quality is a product differentiator or compliance requirement.\n\nFor the full phased rollout (week-by-week), the three dashboard layouts, and the data-source extraction table, see `references\u002Frollout.md` and `references\u002Fdashboards.md`.\n\n---\n\n## Anti-Patterns\n\n- **Treating coverage as quality proof.** Coverage measures execution, not verification. Pair with mutation testing for truth.\n- **Metrics without context.** \"Coverage is 74%\" is meaningless without target (80%), trend (up from 69%), and distribution (92% critical paths, 40% admin). Always present with target, trend, and breakdown.\n- **Gaming metrics.** Trivial tests to hit coverage numbers. Counter by pairing coverage with defect escape rate — if coverage is high but defects escape, the tests lack teeth.\n- **Too many metrics.** Tracking 25 means acting on none. Start with 3. Only add a metric when you can articulate the action it triggers.\n- **Measuring without acting.** A Grafana dashboard nobody opens. If a metric does not trigger action at least once per quarter, retire it (the metric half-life check in `references\u002Frollout.md`).\n- **Comparing across teams.** Coverage in a payment service vs. an admin tool is not comparable. Track improvement over time, not cross-team rankings.\n\n---\n\n## Verification\n\nThe whole point is a working feedback loop — prove the data actually flows before declaring done:\n\n1. **Coverage emits machine-readable output.** Run your coverage tool and confirm it writes JSON\u002FLCOV (`coverage\u002Fcoverage-final.json`, `lcov.info`) — not just an HTML report a human reads.\n2. **CI history is queryable.** Hit your CI provider's API for the last 7 days of run results and confirm you can compute pass rate and flakiness from it.\n3. **Escape labels exist.** Query the issue tracker for the `escaped-defect` (or equivalent) label and confirm at least the tagging convention is in place.\n4. **A gate actually blocks.** Open a throwaway PR that drops coverage or adds a `.skip` and confirm CI fails it — a gate that never fires proves nothing.\n\n---\n\n## Done When\n\n- Key metrics are defined with explicit formulas: coverage % (line and branch), flakiness rate, defect escape rate, and MTTR by severity.\n- Baseline values are established for each metric from at least 2 weeks of collected data, with targets set per the company-stage table.\n- Data collection is automated via CI integrations (coverage from test runner, flakiness from CI run history, defects from issue-tracker labels) — no manual steps.\n- Quality gates are configured in CI to block merges or deployments when flakiness exceeds threshold, coverage drops, or critical tests fail (verified by a failing throwaway PR).\n- Each metric has a named owner, and a metrics block exists in the recurring retro template (or a standing calendar invite) — a checkable artifact, not just an intention.\n\n## Reference Files (in `references\u002F`)\n\n- **dashboards.md** — the engineering (daily), leadership (monthly), and sprint-health dashboard layouts, plus the release-confidence-score example weighting.\n- **rollout.md** — the four-phase week-by-week implementation plan, the data-source extraction table, and the metric half-life retirement practice.\n\n## Related Skills\n\n- **qa-dashboard** — builds the Allure\u002FGrafana\u002FSaaS dashboard UI that surfaces these metrics; go there for the rendering, here for what to measure.\n- **coverage-analysis** — coverage gaps and mutation score in depth; the assertion-quality input to the coverage metric here.\n- **ci-cd-integration** — configures the CI pipelines that generate the raw data these metrics depend on, including Test Impact Analysis as a cost lever.\n- **release-readiness** — consumes quality gates and DORA Change Failure Rate \u002F Failed Deployment Recovery Time for go\u002Fno-go decisions.\n- **test-reliability** — runtime per-test healing for the flaky tests the flakiness rate flags.\n- **quality-postmortem** — action-item-closure-rate pairs with escape rate as the postmortem-side metric.\n- **qa-project-context** — feeds targets and baselines into metrics tracking.\n",{"name":5,"license":15,"metadata":44,"description":7},{"author":45,"version":46,"category":20},"kindlmann","2.0","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fqa-metrics","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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add pattanation\u002FNorvik --skill qa-metrics",{"tool":60,"command":61},"bunx","bunx skills add pattanation\u002FNorvik --skill qa-metrics",{"tool":63,"command":64},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill qa-metrics","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-metrics\u002FSKILL.md",true,[68,74],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fdashboards.md","REFERENCE","参考文档",2702,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-metrics\u002Freferences\u002Fdashboards.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Frollout.md",3158,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fqa-metrics\u002Freferences\u002Frollout.md",[79,111,137,160,182,197],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":83,"licenseFileUrl":84,"sourceHtmlUrl":85,"categories":86,"keywords":95,"publishedAt":39},"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",[87,92],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000009","前端开发",[96,97,98,23,99,100,101,102,103,104,105,106,107,108,109,26,110],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","screenshots",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":83,"licenseFileUrl":115,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":39},"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",[118],{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},[120,121,122,108,123,124,125,23,126,127,101,128,129,130,131,132,133,134,135,136],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":141,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":39},"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",[144],{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},[146,147,148,149,150,151,152,153,154,155,156,157,158,159],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":164,"sourceHtmlUrl":165,"categories":166,"keywords":169,"publishedAt":39},"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",[167,168],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},[170,97,171,157,172,107,173,174,175,152,176,23,177,178,179,129,180,158,181],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":186,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":39},"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",[189],{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},[191,157,192,172,193,175,194,152,180,195,196],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":205,"publishedAt":39},"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",[204],{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},[206,157,172,207,149,208,209,210,191,211,212,213,214,215,216,23,217,129,218,219],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]