[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MRPAP5VCW84EAK578B5SC":3,"skill-same:01M71MRPAP5VCW84EAK578B5SC":94},{"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":55,"commitSha":56,"skillDirectory":57,"forksCount":14,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M71MRPAP5VCW84EAK578B5SC","cypress-automation",null,"Build Cypress test suites in TypeScript: E2E tests, component tests, custom commands, cy.intercept network control, cy.session login, Cypress Cloud, and CI integration. Covers retry-ability, the command queue, cross-origin flows with cy.origin, and data-driven testing with fixtures. Use when: \"write E2E test in Cypress,\" \"Cypress page object \u002F custom command,\" \"cy.,\" \"cy.intercept,\" \"Cypress component test,\" \"Cypress Cloud,\" \"cypress.config.ts.\" Not for: Playwright suites — use playwright-automation; flaky-test healing or quarantine — use test-reliability; bulk selector regeneration after a UI refactor — use selector-drift-recovery; Selenium-to-Cypress conversion — use test-migration. Related: playwright-automation, ci-cd-integration, visual-testing, unit-testing, test-reliability.","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\u002Fcypress-automation\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"automation","cypress automation","cypress","login","command","data-driven","component","conversion","drift","when","selenium","ci","testing","flows","e2e test","retry","reliability","unit","bulk","network control","2026-11-10 10:56:23",false,"---\nname: cypress-automation\ndescription: >-\n  Build Cypress test suites in TypeScript: E2E tests, component tests, custom commands,\n  cy.intercept network control, cy.session login, Cypress Cloud, and CI integration.\n  Covers retry-ability, the command queue, cross-origin flows with cy.origin, and\n  data-driven testing with fixtures.\n  Use when: \"write E2E test in Cypress,\" \"Cypress page object \u002F custom command,\" \"cy.,\"\n  \"cy.intercept,\" \"Cypress component test,\" \"Cypress Cloud,\" \"cypress.config.ts.\"\n  Not for: Playwright suites — use playwright-automation; flaky-test healing or quarantine —\n  use test-reliability; bulk selector regeneration after a UI refactor — use selector-drift-recovery;\n  Selenium-to-Cypress conversion — use test-migration.\n  Related: playwright-automation, ci-cd-integration, visual-testing, unit-testing, test-reliability.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: automation\n---\n\n\u003Cobjective>\nProduction-grade Cypress test suites in TypeScript. The failure this prevents: tests written as if Cypress commands ran synchronously (storing `cy.get()` in a variable, `await cy.click()`), and tests that flake because they wait on `cy.wait(3000)` instead of a network alias. This skill covers the mental model (command queue, retry-ability), project structure, custom commands, network control with `cy.intercept`, component testing, cross-origin auth with `cy.origin`, and Cypress Cloud \u002F CI integration.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| You need to... | Go to |\n|----------------|-------|\n| Write an E2E spec (load, intercept, assert) | Core Principles + `references\u002Fintercept-patterns.md` |\n| Add a typed custom command \u002F `cy.session` login | Custom Commands + `references\u002Fconfig-and-commands.md` |\n| Mount and test a single component | Component Testing + `references\u002Fcomponent-and-fixtures.md` |\n| Scaffold `cypress.config.ts` \u002F project layout | Project Structure + `references\u002Fconfig-and-commands.md` |\n| Stub, spy, simulate errors, or poll an API | cy.intercept Patterns + `references\u002Fintercept-patterns.md` |\n| Run in CI \u002F parallelize on Cypress Cloud | CI Integration + `references\u002Fci-recipes.md` |\n| Handle an SSO \u002F OAuth redirect | Cross-Origin Flows + `references\u002Fintercept-patterns.md` |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first -- if it exists, use it and skip questions already answered there.\n\n1. **Component testing, E2E, or both?** Component testing mounts individual components in isolation; E2E tests the full app through the browser. Most projects need both. Component testing requires a framework-specific mount (React, Vue, Angular, Svelte).\n2. **Cypress Cloud?** Cloud provides parallelization, flake detection, analytics, Test Replay, and the AI add-on. If the team uses it, configure `projectId` and the record key. If not, everything runs locally or in CI without Cloud.\n3. **TypeScript?** Strongly recommended and the default here -- Cypress supports it natively. All examples use TypeScript.\n4. **Framework and bundler?** React + Vite, Next.js + Webpack, Vue + Vite, Angular -- component-testing config depends on this.\n5. **Cross-origin auth?** If login redirects to a separate domain (SSO, OAuth provider), you need `cy.origin`. Note it now so the login command is built for it.\n6. **Existing suite or fresh start?** If migrating, start with the flakiest or most critical tests, not a big-bang rewrite (see `test-migration`).\n\n---\n\n## Core Principles\n\n### 1. Commands Are Enqueued, Not Executed Immediately\n\nThe single most important concept. Cypress commands (`cy.get`, `cy.click`, `cy.type`) do not execute when called -- they are added to a queue and run serially, asynchronously. You cannot use `async\u002Fawait` with Cypress commands, and you cannot store the return value in a variable.\n\n```typescript\n\u002F\u002F WRONG -- this looks synchronous but is not\nconst button = cy.get('[data-testid=\"submit\"]'); \u002F\u002F button is a Chainable, not an element\nbutton.click(); \u002F\u002F works only by accident, via chaining\n\n\u002F\u002F CORRECT -- chain commands; use .then() when you need a value\ncy.get('[data-testid=\"submit\"]').click();\n\ncy.get('[data-testid=\"price\"]').invoke('text').then((text) => {\n  const price = parseFloat(text.replace('$', ''));\n  expect(price).to.be.greaterThan(0);\n});\n```\n\n### 2. Retry-ability Is Built-In (For Queries, Not Actions)\n\nCypress automatically retries **queries** (`cy.get`, `cy.find`, `cy.contains`) and **assertions** until they pass or time out. It does **not** retry **actions** (`cy.click`, `cy.type`, `cy.select`):\n\n- `cy.get('.loading').should('not.exist')` waits for the indicator to disappear\n- `cy.get('.item').should('have.length', 5)` waits for 5 items\n- `cy.click()` executes once -- if the element is not actionable, it fails\n\n### 3. Network Control with cy.intercept\n\n`cy.intercept` intercepts HTTP requests at the network layer -- stub responses, wait for requests to complete, assert on request bodies. Mastering it is the difference between flaky and stable tests. Always wait on a network alias or a DOM assertion, never a fixed `cy.wait(ms)`.\n\n### 4. Isolation: Each Test Starts Clean\n\nEvery `it()` runs in fresh browser state -- Cypress clears cookies, localStorage, and sessionStorage between tests by default. Tests must not depend on other tests' state or order. Use `beforeEach` for shared setup, not inter-test dependencies.\n\n### 5. Data Attributes for Test Selectors\n\nUse `data-testid`, `data-cy`, or `data-test`. They survive CSS refactors, class renames, and localization. Configure the preferred attribute in `cypress.config.ts`.\n\n---\n\n## Project Structure & Configuration\n\nStandard layout splits `e2e\u002F`, `component\u002F`, `fixtures\u002F`, and `support\u002F`, with `cypress.config.ts` at the root configuring both runners. Key config choices: `baseUrl` from env (never hardcode for CI), explicit viewport, `retries.runMode: 2` for CI, and the framework\u002Fbundler pair under `component.devServer`. Component specs live under `cypress\u002Fcomponent\u002F**\u002F*.cy.tsx`.\n\nSee `references\u002Fconfig-and-commands.md` for the directory tree, the complete `cypress.config.ts`, and the `tsconfig.json` additions.\n\n---\n\n## Custom Commands\n\nCustom commands encapsulate repeated actions behind a clean, typed API. Common commands: `login` (via `cy.session` + API, not UI), a `getByTestId` selector shorthand, and assertion helpers like `shouldShowToast`. Declare them in `cypress\u002Fsupport\u002Findex.d.ts` (`declare namespace Cypress { interface Chainable { ... } }` with JSDoc `@example`) so they get autocomplete and compile-time checking.\n\n**`cy.session` needs a `validate()` callback.** `cy.session` caches cookies\u002FlocalStorage\u002FsessionStorage automatically, but without `validate()` the cached session is never re-verified -- a stale or expired token silently reuses a dead session. Always pass a `validate()` that hits an authenticated endpoint (e.g. `cy.request('\u002Fapi\u002Fme').its('status').should('eq', 200)`).\n\n**Retryable lookups use `Cypress.Commands.addQuery()`, and the callback must be a non-arrow `function () {}`** -- Cypress binds `this` to apply the command timeout, so an arrow function silently breaks retry-ability. (Intercept handlers are the opposite: `(req) => {}` is fine there because they do not use `this`.)\n\nSee `references\u002Fconfig-and-commands.md` for the full command definitions, the `validate()` callback, the `addQuery` example, and the TypeScript declarations.\n\n---\n\n## cy.intercept Patterns\n\n`cy.intercept` covers the full network-control surface:\n\n- **Stub a response** — return canned data with `{ statusCode, body }`, then `cy.wait('@alias')`.\n- **Spy without stubbing** — `cy.intercept('POST', '\u002Fapi\u002Forders').as('createOrder')`, then assert on `interception.request.body` and `interception.response?.statusCode`.\n- **Conditional responses** — drive a closure with `callCount` to simulate polling (202 → 200). The handler arrow function `(req) => { ... }` is correct here.\n- **Network errors** — `{ statusCode: 500 }`, `{ forceNetworkError: true }`, or `req.reply({ delay })` for slow responses.\n- **Modify real responses** — `req.continue((res) => { ...; res.send(); })`.\n- **Fixture-backed** — `{ fixture: 'api-responses\u002Fcheckout-success.json' }`.\n\nRegister the intercept **before** the action that triggers the request, or the alias never matches.\n\nSee `references\u002Fintercept-patterns.md` for runnable code for each, plus cross-origin flows.\n\n---\n\n## Component Testing\n\nComponent testing mounts a single component in a real browser without running the full app -- faster than E2E, more visual feedback than unit tests. Use `cy.mount(\u003CComponent ...\u002F>)`, pass `cy.stub()`\u002F`cy.spy()` for callbacks, and assert with the same `cy.contains`\u002F`cy.get` chain you use in E2E. Never use `cy.visit` in a component test. For Vue, use `cy.mount(Component, { props: { ... } })`.\n\nSee `references\u002Fcomponent-and-fixtures.md` for a full React `ProductCard` component-test suite.\n\n---\n\n## Data-Driven Testing with Fixtures\n\nThree layers, depending on where the data comes from:\n\n- **Static fixtures** — `cy.fixture('users').as('users')` for JSON that rarely changes; read it via `this.users` in a `beforeEach(function () { ... })`.\n- **Dynamic data via `cy.task`** — register Node-side tasks in `setupNodeEvents` for API calls or DB seeding that must run outside the browser (task bodies run in Node, so `fetch` there is Node's global fetch, not a Cypress API).\n- **Environment-specific config** — merge a per-environment `baseUrl` map in `setupNodeEvents`, selected by `--env ENVIRONMENT=...`.\n\nSee `references\u002Fcomponent-and-fixtures.md` for the fixture, `cy.task` seeding, and env-config code.\n\n---\n\n## Cross-Origin Flows\n\nFor legitimate redirects to another domain (SSO, OAuth providers, a separate auth host), wrap the commands that run on the other origin in `cy.origin`. This replaced the old `chromeWebSecurity: false` \u002F `experimentalSessionAndOrigin` escape hatches -- do not disable web security to work around a redirect. This is distinct from third-party payment iframes (Stripe\u002FPayPal), which you stub with `cy.intercept` and never reach into.\n\nSee `references\u002Fintercept-patterns.md` (Cross-Origin Flows) for the `cy.origin` example.\n\n---\n\n## CI Integration\n\n**Action version:** pin to `cypress-io\u002Fgithub-action@v7` (latest 7.2.0, May 2026). v7 runs under Node 24 and is the current major; use `@v6` only on a Node 20 runner (the legacy branch).\n\n> **Cypress \u002F Node support:** Current is Cypress 15.x, which supports Node 20, 22, and 24 (Node 18 and 23 dropped). Node 20 removal is a future Cypress 16 \u002F action-v7.2 concern tracking the Node 20 EOL (2026-04-30), not something Cypress 15 did.\n\n- **With Cypress Cloud:** set `projectId`, run `npx cypress run --record --key $CYPRESS_RECORD_KEY`, and parallelize across a container matrix (`fail-fast: false`) for flake detection, Test Replay, and analytics.\n- **Without Cloud:** use `cypress-io\u002Fgithub-action@v7` with `build`\u002F`start`\u002F`wait-on`, and upload `cypress\u002Fscreenshots` + `cypress\u002Fvideos` as artifacts on failure.\n\nSee `references\u002Fci-recipes.md` for both complete GitHub Actions workflows.\n\n**Cypress AI (paid Cloud add-on, GA 2026)** ships Auto Heal (selector self-healing), AI Test Generation, and AI Bug Triage. Now GA and worth knowing: `cy.prompt` (English-to-test authoring with runtime self-healing) and **Cloud MCP** (GA May 2026, free on all Cloud plans) — an MCP server that feeds recorded-run errors, stack traces, and Test Replay links to your AI assistant. This overlaps `test-reliability` (selector healing), `ai-bug-triage` (failure clustering), and `ai-test-generation` (authoring). If the team is already on Cypress Cloud, buying the add-on may be cheaper than building the equivalent -- flag it during framework selection.\n\n---\n\n## Anti-Patterns\n\n### 1. cy.wait(milliseconds) for Synchronization\n\n```typescript\n\u002F\u002F BAD\ncy.get('[data-testid=\"submit\"]').click();\ncy.wait(3000);\n\n\u002F\u002F GOOD -- wait for network\ncy.intercept('POST', '\u002Fapi\u002Fsubmit').as('submit');\ncy.get('[data-testid=\"submit\"]').click();\ncy.wait('@submit');\n```\n\nOnly acceptable for throttle\u002Fdebounce testing. Everything else waits on a network alias or a DOM assertion.\n\n### 2. Conditional Testing Based on DOM State\n\nDo not check `$body.find(selector).length > 0` to conditionally act. Control state deterministically -- stub the API that drives the conditional element.\n\n### 3. CSS Selectors Over Data Attributes\n\n`cy.get('.btn.btn-primary > span')` breaks on every CSS refactor. Use `cy.getByTestId('submit')` or `cy.contains('button', 'Place Order')`.\n\n### 4. Sharing State Between Tests\n\nModule-level `let orderId` set in one `it()` and read in another creates order-dependent, parallel-unsafe tests. Each test sets up its own data via `cy.request` or `cy.task` in `beforeEach`.\n\n### 5. Testing Third-Party Iframes\n\nDo not reach into Stripe\u002FPayPal iframes. Mock the payment API with `cy.intercept` and assert on your own UI.\n\n### 6. Not Using cy.session() for Login (or Omitting validate())\n\nUI login in every test is slow and fragile. Use `cy.session` to authenticate via API once and cache it -- with a `validate()` callback so an expired token does not silently reuse a dead session.\n\n### 7. Arrow Function in addQuery\n\nA custom query written with `addQuery('name', (arg) => { ... })` silently loses its retry timeout because Cypress needs `this`. Use `function (arg) { ... }`.\n\n### 8. Running All Tests Serially in CI\n\nParallelize once the suite exceeds 5 minutes -- Cypress Cloud, `cypress-split`, or manual sharding across a CI matrix.\n\n---\n\n## Failure Modes\n\n| Symptom | Likely cause | Fix |\n|---------|--------------|-----|\n| `element is detached from the DOM` | A yielded element was reused after a re-render | Re-query inside `.should`\u002F`.then` instead of holding the old reference |\n| `cy.intercept` did not match \u002F alias never resolves | Wrong method or glob, or intercept registered after the action | Register the intercept before the triggering command; verify method + URL glob |\n| `cross origin` error on redirect | Login or flow crosses to another domain | Wrap the other-origin commands in `cy.origin`; do not disable `chromeWebSecurity` |\n| Session reused but user is logged out | `cy.session` has no `validate()`, token expired | Add a `validate()` callback that hits an authenticated endpoint |\n| Custom query never times out \u002F retries forever | `addQuery` callback is an arrow function | Convert to `function () {}` so Cypress can bind `this` |\n\n---\n\n## Verification\n\nProve the suite runs before calling it done:\n\n- `npx cypress verify` — confirms the Cypress binary is installed and runnable.\n- `npx cypress run --spec \"cypress\u002Fe2e\u002F\u003Cfile>.cy.ts\"` — should exit 0 (headless, in CI mode).\n- `npx cypress run --component --spec \"cypress\u002Fcomponent\u002F\u003CFile>.cy.tsx\"` — component specs exit 0.\n- `npx tsc --noEmit` — custom-command declarations in `index.d.ts` compile against the test files.\n\n---\n\n## Done When\n\n- `cypress.config.ts` exists with a `baseUrl` from env (not hardcoded `localhost` in CI) and explicit `viewportWidth`\u002F`viewportHeight`; `npx cypress verify` passes.\n- Custom commands extracted to `cypress\u002Fsupport\u002Fcommands.ts` with TypeScript declarations in `cypress\u002Fsupport\u002Findex.d.ts`; `npx tsc --noEmit` exits 0.\n- The `login` command uses `cy.session` with a `validate()` callback.\n- No `cy.wait(\u003Cnumber>)` for synchronization in the suite (`grep -rn \"cy.wait([0-9]\" cypress\u002F` returns nothing except documented throttle\u002Fdebounce cases).\n- Component specs live under `cypress\u002Fcomponent\u002F**\u002F*.cy.tsx` and run with `npx cypress run --component` exiting 0.\n- E2E specs pass in CI (`npx cypress run` exits 0) with either a recorded Cypress Cloud run (parallel) or local video\u002Fscreenshot artifacts uploaded on failure.\n\n## Reference Files (in `references\u002F`)\n\n- **config-and-commands.md** — Project directory tree, full `cypress.config.ts`, and custom commands (`cy.session` + `validate()`, the non-arrow `addQuery`) with TypeScript declarations.\n- **intercept-patterns.md** — Every `cy.intercept` recipe (stub, spy, conditional\u002Fpolling, error simulation, response modification, fixture-backed) plus cross-origin flows with `cy.origin`.\n- **component-and-fixtures.md** — React component-test suite plus data-driven testing (static fixtures, `cy.task` seeding, env-specific config).\n- **ci-recipes.md** — GitHub Actions workflows with and without Cypress Cloud, on `@v7`, with parallelization and artifact upload.\n\n## Related Skills\n\n- **playwright-automation** — Use instead of this skill when the suite is Playwright, not Cypress. Same E2E goals, different runner and API.\n- **test-reliability** — Go here for runtime per-test flake healing, self-healing locators, and quarantine. This skill writes stable tests; that one repairs failing ones.\n- **selector-drift-recovery** — Bulk-regenerate broken selectors after a UI refactor or redesign; this skill is for authoring, not mass repair.\n- **test-migration** — Converting Selenium\u002Fother suites to Cypress.\n- **ci-cd-integration** — Pipeline templates for running Cypress in GitHub Actions \u002F GitLab CI, parallelization, and artifact management.\n- **visual-testing** — Visual regression to complement Cypress functional tests; Cypress has no built-in pixel comparison.\n- **unit-testing** — Jest\u002FVitest for logic that needs no browser; Cypress component tests fill the gap between unit and E2E.\n- **test-data-management** — Seeding, managing, and cleaning up the test data Cypress tests consume.\n- **qa-project-context** — The project context file capturing framework choices, CI platform, and conventions.\n","\u003Cobjective>\nProduction-grade Cypress test suites in TypeScript. The failure this prevents: tests written as if Cypress commands ran synchronously (storing `cy.get()` in a variable, `await cy.click()`), and tests that flake because they wait on `cy.wait(3000)` instead of a network alias. This skill covers the mental model (command queue, retry-ability), project structure, custom commands, network control with `cy.intercept`, component testing, cross-origin auth with `cy.origin`, and Cypress Cloud \u002F CI integration.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| You need to... | Go to |\n|----------------|-------|\n| Write an E2E spec (load, intercept, assert) | Core Principles + `references\u002Fintercept-patterns.md` |\n| Add a typed custom command \u002F `cy.session` login | Custom Commands + `references\u002Fconfig-and-commands.md` |\n| Mount and test a single component | Component Testing + `references\u002Fcomponent-and-fixtures.md` |\n| Scaffold `cypress.config.ts` \u002F project layout | Project Structure + `references\u002Fconfig-and-commands.md` |\n| Stub, spy, simulate errors, or poll an API | cy.intercept Patterns + `references\u002Fintercept-patterns.md` |\n| Run in CI \u002F parallelize on Cypress Cloud | CI Integration + `references\u002Fci-recipes.md` |\n| Handle an SSO \u002F OAuth redirect | Cross-Origin Flows + `references\u002Fintercept-patterns.md` |\n\n---\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first -- if it exists, use it and skip questions already answered there.\n\n1. **Component testing, E2E, or both?** Component testing mounts individual components in isolation; E2E tests the full app through the browser. Most projects need both. Component testing requires a framework-specific mount (React, Vue, Angular, Svelte).\n2. **Cypress Cloud?** Cloud provides parallelization, flake detection, analytics, Test Replay, and the AI add-on. If the team uses it, configure `projectId` and the record key. If not, everything runs locally or in CI without Cloud.\n3. **TypeScript?** Strongly recommended and the default here -- Cypress supports it natively. All examples use TypeScript.\n4. **Framework and bundler?** React + Vite, Next.js + Webpack, Vue + Vite, Angular -- component-testing config depends on this.\n5. **Cross-origin auth?** If login redirects to a separate domain (SSO, OAuth provider), you need `cy.origin`. Note it now so the login command is built for it.\n6. **Existing suite or fresh start?** If migrating, start with the flakiest or most critical tests, not a big-bang rewrite (see `test-migration`).\n\n---\n\n## Core Principles\n\n### 1. Commands Are Enqueued, Not Executed Immediately\n\nThe single most important concept. Cypress commands (`cy.get`, `cy.click`, `cy.type`) do not execute when called -- they are added to a queue and run serially, asynchronously. You cannot use `async\u002Fawait` with Cypress commands, and you cannot store the return value in a variable.\n\n```typescript\n\u002F\u002F WRONG -- this looks synchronous but is not\nconst button = cy.get('[data-testid=\"submit\"]'); \u002F\u002F button is a Chainable, not an element\nbutton.click(); \u002F\u002F works only by accident, via chaining\n\n\u002F\u002F CORRECT -- chain commands; use .then() when you need a value\ncy.get('[data-testid=\"submit\"]').click();\n\ncy.get('[data-testid=\"price\"]').invoke('text').then((text) => {\n  const price = parseFloat(text.replace('$', ''));\n  expect(price).to.be.greaterThan(0);\n});\n```\n\n### 2. Retry-ability Is Built-In (For Queries, Not Actions)\n\nCypress automatically retries **queries** (`cy.get`, `cy.find`, `cy.contains`) and **assertions** until they pass or time out. It does **not** retry **actions** (`cy.click`, `cy.type`, `cy.select`):\n\n- `cy.get('.loading').should('not.exist')` waits for the indicator to disappear\n- `cy.get('.item').should('have.length', 5)` waits for 5 items\n- `cy.click()` executes once -- if the element is not actionable, it fails\n\n### 3. Network Control with cy.intercept\n\n`cy.intercept` intercepts HTTP requests at the network layer -- stub responses, wait for requests to complete, assert on request bodies. Mastering it is the difference between flaky and stable tests. Always wait on a network alias or a DOM assertion, never a fixed `cy.wait(ms)`.\n\n### 4. Isolation: Each Test Starts Clean\n\nEvery `it()` runs in fresh browser state -- Cypress clears cookies, localStorage, and sessionStorage between tests by default. Tests must not depend on other tests' state or order. Use `beforeEach` for shared setup, not inter-test dependencies.\n\n### 5. Data Attributes for Test Selectors\n\nUse `data-testid`, `data-cy`, or `data-test`. They survive CSS refactors, class renames, and localization. Configure the preferred attribute in `cypress.config.ts`.\n\n---\n\n## Project Structure & Configuration\n\nStandard layout splits `e2e\u002F`, `component\u002F`, `fixtures\u002F`, and `support\u002F`, with `cypress.config.ts` at the root configuring both runners. Key config choices: `baseUrl` from env (never hardcode for CI), explicit viewport, `retries.runMode: 2` for CI, and the framework\u002Fbundler pair under `component.devServer`. Component specs live under `cypress\u002Fcomponent\u002F**\u002F*.cy.tsx`.\n\nSee `references\u002Fconfig-and-commands.md` for the directory tree, the complete `cypress.config.ts`, and the `tsconfig.json` additions.\n\n---\n\n## Custom Commands\n\nCustom commands encapsulate repeated actions behind a clean, typed API. Common commands: `login` (via `cy.session` + API, not UI), a `getByTestId` selector shorthand, and assertion helpers like `shouldShowToast`. Declare them in `cypress\u002Fsupport\u002Findex.d.ts` (`declare namespace Cypress { interface Chainable { ... } }` with JSDoc `@example`) so they get autocomplete and compile-time checking.\n\n**`cy.session` needs a `validate()` callback.** `cy.session` caches cookies\u002FlocalStorage\u002FsessionStorage automatically, but without `validate()` the cached session is never re-verified -- a stale or expired token silently reuses a dead session. Always pass a `validate()` that hits an authenticated endpoint (e.g. `cy.request('\u002Fapi\u002Fme').its('status').should('eq', 200)`).\n\n**Retryable lookups use `Cypress.Commands.addQuery()`, and the callback must be a non-arrow `function () {}`** -- Cypress binds `this` to apply the command timeout, so an arrow function silently breaks retry-ability. (Intercept handlers are the opposite: `(req) => {}` is fine there because they do not use `this`.)\n\nSee `references\u002Fconfig-and-commands.md` for the full command definitions, the `validate()` callback, the `addQuery` example, and the TypeScript declarations.\n\n---\n\n## cy.intercept Patterns\n\n`cy.intercept` covers the full network-control surface:\n\n- **Stub a response** — return canned data with `{ statusCode, body }`, then `cy.wait('@alias')`.\n- **Spy without stubbing** — `cy.intercept('POST', '\u002Fapi\u002Forders').as('createOrder')`, then assert on `interception.request.body` and `interception.response?.statusCode`.\n- **Conditional responses** — drive a closure with `callCount` to simulate polling (202 → 200). The handler arrow function `(req) => { ... }` is correct here.\n- **Network errors** — `{ statusCode: 500 }`, `{ forceNetworkError: true }`, or `req.reply({ delay })` for slow responses.\n- **Modify real responses** — `req.continue((res) => { ...; res.send(); })`.\n- **Fixture-backed** — `{ fixture: 'api-responses\u002Fcheckout-success.json' }`.\n\nRegister the intercept **before** the action that triggers the request, or the alias never matches.\n\nSee `references\u002Fintercept-patterns.md` for runnable code for each, plus cross-origin flows.\n\n---\n\n## Component Testing\n\nComponent testing mounts a single component in a real browser without running the full app -- faster than E2E, more visual feedback than unit tests. Use `cy.mount(\u003CComponent ...\u002F>)`, pass `cy.stub()`\u002F`cy.spy()` for callbacks, and assert with the same `cy.contains`\u002F`cy.get` chain you use in E2E. Never use `cy.visit` in a component test. For Vue, use `cy.mount(Component, { props: { ... } })`.\n\nSee `references\u002Fcomponent-and-fixtures.md` for a full React `ProductCard` component-test suite.\n\n---\n\n## Data-Driven Testing with Fixtures\n\nThree layers, depending on where the data comes from:\n\n- **Static fixtures** — `cy.fixture('users').as('users')` for JSON that rarely changes; read it via `this.users` in a `beforeEach(function () { ... })`.\n- **Dynamic data via `cy.task`** — register Node-side tasks in `setupNodeEvents` for API calls or DB seeding that must run outside the browser (task bodies run in Node, so `fetch` there is Node's global fetch, not a Cypress API).\n- **Environment-specific config** — merge a per-environment `baseUrl` map in `setupNodeEvents`, selected by `--env ENVIRONMENT=...`.\n\nSee `references\u002Fcomponent-and-fixtures.md` for the fixture, `cy.task` seeding, and env-config code.\n\n---\n\n## Cross-Origin Flows\n\nFor legitimate redirects to another domain (SSO, OAuth providers, a separate auth host), wrap the commands that run on the other origin in `cy.origin`. This replaced the old `chromeWebSecurity: false` \u002F `experimentalSessionAndOrigin` escape hatches -- do not disable web security to work around a redirect. This is distinct from third-party payment iframes (Stripe\u002FPayPal), which you stub with `cy.intercept` and never reach into.\n\nSee `references\u002Fintercept-patterns.md` (Cross-Origin Flows) for the `cy.origin` example.\n\n---\n\n## CI Integration\n\n**Action version:** pin to `cypress-io\u002Fgithub-action@v7` (latest 7.2.0, May 2026). v7 runs under Node 24 and is the current major; use `@v6` only on a Node 20 runner (the legacy branch).\n\n> **Cypress \u002F Node support:** Current is Cypress 15.x, which supports Node 20, 22, and 24 (Node 18 and 23 dropped). Node 20 removal is a future Cypress 16 \u002F action-v7.2 concern tracking the Node 20 EOL (2026-04-30), not something Cypress 15 did.\n\n- **With Cypress Cloud:** set `projectId`, run `npx cypress run --record --key $CYPRESS_RECORD_KEY`, and parallelize across a container matrix (`fail-fast: false`) for flake detection, Test Replay, and analytics.\n- **Without Cloud:** use `cypress-io\u002Fgithub-action@v7` with `build`\u002F`start`\u002F`wait-on`, and upload `cypress\u002Fscreenshots` + `cypress\u002Fvideos` as artifacts on failure.\n\nSee `references\u002Fci-recipes.md` for both complete GitHub Actions workflows.\n\n**Cypress AI (paid Cloud add-on, GA 2026)** ships Auto Heal (selector self-healing), AI Test Generation, and AI Bug Triage. Now GA and worth knowing: `cy.prompt` (English-to-test authoring with runtime self-healing) and **Cloud MCP** (GA May 2026, free on all Cloud plans) — an MCP server that feeds recorded-run errors, stack traces, and Test Replay links to your AI assistant. This overlaps `test-reliability` (selector healing), `ai-bug-triage` (failure clustering), and `ai-test-generation` (authoring). If the team is already on Cypress Cloud, buying the add-on may be cheaper than building the equivalent -- flag it during framework selection.\n\n---\n\n## Anti-Patterns\n\n### 1. cy.wait(milliseconds) for Synchronization\n\n```typescript\n\u002F\u002F BAD\ncy.get('[data-testid=\"submit\"]').click();\ncy.wait(3000);\n\n\u002F\u002F GOOD -- wait for network\ncy.intercept('POST', '\u002Fapi\u002Fsubmit').as('submit');\ncy.get('[data-testid=\"submit\"]').click();\ncy.wait('@submit');\n```\n\nOnly acceptable for throttle\u002Fdebounce testing. Everything else waits on a network alias or a DOM assertion.\n\n### 2. Conditional Testing Based on DOM State\n\nDo not check `$body.find(selector).length > 0` to conditionally act. Control state deterministically -- stub the API that drives the conditional element.\n\n### 3. CSS Selectors Over Data Attributes\n\n`cy.get('.btn.btn-primary > span')` breaks on every CSS refactor. Use `cy.getByTestId('submit')` or `cy.contains('button', 'Place Order')`.\n\n### 4. Sharing State Between Tests\n\nModule-level `let orderId` set in one `it()` and read in another creates order-dependent, parallel-unsafe tests. Each test sets up its own data via `cy.request` or `cy.task` in `beforeEach`.\n\n### 5. Testing Third-Party Iframes\n\nDo not reach into Stripe\u002FPayPal iframes. Mock the payment API with `cy.intercept` and assert on your own UI.\n\n### 6. Not Using cy.session() for Login (or Omitting validate())\n\nUI login in every test is slow and fragile. Use `cy.session` to authenticate via API once and cache it -- with a `validate()` callback so an expired token does not silently reuse a dead session.\n\n### 7. Arrow Function in addQuery\n\nA custom query written with `addQuery('name', (arg) => { ... })` silently loses its retry timeout because Cypress needs `this`. Use `function (arg) { ... }`.\n\n### 8. Running All Tests Serially in CI\n\nParallelize once the suite exceeds 5 minutes -- Cypress Cloud, `cypress-split`, or manual sharding across a CI matrix.\n\n---\n\n## Failure Modes\n\n| Symptom | Likely cause | Fix |\n|---------|--------------|-----|\n| `element is detached from the DOM` | A yielded element was reused after a re-render | Re-query inside `.should`\u002F`.then` instead of holding the old reference |\n| `cy.intercept` did not match \u002F alias never resolves | Wrong method or glob, or intercept registered after the action | Register the intercept before the triggering command; verify method + URL glob |\n| `cross origin` error on redirect | Login or flow crosses to another domain | Wrap the other-origin commands in `cy.origin`; do not disable `chromeWebSecurity` |\n| Session reused but user is logged out | `cy.session` has no `validate()`, token expired | Add a `validate()` callback that hits an authenticated endpoint |\n| Custom query never times out \u002F retries forever | `addQuery` callback is an arrow function | Convert to `function () {}` so Cypress can bind `this` |\n\n---\n\n## Verification\n\nProve the suite runs before calling it done:\n\n- `npx cypress verify` — confirms the Cypress binary is installed and runnable.\n- `npx cypress run --spec \"cypress\u002Fe2e\u002F\u003Cfile>.cy.ts\"` — should exit 0 (headless, in CI mode).\n- `npx cypress run --component --spec \"cypress\u002Fcomponent\u002F\u003CFile>.cy.tsx\"` — component specs exit 0.\n- `npx tsc --noEmit` — custom-command declarations in `index.d.ts` compile against the test files.\n\n---\n\n## Done When\n\n- `cypress.config.ts` exists with a `baseUrl` from env (not hardcoded `localhost` in CI) and explicit `viewportWidth`\u002F`viewportHeight`; `npx cypress verify` passes.\n- Custom commands extracted to `cypress\u002Fsupport\u002Fcommands.ts` with TypeScript declarations in `cypress\u002Fsupport\u002Findex.d.ts`; `npx tsc --noEmit` exits 0.\n- The `login` command uses `cy.session` with a `validate()` callback.\n- No `cy.wait(\u003Cnumber>)` for synchronization in the suite (`grep -rn \"cy.wait([0-9]\" cypress\u002F` returns nothing except documented throttle\u002Fdebounce cases).\n- Component specs live under `cypress\u002Fcomponent\u002F**\u002F*.cy.tsx` and run with `npx cypress run --component` exiting 0.\n- E2E specs pass in CI (`npx cypress run` exits 0) with either a recorded Cypress Cloud run (parallel) or local video\u002Fscreenshot artifacts uploaded on failure.\n\n## Reference Files (in `references\u002F`)\n\n- **config-and-commands.md** — Project directory tree, full `cypress.config.ts`, and custom commands (`cy.session` + `validate()`, the non-arrow `addQuery`) with TypeScript declarations.\n- **intercept-patterns.md** — Every `cy.intercept` recipe (stub, spy, conditional\u002Fpolling, error simulation, response modification, fixture-backed) plus cross-origin flows with `cy.origin`.\n- **component-and-fixtures.md** — React component-test suite plus data-driven testing (static fixtures, `cy.task` seeding, env-specific config).\n- **ci-recipes.md** — GitHub Actions workflows with and without Cypress Cloud, on `@v7`, with parallelization and artifact upload.\n\n## Related Skills\n\n- **playwright-automation** — Use instead of this skill when the suite is Playwright, not Cypress. Same E2E goals, different runner and API.\n- **test-reliability** — Go here for runtime per-test flake healing, self-healing locators, and quarantine. This skill writes stable tests; that one repairs failing ones.\n- **selector-drift-recovery** — Bulk-regenerate broken selectors after a UI refactor or redesign; this skill is for authoring, not mass repair.\n- **test-migration** — Converting Selenium\u002Fother suites to Cypress.\n- **ci-cd-integration** — Pipeline templates for running Cypress in GitHub Actions \u002F GitLab CI, parallelization, and artifact management.\n- **visual-testing** — Visual regression to complement Cypress functional tests; Cypress has no built-in pixel comparison.\n- **unit-testing** — Jest\u002FVitest for logic that needs no browser; Cypress component tests fill the gap between unit and E2E.\n- **test-data-management** — Seeding, managing, and cleaning up the test data Cypress tests consume.\n- **qa-project-context** — The project context file capturing framework choices, CI platform, and conventions.\n",{"name":5,"license":15,"metadata":52,"description":7},{"author":53,"version":54,"category":27},"kindlmann","2.0","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fcypress-automation","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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add pattanation\u002FNorvik --skill cypress-automation",{"tool":68,"command":69},"bunx","bunx skills add pattanation\u002FNorvik --skill cypress-automation",{"tool":71,"command":72},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill cypress-automation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcypress-automation\u002FSKILL.md",true,[76,82,86,90],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fci-recipes.md","REFERENCE","参考文档",1495,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcypress-automation\u002Freferences\u002Fci-recipes.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fcomponent-and-fixtures.md",3329,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcypress-automation\u002Freferences\u002Fcomponent-and-fixtures.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fconfig-and-commands.md",5160,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcypress-automation\u002Freferences\u002Fconfig-and-commands.md",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fintercept-patterns.md",3536,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcypress-automation\u002Freferences\u002Fintercept-patterns.md",[95,125,151,174,195,210],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":100,"sourceHtmlUrl":101,"categories":102,"keywords":107,"publishedAt":124},"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",[103,104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[108,39,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123],"webapp","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":129,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":124},"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",[132],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},[134,135,136,120,137,138,139,110,140,141,113,142,143,144,145,146,147,148,149,150],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":155,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":124},"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",[158],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},[160,161,162,163,164,165,166,167,168,169,170,171,172,173],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":178,"sourceHtmlUrl":179,"categories":180,"keywords":183,"publishedAt":124},"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",[181,182],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},[184,39,185,171,186,119,187,188,33,166,189,110,190,191,192,143,193,172,194],"vue testing best practices","testing best practices","best practices","test","testing patterns","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":199,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":124},"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",[202],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},[204,171,205,186,206,33,207,166,193,208,209],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":214,"sourceHtmlUrl":215,"categories":216,"keywords":218,"publishedAt":124},"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",[217],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},[219,171,186,220,163,221,222,223,204,224,225,226,227,228,229,110,230,143,231,232],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]