[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PST1X7P62VQEJ3RQRJRX2":3,"skill-same:01M71PST1X7P62VQEJ3RQRJRX2":87},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M71PST1X7P62VQEJ3RQRJRX2","synthetic-monitoring",null,"Scheduled probes that run CONTINUOUSLY after release. Covers probe design for critical user journeys, alerting integration, SLA validation, multi-region monitoring, and the boundary between QA and SRE. Use when: \"synthetic monitoring,\" \"uptime testing,\" \"scheduled probes,\" \"SLA validation,\" \"availability monitoring,\" \"post-deploy checks.\" Not for: safe-release techniques during rollout — use testing-in-production. Not for: designing tests from prod telemetry — use observability-driven-testing. Not for: a one-shot post-deploy smoke gate tied to a release — use release-readiness. Related: testing-in-production, release-readiness, performance-testing, qa-metrics.","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\u002Fsynthetic-monitoring\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"monitoring","synthetic monitoring","synthetic","metrics","safe","release","run","designing tests","uptime","alerting","rollout","when","critical","scheduled","qa","design","testing","performance","sre","user journeys","2026-11-10 13:02:02",false,"---\nname: synthetic-monitoring\ndescription: >-\n  Scheduled probes that run CONTINUOUSLY after release. Covers probe design for\n  critical user journeys, alerting integration, SLA validation, multi-region\n  monitoring, and the boundary between QA and SRE. Use when: \"synthetic\n  monitoring,\" \"uptime testing,\" \"scheduled probes,\" \"SLA validation,\"\n  \"availability monitoring,\" \"post-deploy checks.\" Not for: safe-release\n  techniques during rollout — use testing-in-production. Not for: designing\n  tests from prod telemetry — use observability-driven-testing. Not for: a\n  one-shot post-deploy smoke gate tied to a release — use release-readiness.\n  Related: testing-in-production, release-readiness, performance-testing, qa-metrics.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: production\n---\n\n\u003Cobjective>\nSynthetic monitoring runs scripted tests against production on a schedule, 24\u002F7. It catches outages, performance degradation, and broken flows before real users report them — at 3 AM when traffic is zero, probes are the only thing checking your app works. A login page that always returns 200 but never authenticates passes a naive uptime check; a synthetic probe that asserts the dashboard loads catches it. This skill covers probe design, alerting integration, SLA validation, multi-region execution, and the runbook discipline that keeps a 3 AM page actionable.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Picking a platform (Checkly, Datadog, Grafana, CloudWatch…) | Platform Options |\n| Writing a probe (login, API health, search) | Probe Design → `references\u002Fprobe-implementations.md` |\n| Probe runs but users still report outages | Failure Modes |\n| Alerts too noisy or missing real outages | Alerting Integration |\n| Calculating downtime budget for an SLA | SLA Validation |\n| Probe failed at 3 AM and on-call is lost | runbook template in `references\u002Fplatforms-and-ci.md` |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first. If it exists, use it as context and skip questions already answered there. Each answer changes the probe set, the alerting config, or the SLA math.\n\n**Critical flows** (decides which probes you write):\n- What are the 5-10 most important user journeys (login, search, checkout, signup, core workflow)? These become your probe list.\n- Which flows, if broken, cause immediate revenue loss or churn? These get the shortest frequency and page on-call.\n- Are there flows that break silently (data sync, background jobs, webhooks)? Silent failures need probes most — no user reports them.\n- Do you have documented SLAs\u002FSLOs for availability and response time? They set the downtime budget and the alert thresholds.\n\n**Current monitoring** (decides where the gaps are):\n- What exists today (uptime checks, APM, error tracking, dashboards)? Avoid duplicating; find the gap.\n- Are there gaps between what monitoring covers and what users experience? That gap is where probes earn their keep.\n- How do you learn about production issues today (alerts, user reports, social media)? If it's user reports, detection time is your first metric to fix.\n- What was the last outage, and how long before it was detected? Sets the detection-time target probes must beat.\n\n**Infrastructure** (decides regions and CDN assertions):\n- Is the app served from multiple regions or one? Multi-region serving needs multi-region probing.\n- Are there CDN, caching, or edge layers that could mask origin failures? If yes, probes must assert on `x-cache`\u002Forigin headers.\n- Do third-party dependencies (payment, auth, email) have their own monitoring? Their status pages feed your runbooks.\n- What alerting systems exist (PagerDuty, OpsGenie, Slack, email)? Decides the routing config.\n\n**Test accounts** (decides data safety):\n- Do dedicated synthetic test accounts exist in production? Without them, probes pollute real data and analytics.\n- Can test accounts be excluded from analytics, billing, and email campaigns? If not, probe traffic skews every downstream number.\n- Is there API access for programmatic account setup and data cleanup? Decides whether create-then-delete probes are viable.\n\n---\n\n## Core Principles\n\n### 1. Synthetic tests validate the user experience continuously\nRUM tells you what happened; synthetic tells you what is happening right now, whether or not real users are active. At 3 AM when traffic is zero, synthetic probes are the only thing checking the app works. Complement RUM, never replace it: synthetic covers known paths with predictable inputs, RUM discovers the creative ways real users break things.\n\n### 2. Keep probes simple and fast\nA probe that takes 2 minutes and touches 15 pages is not a probe — it is an E2E suite running in production. Probes are short (per-probe wall-clock budget under 30 seconds), focused (one critical path each), and stable (`retries: 0`, zero flakiness tolerance). The 30-second ceiling is a hard budget: a slow probe that \"still passes\" is masking a degradation users feel.\n\n### 3. Alert on trends, not single failures\nA single probe failure is noise — network blips and DNS hiccups cause them constantly. Two consecutive failures are a signal; failures from 2+ regions confirm it is not local. Configure consecutive-failure and multi-region thresholds, or alert fatigue teaches the team to ignore the pager.\n\n### 4. Probes must not affect production data\nProbes run every few minutes, 24\u002F7. Even small side effects (a created record, an incremented counter) compound. Probes must be non-destructive, created data cleaned up immediately, and synthetic traffic excluded from analytics, billing, and — critically — from SLO\u002Ferror-budget math itself, or probes inflate your own reliability numbers.\n\n### 5. Assert on the goal, not the status code\nA login page that returns 200 but never authenticates is broken. A search page that returns 200 with zero results is broken. Probes assert that the user can accomplish their goal — data loads, auth succeeds, results appear — not merely that the page returns a 2xx.\n\n---\n\n## Probe Design\n\nDesign probes around critical user journeys, not infrastructure components. Users do not care if your load balancer is healthy — they care if they can log in and use the product.\n\n| Probe | What It Validates | Frequency | Timeout |\n|-------|-------------------|-----------|---------|\n| Homepage load | DNS, CDN, server, basic rendering | 1 min | 10s |\n| Login flow | Authentication service, session management | 5 min | 15s |\n| Core workflow | Primary value-delivering action (create document, run report) | 5 min | 20s |\n| API health | Backend services, database connectivity | 1 min | 5s |\n| Search | Search index, query processing, result rendering | 5 min | 15s |\n| Checkout (if applicable) | Payment integration (sandbox mode), cart, order creation | 10 min | 25s |\n| Third-party integrations | OAuth providers, email delivery, file storage | 10 min | 15s |\n\n### Probe implementations\n\nThree probe shapes cover most needs: a login flow (Playwright browser), an API health check (status + auth + latency budget), and a search probe (fill query → submit → assert on results, not just status). Keep each to one critical path, a tight timeout, and `retries: 0`. See `references\u002Fprobe-implementations.md` for runnable login-flow, API-health, and search probes plus the environment-aware config.\n\n### Non-destructive probe patterns\n\n```\nSafe patterns:\n  - Read-only operations: GET requests, page loads, searches\n  - Sandbox transactions: payment in test mode, email to internal addresses\n  - Create-then-delete: create a draft, verify, delete immediately\n  - Synthetic flag: operations tagged as synthetic, excluded from processing\n\nDangerous patterns (avoid):\n  - Creating real orders, tickets, or user-facing records\n  - Triggering real notifications (email, SMS, push)\n  - Modifying shared resources (config, permissions, settings)\n  - Operations that cannot be automatically cleaned up\n```\n\n### Dedicated test accounts\n\n```\nAccount requirements:\n  - Clearly identifiable: email contains \"synthetic\" or \"monitor\"\n  - Flagged in database with an is_synthetic flag (is_synthetic = true)\n  - Excluded from analytics, billing, email campaigns, support queues\n  - Excluded from RUM and SLO\u002Ferror-budget pipelines (synthetic traffic is not real traffic)\n  - Pre-populated with stable test data that probes can rely on\n  - Credentials in a secrets manager (process.env), rotated quarterly\n  - Separate accounts per concurrent probe (avoid state conflicts)\n```\n\n---\n\n## Platform Options\n\n| Platform | Strengths | When to Use |\n|----------|-----------|-------------|\n| Checkly | Playwright-native, code-first, Git integration; **Rocky** AI agent (GA 2026) now does automated root-cause analysis across Playwright\u002FAPI\u002FMultistep\u002FTCP\u002FDNS\u002FICMP checks; CLI access from any AI agent; MCP server | Teams already using Playwright for E2E |\n| Datadog Synthetic | Deep APM integration, browser and API tests | Teams on the Datadog platform |\n| Grafana Synthetic Monitoring | Open source, integrates with Grafana dashboards; pairs with k6 2.x; pin a version channel (v1.x\u002Fv2.x) for reproducibility | Teams using the Grafana stack |\n| AWS CloudWatch Synthetics | Blueprints (heartbeat, API, broken-link, visual diff); Python or Node Puppeteer canaries | Teams already on AWS |\n| New Relic Synthetics | Full-stack observability integration | Teams on the New Relic platform |\n| Better Stack | Lightweight uptime + status pages + on-call | SMB-friendly, fast setup |\n| Uptime Kuma | OSS, self-hosted, lightweight | Self-hosting requirement, small surface area |\n| Custom (Playwright \u002F k6 \u002F Puppeteer + cron) | Full control, no vendor lock-in | Budget-constrained or custom requirements |\n\n> Probes can be authored in Playwright (TS\u002FJS), Puppeteer, k6 (JS — k6 2.0 shipped May 2026 with AI-assisted test authoring and a clearer Assertions API; first-class for synthetic), or Python (CloudWatch Synthetics, Checkly). Pick what your team already maintains. Avoid: Pingdom for new setups — it is a legacy uptime tool; prefer code-first alternatives (Checkly, Grafana, custom Playwright) that version-control probes alongside your app.\n\n### Custom and managed implementations\n\nSelf-managed: schedule Playwright probes with a GitHub Actions `schedule` cron (every 5 minutes), inject prod credentials via secrets, and report results to a monitoring webhook. Managed: Checkly is Playwright-native and runs from multiple locations on a fixed frequency. Either way, make probes environment-aware so the same code runs against staging and production with different base URLs and thresholds. See `references\u002Fplatforms-and-ci.md` for the GitHub Actions workflow, the Checkly config, the alert-routing rules, and the runbook template.\n\n---\n\n## Alerting Integration\n\nNot every probe failure is an incident. Configure rules that cut noise while catching real problems.\n\n```\nAlerting rules:\n  - Single failure: log, do not alert (transient network issue)\n  - 2 consecutive failures from same region: warning (possible issue)\n  - 2 consecutive failures from 2+ regions: alert on-call (confirmed outage)\n  - Latency >2x baseline for 10 minutes: warning (performance degradation)\n  - Latency >3x baseline for 5 minutes: alert on-call (severe degradation)\n  - Any probe timeout: alert if 3 consecutive (service unresponsive)\n```\n\n**Routing.** Critical failures on revenue paths (login, checkout, api-health) page on-call (PagerDuty + Slack incidents) with a short repeat interval; warnings on secondary probes go to a Slack monitoring channel; info-level events use a long repeat interval. The probe must tag each result with a `severity` and `probe` label for these routes to match — see the routing note in `references\u002Fplatforms-and-ci.md` for the full `alerting-rules.yaml` and the tagging step.\n\n**Suppress synthetic alerts during planned maintenance.** A maintenance window should silence synthetic paging (the probes will fail by design) and exclude that window from error-budget math, or scheduled work burns budget and pages on-call for nothing.\n\n**Alert message format** — include enough context to start investigating immediately:\n\n```\nAlert template:\n  Title: [SYNTHETIC] {probe_name} failing from {region}\n  Severity: {critical|warning|info}\n  Consecutive failures: {count}\n  Last success: {timestamp}\n  Error: {error_message}\n  Duration: {last_response_time_ms}ms (threshold: {threshold}ms)\n  Dashboard: {link_to_dashboard}\n  Runbook: {link_to_runbook}\n  Regions affected: {list_of_failing_regions}\n```\n\nThe `{link_to_runbook}` points at a per-probe runbook (six lines: what it tests, first checks, manual repro, escalation, dashboard, owner). See the template in `references\u002Fplatforms-and-ci.md`.\n\n---\n\n## SLA Validation\n\n### Availability calculation\n\n```\nAvailability = (total_minutes - downtime_minutes) \u002F total_minutes × 100\n\nWhere:\n  - total_minutes = calendar month in minutes (43,200 for a 30-day month)\n  - downtime_minutes = minutes where synthetic probes detected failure\n\nSLA tiers (downtime\u002Fmonth, monthly basis on 43,200 min):\n  99.0%  = 432 min   = 7h 12min     (basic web app)\n  99.9%  = 43.2 min  = 43min 12s    (business application)\n  99.95% = 21.6 min  = 21min 36s    (critical SaaS)\n  99.99% = 4.32 min  = 4min 19s     (infrastructure\u002Fplatform)\n```\n\n> These are *common* availability targets, not prescriptive tiers. Pick targets from a user-impact analysis, not by tier name. Modern practice (Google SRE Workbook, OpenSLO) favors explicit SLO + error-budget policies over labelled tiers — define what user-visible failure looks like, set the budget user impact tolerates, and let the SLO follow. References: https:\u002F\u002Fsre.google\u002Fworkbook\u002F ; https:\u002F\u002Fopenslo.com\u002F\n\n### Response time percentiles\n\nTrack percentiles, not averages — averages hide the worst experiences.\n\n```\nSLA response time targets (example):\n  Homepage load:  P50 \u003C 1s,    P95 \u003C 3s,   P99 \u003C 5s\n  API response:   P50 \u003C 200ms, P95 \u003C 500ms, P99 \u003C 1s\n  Search results: P50 \u003C 500ms, P95 \u003C 2s,   P99 \u003C 4s\n  Login flow:     P50 \u003C 2s,    P95 \u003C 5s,   P99 \u003C 8s\n```\n\n### Error budget tracking\n\nError budget connects SLA targets to engineering decisions.\n\n```\nError budget calculation:\n  SLO: 99.9% availability on a 43,200-min month\n  Budget: 0.1% of total time = 43.2 minutes\u002Fmonth\n\n  Budget consumed this month: 12 minutes (28%)\n  Budget remaining: 31.2 minutes (72%)\n\nActions by budget status:\n  >50% remaining: normal operations, ship features\n  25-50% remaining: caution, review recent changes\n  \u003C25% remaining: freeze non-critical deploys, focus on reliability\n  Budget exhausted: incident mode, every deploy needs extra scrutiny\n```\n\nExclude synthetic-probe downtime caused by your own maintenance windows from this calculation, or planned work shows as budget burn.\n\n---\n\n## Multi-Region Monitoring\n\nRun probes from regions where your users are. A service that works from us-east-1 but is broken from ap-southeast-1 is broken for APAC users.\n\n```\nRegion selection strategy:\n  - Minimum 3 regions for global services\n  - Always include: closest to primary infrastructure, largest user base, farthest from primary\n  - Example for US-primary service: us-east-1, eu-west-1, ap-southeast-1\n  - Example for EU-primary service: eu-west-1, us-east-1, ap-northeast-1\n```\n\nTrack regional latency separately — a global average hides regional degradation.\n\n```\nRegional latency dashboard:\n  Region       | P50    | P95    | Status\n  us-east-1    | 120ms  | 340ms  | healthy\n  eu-west-1    | 280ms  | 620ms  | healthy\n  ap-southeast | 450ms  | 1200ms | warning (P95 above threshold)\n\nAlert when:\n  - Any region's P95 exceeds its regional threshold\n  - Latency difference between regions exceeds 5x (CDN or routing issue)\n  - A region that was healthy becomes consistently degraded\n```\n\n**CDN validation.** Synthetic probes verify CDN caching by checking response headers (`x-cache`, `cf-cache-status`) for `HIT` and confirming the `server` header matches the expected provider. This catches CDN misconfigurations — and origin failures masked by a stale cache — before users hit slow uncached responses.\n\n---\n\n## Anti-Patterns\n\n### Complex probes that break often\nA probe that navigates 10 pages, fills 5 forms, and asserts on 20 elements is an E2E test, not a synthetic probe. When it breaks, you cannot tell if the app is down or the probe is flaky. **Fix:** one critical path per probe, under 30 seconds, under 5 assertions. A failure should make it immediately clear what is broken.\n\n### Alerting on every single failure\nNetwork blips, DNS hiccups, and transient cloud issues cause occasional failures. Alerting on every one produces noise that teaches the team to ignore alerts. **Fix:** require 2-3 consecutive failures and failures from 2+ regions before paging. Escalating severity: first failure logs, second warns, third pages.\n\n### No test account isolation\nProbes sharing one account interfere — one probe changes a setting, another fails because it expected the default. **Fix:** one dedicated synthetic account per concurrent probe, flagged synthetic, excluded from analytics and billing.\n\n### Monitoring only the happy path\nProbes that only check \"page loads, returns 200\" miss broken functionality behind a loading page. A login that returns 200 but never authenticates is not working. **Fix:** assert on meaningful content — data loads, auth succeeds, the core action completes, search returns results. One \"can the user accomplish their goal\" probe is worth ten \"does the page return 200\" probes.\n\n### No runbook for probe failures\nAn alert fires at 3 AM. On-call sees \"Login probe failing\" but has no idea what to check first, what the probe does, or how to tell a real outage from a probe issue. **Fix:** every probe links a runbook (what it tests; first checks — third-party status, recent deploys, app telemetry; manual repro; escalation; dashboard link). See the template in `references\u002Fplatforms-and-ci.md`.\n\n**Emerging pattern (2026): agent-driven first response.** Tools like Checkly Rocky (GA 2026, automated root-cause analysis across check types) and Honeycomb Canvas Skills (Agent Observability, launched May 2026; open-source `honeycombio\u002Fagent-skill` repo ships a honeycomb-investigator and instrumentation-advisor for Claude Code and Cursor) read probe context + linked runbook + telemetry and post a candidate diagnosis to chat. Treat this as triage assist — it shortens MTTR for routine failures, but it does not replace on-call judgment for novel incidents.\n\n---\n\n## Failure Modes\n\n| Symptom | Likely cause | Fix or check |\n|---------|--------------|--------------|\n| Probe green but users report an outage | Probe asserts only HTTP 200, not the goal | Add content\u002Fstate assertions (dashboard heading, search results count, `body.status`) |\n| Flapping alerts (fire\u002Fresolve repeatedly) | No consecutive-failure or multi-region rule | Require 2+ consecutive failures and 2+ regions before paging |\n| Probe passes locally, fails in CI\u002Fregion | Region-specific outage or CDN routing | Compare per-region results; check latency-difference and `x-cache` assertions |\n| Probe failures with no real outage | Synthetic-account state drift (shared account) | One isolated account per concurrent probe; reset\u002Fseed stable data |\n| Origin is down but probe stays green | CDN serving stale cache | Assert `cf-cache-status`\u002Forigin `server` header, not just 200 |\n| Error budget burns with no incident | Maintenance windows counted as downtime | Suppress synthetic paging during maintenance; exclude window from budget math |\n| On-call paged but can't act | Missing\u002Fempty runbook on the alert | Populate the six-line runbook; verify `{link_to_runbook}` resolves |\n| Reliability numbers look too good | Synthetic traffic counted as real in SLO\u002FRUM | Exclude `is_synthetic` traffic from RUM, billing, and error-budget pipelines |\n\n---\n\n## Verification\n\nProve the monitoring works before trusting it — smallest check first.\n\n1. **Probes pass against staging.** Run `npx playwright test probes\u002F --reporter=list` against staging and confirm every probe passes within its declared timeout (no probe exceeds the 30s ceiling).\n2. **A failure actually pages.** Point one probe at a known-bad URL (a `503` or a wrong path), let it run the configured consecutive-failure count, and confirm the alert routes to on-call within the SLA detection time — and resolves when you revert.\n3. **Assertions are meaningful, not status-only.** Temporarily break the asserted content (rename the dashboard heading on staging) and confirm the probe fails. A probe that stays green here is asserting on the wrong thing.\n4. **Synthetic traffic is excluded.** Query the analytics\u002FRUM\u002Fbilling pipeline for `is_synthetic` traffic and confirm it is filtered out.\n\n---\n\n## Done When\n\n- A probe exists for every critical user journey identified in discovery (not only homepage uptime or a single health endpoint), and each asserts on the goal, not just a 2xx.\n- Each probe's wall-clock budget is under 30s, with `retries: 0`.\n- Alerting config encodes a ≥2 consecutive-failure rule AND a multi-region confirmation rule, and probe results are tagged with `severity` + `probe` so routes match.\n- The SLA dashboard shows current availability and error-budget consumption, and synthetic traffic is excluded from RUM, billing, and error-budget pipelines.\n- A test alert (probe pointed at a failing URL) reaches on-call within the SLA detection time — confirmed once, not assumed.\n- Every probe links a non-empty runbook with first checks, manual repro, and an escalation path.\n- A scheduled review job or recurring calendar item for monitoring health exists (not just an intention to review).\n\n## Reference Files (in `references\u002F`)\n\n- **probe-implementations.md** — Runnable login-flow, API-health, and search probes, plus the environment-aware probe config.\n- **platforms-and-ci.md** — GitHub Actions scheduling workflow, Checkly config, alert-routing rules + tagging note, and the per-probe runbook template.\n\n## Related Skills\n\n- **testing-in-production** — safe-release *techniques* (flags, canary, guardrail metrics) applied *during* a rollout; synthetic monitoring is the schedule-driven validation that runs continuously *after*.\n- **release-readiness** — a one-shot post-deploy smoke gate tied to a specific release lives there; come here for the continuous, schedule-driven version that keeps running long after the release.\n- **observability-driven-testing** — uses production telemetry (including signals from these probes) as *input* to design new tests; this skill instead *produces* the probes and their telemetry.\n- **performance-testing** — load tests measure capacity on demand; synthetic probes track production performance *trends* between those load tests.\n- **qa-metrics** — availability, response-time percentiles, and error-budget consumption from probes feed the quality dashboards defined there.\n- **ci-cd-integration** — go there to wire synthetic probes into a pipeline as a post-deploy verification stage.\n","\u003Cobjective>\nSynthetic monitoring runs scripted tests against production on a schedule, 24\u002F7. It catches outages, performance degradation, and broken flows before real users report them — at 3 AM when traffic is zero, probes are the only thing checking your app works. A login page that always returns 200 but never authenticates passes a naive uptime check; a synthetic probe that asserts the dashboard loads catches it. This skill covers probe design, alerting integration, SLA validation, multi-region execution, and the runbook discipline that keeps a 3 AM page actionable.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Picking a platform (Checkly, Datadog, Grafana, CloudWatch…) | Platform Options |\n| Writing a probe (login, API health, search) | Probe Design → `references\u002Fprobe-implementations.md` |\n| Probe runs but users still report outages | Failure Modes |\n| Alerts too noisy or missing real outages | Alerting Integration |\n| Calculating downtime budget for an SLA | SLA Validation |\n| Probe failed at 3 AM and on-call is lost | runbook template in `references\u002Fplatforms-and-ci.md` |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first. If it exists, use it as context and skip questions already answered there. Each answer changes the probe set, the alerting config, or the SLA math.\n\n**Critical flows** (decides which probes you write):\n- What are the 5-10 most important user journeys (login, search, checkout, signup, core workflow)? These become your probe list.\n- Which flows, if broken, cause immediate revenue loss or churn? These get the shortest frequency and page on-call.\n- Are there flows that break silently (data sync, background jobs, webhooks)? Silent failures need probes most — no user reports them.\n- Do you have documented SLAs\u002FSLOs for availability and response time? They set the downtime budget and the alert thresholds.\n\n**Current monitoring** (decides where the gaps are):\n- What exists today (uptime checks, APM, error tracking, dashboards)? Avoid duplicating; find the gap.\n- Are there gaps between what monitoring covers and what users experience? That gap is where probes earn their keep.\n- How do you learn about production issues today (alerts, user reports, social media)? If it's user reports, detection time is your first metric to fix.\n- What was the last outage, and how long before it was detected? Sets the detection-time target probes must beat.\n\n**Infrastructure** (decides regions and CDN assertions):\n- Is the app served from multiple regions or one? Multi-region serving needs multi-region probing.\n- Are there CDN, caching, or edge layers that could mask origin failures? If yes, probes must assert on `x-cache`\u002Forigin headers.\n- Do third-party dependencies (payment, auth, email) have their own monitoring? Their status pages feed your runbooks.\n- What alerting systems exist (PagerDuty, OpsGenie, Slack, email)? Decides the routing config.\n\n**Test accounts** (decides data safety):\n- Do dedicated synthetic test accounts exist in production? Without them, probes pollute real data and analytics.\n- Can test accounts be excluded from analytics, billing, and email campaigns? If not, probe traffic skews every downstream number.\n- Is there API access for programmatic account setup and data cleanup? Decides whether create-then-delete probes are viable.\n\n---\n\n## Core Principles\n\n### 1. Synthetic tests validate the user experience continuously\nRUM tells you what happened; synthetic tells you what is happening right now, whether or not real users are active. At 3 AM when traffic is zero, synthetic probes are the only thing checking the app works. Complement RUM, never replace it: synthetic covers known paths with predictable inputs, RUM discovers the creative ways real users break things.\n\n### 2. Keep probes simple and fast\nA probe that takes 2 minutes and touches 15 pages is not a probe — it is an E2E suite running in production. Probes are short (per-probe wall-clock budget under 30 seconds), focused (one critical path each), and stable (`retries: 0`, zero flakiness tolerance). The 30-second ceiling is a hard budget: a slow probe that \"still passes\" is masking a degradation users feel.\n\n### 3. Alert on trends, not single failures\nA single probe failure is noise — network blips and DNS hiccups cause them constantly. Two consecutive failures are a signal; failures from 2+ regions confirm it is not local. Configure consecutive-failure and multi-region thresholds, or alert fatigue teaches the team to ignore the pager.\n\n### 4. Probes must not affect production data\nProbes run every few minutes, 24\u002F7. Even small side effects (a created record, an incremented counter) compound. Probes must be non-destructive, created data cleaned up immediately, and synthetic traffic excluded from analytics, billing, and — critically — from SLO\u002Ferror-budget math itself, or probes inflate your own reliability numbers.\n\n### 5. Assert on the goal, not the status code\nA login page that returns 200 but never authenticates is broken. A search page that returns 200 with zero results is broken. Probes assert that the user can accomplish their goal — data loads, auth succeeds, results appear — not merely that the page returns a 2xx.\n\n---\n\n## Probe Design\n\nDesign probes around critical user journeys, not infrastructure components. Users do not care if your load balancer is healthy — they care if they can log in and use the product.\n\n| Probe | What It Validates | Frequency | Timeout |\n|-------|-------------------|-----------|---------|\n| Homepage load | DNS, CDN, server, basic rendering | 1 min | 10s |\n| Login flow | Authentication service, session management | 5 min | 15s |\n| Core workflow | Primary value-delivering action (create document, run report) | 5 min | 20s |\n| API health | Backend services, database connectivity | 1 min | 5s |\n| Search | Search index, query processing, result rendering | 5 min | 15s |\n| Checkout (if applicable) | Payment integration (sandbox mode), cart, order creation | 10 min | 25s |\n| Third-party integrations | OAuth providers, email delivery, file storage | 10 min | 15s |\n\n### Probe implementations\n\nThree probe shapes cover most needs: a login flow (Playwright browser), an API health check (status + auth + latency budget), and a search probe (fill query → submit → assert on results, not just status). Keep each to one critical path, a tight timeout, and `retries: 0`. See `references\u002Fprobe-implementations.md` for runnable login-flow, API-health, and search probes plus the environment-aware config.\n\n### Non-destructive probe patterns\n\n```\nSafe patterns:\n  - Read-only operations: GET requests, page loads, searches\n  - Sandbox transactions: payment in test mode, email to internal addresses\n  - Create-then-delete: create a draft, verify, delete immediately\n  - Synthetic flag: operations tagged as synthetic, excluded from processing\n\nDangerous patterns (avoid):\n  - Creating real orders, tickets, or user-facing records\n  - Triggering real notifications (email, SMS, push)\n  - Modifying shared resources (config, permissions, settings)\n  - Operations that cannot be automatically cleaned up\n```\n\n### Dedicated test accounts\n\n```\nAccount requirements:\n  - Clearly identifiable: email contains \"synthetic\" or \"monitor\"\n  - Flagged in database with an is_synthetic flag (is_synthetic = true)\n  - Excluded from analytics, billing, email campaigns, support queues\n  - Excluded from RUM and SLO\u002Ferror-budget pipelines (synthetic traffic is not real traffic)\n  - Pre-populated with stable test data that probes can rely on\n  - Credentials in a secrets manager (process.env), rotated quarterly\n  - Separate accounts per concurrent probe (avoid state conflicts)\n```\n\n---\n\n## Platform Options\n\n| Platform | Strengths | When to Use |\n|----------|-----------|-------------|\n| Checkly | Playwright-native, code-first, Git integration; **Rocky** AI agent (GA 2026) now does automated root-cause analysis across Playwright\u002FAPI\u002FMultistep\u002FTCP\u002FDNS\u002FICMP checks; CLI access from any AI agent; MCP server | Teams already using Playwright for E2E |\n| Datadog Synthetic | Deep APM integration, browser and API tests | Teams on the Datadog platform |\n| Grafana Synthetic Monitoring | Open source, integrates with Grafana dashboards; pairs with k6 2.x; pin a version channel (v1.x\u002Fv2.x) for reproducibility | Teams using the Grafana stack |\n| AWS CloudWatch Synthetics | Blueprints (heartbeat, API, broken-link, visual diff); Python or Node Puppeteer canaries | Teams already on AWS |\n| New Relic Synthetics | Full-stack observability integration | Teams on the New Relic platform |\n| Better Stack | Lightweight uptime + status pages + on-call | SMB-friendly, fast setup |\n| Uptime Kuma | OSS, self-hosted, lightweight | Self-hosting requirement, small surface area |\n| Custom (Playwright \u002F k6 \u002F Puppeteer + cron) | Full control, no vendor lock-in | Budget-constrained or custom requirements |\n\n> Probes can be authored in Playwright (TS\u002FJS), Puppeteer, k6 (JS — k6 2.0 shipped May 2026 with AI-assisted test authoring and a clearer Assertions API; first-class for synthetic), or Python (CloudWatch Synthetics, Checkly). Pick what your team already maintains. Avoid: Pingdom for new setups — it is a legacy uptime tool; prefer code-first alternatives (Checkly, Grafana, custom Playwright) that version-control probes alongside your app.\n\n### Custom and managed implementations\n\nSelf-managed: schedule Playwright probes with a GitHub Actions `schedule` cron (every 5 minutes), inject prod credentials via secrets, and report results to a monitoring webhook. Managed: Checkly is Playwright-native and runs from multiple locations on a fixed frequency. Either way, make probes environment-aware so the same code runs against staging and production with different base URLs and thresholds. See `references\u002Fplatforms-and-ci.md` for the GitHub Actions workflow, the Checkly config, the alert-routing rules, and the runbook template.\n\n---\n\n## Alerting Integration\n\nNot every probe failure is an incident. Configure rules that cut noise while catching real problems.\n\n```\nAlerting rules:\n  - Single failure: log, do not alert (transient network issue)\n  - 2 consecutive failures from same region: warning (possible issue)\n  - 2 consecutive failures from 2+ regions: alert on-call (confirmed outage)\n  - Latency >2x baseline for 10 minutes: warning (performance degradation)\n  - Latency >3x baseline for 5 minutes: alert on-call (severe degradation)\n  - Any probe timeout: alert if 3 consecutive (service unresponsive)\n```\n\n**Routing.** Critical failures on revenue paths (login, checkout, api-health) page on-call (PagerDuty + Slack incidents) with a short repeat interval; warnings on secondary probes go to a Slack monitoring channel; info-level events use a long repeat interval. The probe must tag each result with a `severity` and `probe` label for these routes to match — see the routing note in `references\u002Fplatforms-and-ci.md` for the full `alerting-rules.yaml` and the tagging step.\n\n**Suppress synthetic alerts during planned maintenance.** A maintenance window should silence synthetic paging (the probes will fail by design) and exclude that window from error-budget math, or scheduled work burns budget and pages on-call for nothing.\n\n**Alert message format** — include enough context to start investigating immediately:\n\n```\nAlert template:\n  Title: [SYNTHETIC] {probe_name} failing from {region}\n  Severity: {critical|warning|info}\n  Consecutive failures: {count}\n  Last success: {timestamp}\n  Error: {error_message}\n  Duration: {last_response_time_ms}ms (threshold: {threshold}ms)\n  Dashboard: {link_to_dashboard}\n  Runbook: {link_to_runbook}\n  Regions affected: {list_of_failing_regions}\n```\n\nThe `{link_to_runbook}` points at a per-probe runbook (six lines: what it tests, first checks, manual repro, escalation, dashboard, owner). See the template in `references\u002Fplatforms-and-ci.md`.\n\n---\n\n## SLA Validation\n\n### Availability calculation\n\n```\nAvailability = (total_minutes - downtime_minutes) \u002F total_minutes × 100\n\nWhere:\n  - total_minutes = calendar month in minutes (43,200 for a 30-day month)\n  - downtime_minutes = minutes where synthetic probes detected failure\n\nSLA tiers (downtime\u002Fmonth, monthly basis on 43,200 min):\n  99.0%  = 432 min   = 7h 12min     (basic web app)\n  99.9%  = 43.2 min  = 43min 12s    (business application)\n  99.95% = 21.6 min  = 21min 36s    (critical SaaS)\n  99.99% = 4.32 min  = 4min 19s     (infrastructure\u002Fplatform)\n```\n\n> These are *common* availability targets, not prescriptive tiers. Pick targets from a user-impact analysis, not by tier name. Modern practice (Google SRE Workbook, OpenSLO) favors explicit SLO + error-budget policies over labelled tiers — define what user-visible failure looks like, set the budget user impact tolerates, and let the SLO follow. References: https:\u002F\u002Fsre.google\u002Fworkbook\u002F ; https:\u002F\u002Fopenslo.com\u002F\n\n### Response time percentiles\n\nTrack percentiles, not averages — averages hide the worst experiences.\n\n```\nSLA response time targets (example):\n  Homepage load:  P50 \u003C 1s,    P95 \u003C 3s,   P99 \u003C 5s\n  API response:   P50 \u003C 200ms, P95 \u003C 500ms, P99 \u003C 1s\n  Search results: P50 \u003C 500ms, P95 \u003C 2s,   P99 \u003C 4s\n  Login flow:     P50 \u003C 2s,    P95 \u003C 5s,   P99 \u003C 8s\n```\n\n### Error budget tracking\n\nError budget connects SLA targets to engineering decisions.\n\n```\nError budget calculation:\n  SLO: 99.9% availability on a 43,200-min month\n  Budget: 0.1% of total time = 43.2 minutes\u002Fmonth\n\n  Budget consumed this month: 12 minutes (28%)\n  Budget remaining: 31.2 minutes (72%)\n\nActions by budget status:\n  >50% remaining: normal operations, ship features\n  25-50% remaining: caution, review recent changes\n  \u003C25% remaining: freeze non-critical deploys, focus on reliability\n  Budget exhausted: incident mode, every deploy needs extra scrutiny\n```\n\nExclude synthetic-probe downtime caused by your own maintenance windows from this calculation, or planned work shows as budget burn.\n\n---\n\n## Multi-Region Monitoring\n\nRun probes from regions where your users are. A service that works from us-east-1 but is broken from ap-southeast-1 is broken for APAC users.\n\n```\nRegion selection strategy:\n  - Minimum 3 regions for global services\n  - Always include: closest to primary infrastructure, largest user base, farthest from primary\n  - Example for US-primary service: us-east-1, eu-west-1, ap-southeast-1\n  - Example for EU-primary service: eu-west-1, us-east-1, ap-northeast-1\n```\n\nTrack regional latency separately — a global average hides regional degradation.\n\n```\nRegional latency dashboard:\n  Region       | P50    | P95    | Status\n  us-east-1    | 120ms  | 340ms  | healthy\n  eu-west-1    | 280ms  | 620ms  | healthy\n  ap-southeast | 450ms  | 1200ms | warning (P95 above threshold)\n\nAlert when:\n  - Any region's P95 exceeds its regional threshold\n  - Latency difference between regions exceeds 5x (CDN or routing issue)\n  - A region that was healthy becomes consistently degraded\n```\n\n**CDN validation.** Synthetic probes verify CDN caching by checking response headers (`x-cache`, `cf-cache-status`) for `HIT` and confirming the `server` header matches the expected provider. This catches CDN misconfigurations — and origin failures masked by a stale cache — before users hit slow uncached responses.\n\n---\n\n## Anti-Patterns\n\n### Complex probes that break often\nA probe that navigates 10 pages, fills 5 forms, and asserts on 20 elements is an E2E test, not a synthetic probe. When it breaks, you cannot tell if the app is down or the probe is flaky. **Fix:** one critical path per probe, under 30 seconds, under 5 assertions. A failure should make it immediately clear what is broken.\n\n### Alerting on every single failure\nNetwork blips, DNS hiccups, and transient cloud issues cause occasional failures. Alerting on every one produces noise that teaches the team to ignore alerts. **Fix:** require 2-3 consecutive failures and failures from 2+ regions before paging. Escalating severity: first failure logs, second warns, third pages.\n\n### No test account isolation\nProbes sharing one account interfere — one probe changes a setting, another fails because it expected the default. **Fix:** one dedicated synthetic account per concurrent probe, flagged synthetic, excluded from analytics and billing.\n\n### Monitoring only the happy path\nProbes that only check \"page loads, returns 200\" miss broken functionality behind a loading page. A login that returns 200 but never authenticates is not working. **Fix:** assert on meaningful content — data loads, auth succeeds, the core action completes, search returns results. One \"can the user accomplish their goal\" probe is worth ten \"does the page return 200\" probes.\n\n### No runbook for probe failures\nAn alert fires at 3 AM. On-call sees \"Login probe failing\" but has no idea what to check first, what the probe does, or how to tell a real outage from a probe issue. **Fix:** every probe links a runbook (what it tests; first checks — third-party status, recent deploys, app telemetry; manual repro; escalation; dashboard link). See the template in `references\u002Fplatforms-and-ci.md`.\n\n**Emerging pattern (2026): agent-driven first response.** Tools like Checkly Rocky (GA 2026, automated root-cause analysis across check types) and Honeycomb Canvas Skills (Agent Observability, launched May 2026; open-source `honeycombio\u002Fagent-skill` repo ships a honeycomb-investigator and instrumentation-advisor for Claude Code and Cursor) read probe context + linked runbook + telemetry and post a candidate diagnosis to chat. Treat this as triage assist — it shortens MTTR for routine failures, but it does not replace on-call judgment for novel incidents.\n\n---\n\n## Failure Modes\n\n| Symptom | Likely cause | Fix or check |\n|---------|--------------|--------------|\n| Probe green but users report an outage | Probe asserts only HTTP 200, not the goal | Add content\u002Fstate assertions (dashboard heading, search results count, `body.status`) |\n| Flapping alerts (fire\u002Fresolve repeatedly) | No consecutive-failure or multi-region rule | Require 2+ consecutive failures and 2+ regions before paging |\n| Probe passes locally, fails in CI\u002Fregion | Region-specific outage or CDN routing | Compare per-region results; check latency-difference and `x-cache` assertions |\n| Probe failures with no real outage | Synthetic-account state drift (shared account) | One isolated account per concurrent probe; reset\u002Fseed stable data |\n| Origin is down but probe stays green | CDN serving stale cache | Assert `cf-cache-status`\u002Forigin `server` header, not just 200 |\n| Error budget burns with no incident | Maintenance windows counted as downtime | Suppress synthetic paging during maintenance; exclude window from budget math |\n| On-call paged but can't act | Missing\u002Fempty runbook on the alert | Populate the six-line runbook; verify `{link_to_runbook}` resolves |\n| Reliability numbers look too good | Synthetic traffic counted as real in SLO\u002FRUM | Exclude `is_synthetic` traffic from RUM, billing, and error-budget pipelines |\n\n---\n\n## Verification\n\nProve the monitoring works before trusting it — smallest check first.\n\n1. **Probes pass against staging.** Run `npx playwright test probes\u002F --reporter=list` against staging and confirm every probe passes within its declared timeout (no probe exceeds the 30s ceiling).\n2. **A failure actually pages.** Point one probe at a known-bad URL (a `503` or a wrong path), let it run the configured consecutive-failure count, and confirm the alert routes to on-call within the SLA detection time — and resolves when you revert.\n3. **Assertions are meaningful, not status-only.** Temporarily break the asserted content (rename the dashboard heading on staging) and confirm the probe fails. A probe that stays green here is asserting on the wrong thing.\n4. **Synthetic traffic is excluded.** Query the analytics\u002FRUM\u002Fbilling pipeline for `is_synthetic` traffic and confirm it is filtered out.\n\n---\n\n## Done When\n\n- A probe exists for every critical user journey identified in discovery (not only homepage uptime or a single health endpoint), and each asserts on the goal, not just a 2xx.\n- Each probe's wall-clock budget is under 30s, with `retries: 0`.\n- Alerting config encodes a ≥2 consecutive-failure rule AND a multi-region confirmation rule, and probe results are tagged with `severity` + `probe` so routes match.\n- The SLA dashboard shows current availability and error-budget consumption, and synthetic traffic is excluded from RUM, billing, and error-budget pipelines.\n- A test alert (probe pointed at a failing URL) reaches on-call within the SLA detection time — confirmed once, not assumed.\n- Every probe links a non-empty runbook with first checks, manual repro, and an escalation path.\n- A scheduled review job or recurring calendar item for monitoring health exists (not just an intention to review).\n\n## Reference Files (in `references\u002F`)\n\n- **probe-implementations.md** — Runnable login-flow, API-health, and search probes, plus the environment-aware probe config.\n- **platforms-and-ci.md** — GitHub Actions scheduling workflow, Checkly config, alert-routing rules + tagging note, and the per-probe runbook template.\n\n## Related Skills\n\n- **testing-in-production** — safe-release *techniques* (flags, canary, guardrail metrics) applied *during* a rollout; synthetic monitoring is the schedule-driven validation that runs continuously *after*.\n- **release-readiness** — a one-shot post-deploy smoke gate tied to a specific release lives there; come here for the continuous, schedule-driven version that keeps running long after the release.\n- **observability-driven-testing** — uses production telemetry (including signals from these probes) as *input* to design new tests; this skill instead *produces* the probes and their telemetry.\n- **performance-testing** — load tests measure capacity on demand; synthetic probes track production performance *trends* between those load tests.\n- **qa-metrics** — availability, response-time percentiles, and error-budget consumption from probes feed the quality dashboards defined there.\n- **ci-cd-integration** — go there to wire synthetic probes into a pipeline as a post-deploy verification stage.\n",{"name":5,"license":15,"metadata":52,"description":7},{"author":53,"version":54,"category":55},"kindlmann","2.0","production","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fsynthetic-monitoring","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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add pattanation\u002FNorvik --skill synthetic-monitoring",{"tool":69,"command":70},"bunx","bunx skills add pattanation\u002FNorvik --skill synthetic-monitoring",{"tool":72,"command":73},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill synthetic-monitoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fsynthetic-monitoring\u002FSKILL.md",true,[77,83],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fplatforms-and-ci.md","REFERENCE","参考文档",3847,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fsynthetic-monitoring\u002Freferences\u002Fplatforms-and-ci.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fprobe-implementations.md",5116,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fsynthetic-monitoring\u002Freferences\u002Fprobe-implementations.md",[88,117,143,166,188,203],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":93,"sourceHtmlUrl":94,"categories":95,"keywords":100,"publishedAt":47},"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",[96,97],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[101,43,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116],"webapp","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":121,"sourceHtmlUrl":122,"categories":123,"keywords":125,"publishedAt":47},"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",[124],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[126,127,128,113,129,130,131,103,132,133,106,134,135,136,137,138,139,140,141,142],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":147,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":47},"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",[150],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[152,153,154,155,156,157,158,159,160,161,162,163,164,165],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":170,"sourceHtmlUrl":171,"categories":172,"keywords":175,"publishedAt":47},"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",[173,174],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[176,43,177,163,178,112,179,180,181,158,182,103,183,184,185,135,186,164,187],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":192,"sourceHtmlUrl":193,"categories":194,"keywords":196,"publishedAt":47},"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",[195],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[197,163,198,178,199,181,200,158,186,201,202],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":207,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":47},"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",[210],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[212,163,178,213,155,214,215,216,197,217,218,219,220,221,222,103,223,135,224,225],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]