{"owner":"cypress-io","repo":"cypress-documentation","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":5018,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"cypress-documentation":{"command":"npx","args":["-y","@modelcontextprotocol/server-cypress-documentation"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# Repository Guide for AI Agents\n\nCypress Documentation: a **Docusaurus 3** (TypeScript) docs site. Content is in\n`docs/**/*.mdx`. These are the always-apply rules. For examples and the full\ndetail behind each rule, read **[`AGENTS_REFERENCE.md`](./AGENTS_REFERENCE.md)**\n(and the section links below).\n\n## Directory guides\n\nSome directories carry their own `AGENTS.md` (plus a `CLAUDE.md` that imports\nit) for conventions that apply only inside them. Read the one for the directory\nyou're working in:\n\n| Directory              | Covers                                                      |\n| ---------------------- | ----------------------------------------------------------- |\n| `docs/api/`            | the Cypress source behind a page, frontmatter, the skeleton |\n| `docs/partials/`       | when a partial is warranted, naming, registration           |\n| `docs/app/releases/`   | changelog entry format                                      |\n| `src/`                 | component layout, registration, swizzled theme files        |\n| `plugins/`             | the sub-package build and dependency rules                  |\n| `cypress/`             | the generated page list, what the crawl specs are for       |\n| `.github/workflows/`   | pinning actions, what forks copy, required checks           |\n| `scripts/screenshots/` | editing the Puppeteer capture scripts                       |\n\nThree conventions hold for every one of them:\n\n1. **Each opens with a pointer back here.** Tools differ on whether they merge a\n   nested file with its ancestors or read only the nearest one, so a nested file\n   never assumes this file was loaded.\n2. **They are additive, never contradictory.** A nested rule that conflicts with\n   a rule in this file is a sign the rule in this file is wrong. Fix it here.\n3. **Keep them short**, under about 75 lines. They are the rules that apply\n   here, not a second reference manual. Treat 75 as a ceiling rather than a\n   target: most directories need far less, and a guide that splits one\n   convention across two files to hit a number costs the reader more than the\n   lines saved. Detail belongs in `AGENTS_REFERENCE.md`; link its anchor rather\n   than restating it.\n\nFour things walk `docs/` independently, and each skips these two filenames: the\ndocs build (`exclude` in `docusaurus.config.js`), the LLM export (`walkDocs` in\n`plugins/llm`), `npm run lint:frontmatter`, and `npm run preview:og`. Because\nthey match on filename, adding a nested guide to a **new** directory needs no\nconfig change. Prettier still formats them, so `npm run lint:fix` applies as\nusual — check `.prettierignore` when adding a guide outside `docs/`, since a\nguide inside an ignored directory is silently skipped and a negation cannot pull\nit back out.\n\n## Commands\n\n```bash\nnpm i                 # install (runs patch-package via postinstall)\nnpm run start         # local dev server at http://localhost:3000\nnpm run build         # production build into dist/ (also rebuilds plugins)\nnpm run lint:fix      # Prettier autofix on **/*.{md,mdx}\nnpm run typecheck     # tsc\nnpm test              # cypress e2e (needs `npm run serve`, not the dev server)\nnpm run test:plugins  # vitest unit tests for plugins/\nnpm run api:source -- blur   # locate the Cypress source a /api page documents\n```\n\nInstall before you lint. With no `node_modules` present, `npm run lint:fix`\nstill runs, but on whatever Prettier `npx` fetches rather than the pinned one,\nand a different version reformats files the pinned one leaves alone. For\ncontent-only work, `CYPRESS_INSTALL_BINARY=0 npm i` skips a 250 MB download and\nis enough for every command above except `npm test`.\n\n## Verify ladder (cheap → authoritative)\n\n1. `npm run lint:fix` — **required before every commit** (a Husky/lint-staged\n   hook and CI both enforce Prettier on `*.{md,mdx}`).\n2. `npm run build` — the real safety net for content: `onBrokenLinks` and\n   `onBrokenMarkdownLinks` are `throw`, so any bad link or anchor fails the build.\n3. `npm run typecheck` — when you touched TypeScript in `src/` or `cypress/`, or\n   a script in `scripts/screenshots/`.\n4. `npm run test:plugins` — only when you touched `plugins/`.\n5. `npm test` — for nav/routing or broad changes. Serve a production build\n   first (`npm run build`, then `npm run serve`), which is what CI does. The dev\n   server injects page titles during hydration, so the specs that assert on\n   server-rendered HTML fail against it.\n\nCI runs all of these, so a miss fails the PR rather than `main`. None of them\nexecutes the code inside a code block, so an added or rewritten example also\nneeds [running it yourself](./AGENTS_REFERENCE.md#verifying-code-examples).\n\n## Pull requests\n\nWhen opening a PR, fill out **[`.github/pull_request_template.md`](./.github/pull_request_template.md)**\n(GitHub loads it into the PR body automatically). It is the historical record of\nthe change: complete every section, explaining _why_ the change was made, not\njust _what_ changed.\n\nFor a **release PR** (opened from a `releases/*` branch to document a specific\nproduct release), use the release template instead:\n**[`.github/PULL_REQUEST_TEMPLATE/release.md`](./.github/PULL_REQUEST_TEMPLATE/release.md)**.\nSelect it by appending `?template=release.md` to the compare URL. Name the\ntarget release, list every included change, and make sure a new changelog entry\nis one of them.\n\n## Rules\n\nEach rule is a hard convention. See the linked section for the how and why.\n\n**Pages** — [details](./AGENTS_REFERENCE.md#adding-moving--removing-pages)\n\n- A page is an `.mdx` file under `docs/<section>/`; sidebars are autogenerated, so\n  never hand-edit `sidebars.js` to add one.\n- Include the standard frontmatter (`title`, `description`, `sidebar_label`,\n  `slug`). `title` and `description` are the page's `<title>` and meta\n  description, so make them **SEO-friendly**: lead with the key term and\n  summarize the page accurately. Match the section's house style and mirror a\n  sibling file when unsure. Never append `| Cypress Documentation` to a `title`:\n  a per-section suffix is appended at build time from `src/sectionTitles.js`,\n  and `cypress/e2e/page_titles.cy.ts` asserts it. Never add a `keywords` field to\n  frontmatter —\n  Docusaurus only emits it as a `<meta name=\"keywords\">` tag that modern search\n  engines ignore and that the site's own search doesn't index, so it adds noise\n  with no benefit.\n- Order with `sidebar_position` and `_category_.json`, not `sidebars.js`. Without\n  a `sidebar_position`, pages sort alphabetically; if sibling files don't define\n  one, match them and skip it rather than introducing positions.\n- Moving/renaming/deleting a page **requires** a `301` in both `netlify.toml`\n  and `static/_redirects` (Netlify serves production while Cloudflare builds\n  previews), plus updating in-repo links to it.\n\n**Authoring** — [components](./AGENTS_REFERENCE.md#mdx-components),\n[partials](./AGENTS_REFERENCE.md#partials),\n[naming](./AGENTS_REFERENCE.md#product-heading--naming),\n[code blocks](./AGENTS_REFERENCE.md#code-blocks),\n[AI prompts vs code blocks](./AGENTS_REFERENCE.md#ai-prompts-copyprompt-vs-a-code-block),\n[alt text](./AGENTS_REFERENCE.md#accessible-image-alt-text),\n[diagram contrast](./AGENTS_REFERENCE.md#diagram-color-contrast),\n[screenshots](./scripts/screenshots/README.md)\n\n- Use the MDX components, not raw HTML: `<DocsImage>` / `<DocsVideo>` / `<Icon>`.\n  Always give images meaningful `alt` (describe purpose, not \"screenshot of…\").\n- Capture Cypress App screenshots from a real run of the page's own snippet, never\n  a mock-up: follow the [capture procedure](./scripts/screenshots/README.md).\n- Check every diagram you add or change against WCAG 2.2 AA color contrast before\n  committing it: 4.5:1 for text and 3:1 for lines and shapes the reader needs.\n  Measure each color pair against what it sits on, and report the ratios.\n- Start every product page with `<ProductHeading product=\"…\" />`. Use canonical\n  names: Cypress App, Cypress Cloud, Cypress Accessibility, UI Coverage.\n- Reuse `docs/partials/_*.mdx` instead of repeating content, but only create a\n  partial for content rendered in **more than one location**. If it's used in a\n  single page, inline it there instead.\n- End related pages with a `## See also` section (sentence-case H2, as the page's\n  last section): a short bulleted list of doc-to-doc links to closely related\n  pages, command names in backticks, with an optional `- short description` after\n  a link. It's standard on API reference pages; add it to guides and other pages\n  only when there are genuinely related pages worth surfacing. Don't pad it with\n  tangential links or repeat links already prominent in the page body.\n- Tag every code block with a language; add `title=\"file.ext\"` for file snippets.\n  When an example pairs test code with the app code it runs against (markup,\n  source, a fixture), title every block in the pair with its filename, such as\n  `index.html` and `spec.cy.js`, so the reader tells them apart at a glance.\n- For a copyable, reusable AI prompt (or an agent skill/rule), use `<CopyPrompt>`,\n  not a code block; keep example-specific prompts, code, commands, and diagrams in\n  code blocks. Prompts are expanded by default; add `defaultCollapsed` past 350\n  characters, and never wrap the prompt in quotes. Write `subtext` as the outcome\n  the reader gets, not a restatement that the card copies a prompt for an AI\n  assistant.\n\n**Code examples** — [details](./AGENTS_REFERENCE.md#verifying-code-examples)\n\n- Run every code example you add or rewrite before committing it: typecheck and\n  run it in the throwaway `.example-check/` harness, pasted in verbatim, with an\n  assertion for each claim the prose makes. `npm run build` never executes the\n  code inside a block, so this is the only check it gets.\n- Report every result in the thread, passes included. For each failure, give the\n  error as Cypress printed it, the cause, and a fix with a worked code example\n  you ran and watched pass. Never commit an example that failed.\n- An example you can't run locally (a record key, a Cloud or third-party\n  service) gets reported as not run, with the reason. Being short is not a\n  reason.\n- In Claude Code, the first `git commit` after examples change stops once with\n  a reminder listing them. Run them and report (or say in your report why one\n  doesn't need a run), then commit again. The judgment is yours.\n\n**API reference** — [details](./AGENTS_REFERENCE.md#api-source-of-truth)\n\n- The behavior an `/api` page describes is implemented in `cypress-io/cypress`,\n  not here. Before writing or changing a behavior claim, read that source:\n  `npm run api:source -- <command>` syncs a pinned, sparse checkout of it into\n  `.cypress-source/` and resolves the command to its implementation, published\n  types, error messages, and driver specs.\n- Where the source contradicts the page, flag the conflict rather than rewriting\n  the page to match. The fix may belong in `cypress-io/cypress`.\n\n**Writing style** — [details](./AGENTS_REFERENCE.md#writing-style)\n\n- **Lead a guide with the value of the feature**, what it does for the reader,\n  before getting into configuration or steps. How you do that is up to the page.\n- **Write headings that stand on their own**, since search engines and answer\n  engines surface them without the page around them. \"Cypress Cloud MCP\n  workflows to try\", not \"Workflows to try\". Add the context that makes the\n  heading this page's, keep it to roughly 40 to 60 characters, and use sentence\n  case. The fixed API page skeleton and `## See also` are exempt.\n- Address the reader as **you**. Reserve \"we\" for Cypress speaking as a team\n  (\"we recommend\"), never as a stand-in for the reader.\n- **Present tense, active voice.** \"Cypress retries the assertion\", not \"Cypress\n  will retry the assertion\" or \"the assertion is retried\".\n- **Keep body text current.** Describe how the product works today, without\n  naming the Cypress release that added or changed it (\"supports Escape\", not\n  \"supports Escape in Cypress 15.3.0 and later\"). Version history goes in the\n  page's `## History` table and the changelog. Deprecation, removal, and\n  migration notes are the exception, since the reader needs the version to\n  upgrade.\n- **Say what something does**, not what it lets the reader do. \"`cy.session()`\n  caches and restores session state\", not \"allows you to cache…\".\n- Plain words over formal ones: not `leverage`, `utilize`, or `in order to`.\n- Cut filler. `please`, `note that`, and hedges that carry no information.\n- Don't use minimizing words like \"simply\", \"just\", \"easy\", or \"obviously\" in\n  instructions. They undermine a reader who is struggling and add nothing; state\n  the step plainly instead. Don't tell the reader a feature is easy or fast,\n  either. Show it with a short example and let them draw the conclusion. The\n  rule is the minimizing sense, not the letters: \"not just\", \"just as\", and\n  `just-in-time` are other words doing other work.\n- Go easy on em dashes. Overused, they read as AI-generated, so prefer a comma,\n  period, colon, or parentheses and rework the sentence rather than reaching for\n  a dash. Keep one where it is clearly the best fit, rarely more than one per\n  paragraph.\n- **Link text names its destination.** Never `[here]`, `[this link]`, or\n  `[learn more]`.\n- Oxford comma. US English, except that every `cancel` form doubles the `l`:\n  **cancellation**, **cancelled**, **cancelling**. Leave a single `l` only where\n  it is a literal you are quoting, such as an API value or UI string.\n- Write \"accessibility\", not \"a11y\", in prose. Keep `a11y` where it is part of an\n  actual name, such as the `data-a11y-ignore` attribute, the `checkA11y()`\n  command, or an identifier like a `groupId` or an image filename.\n- Bullets take no terminal punctuation when they are fragments and a period when\n  they are full sentences. Don't mix the two within one list.\n- Use **bold** only for real UI controls the reader acts on in a walkthrough\n  (actual buttons, links, tabs, and flows in Cypress Cloud or the Cypress App,\n  e.g. the **App Quality** tab). Put hypothetical UI labels from illustrative\n  examples in `\"quotes\"` instead (e.g. an `\"Add to cart\"` button in a sample),\n  so invented examples stay distinct from the real UI a tutorial navigates.\n- Describe configuration by what it does and accepts. Don't call out fields or\n  features a property lacks (e.g. \"there is no `comment` field\") unless the\n  absence is a documented point of confusion.\n- Frame behavior explanations positively and reader-first. Avoid phrasings that\n  sound like caveats about the product's design, such as \"consequences of this\n  design\"; prefer neutral lead-ins like \"Keep these behaviors in mind\".\n\n**Directives & tabs** — [tabs](./AGENTS_REFERENCE.md#tabs),\n[config](./AGENTS_REFERENCE.md#cypress-config-examples),\n[e2e/ct](./AGENTS_REFERENCE.md#e2e-vs-component-examples)\n\n- Cypress config snippets → `:::cypress-config-example` (or\n  `:::cypress-config-plugin-example`). Never hand-write `defineConfig` + tabs.\n- TS/JS examples → one `ts` block tagged `copyTsToJs`; never maintain a JS copy.\n- E2E-vs-component snippets → `:::visit-mount-example`.\n- Package-manager commands → `<PackageManagerTabs>` (with `install`, `run`, or\n  `exec`) or `<CypressCommandTabs>` for `cypress` subcommands. Never hand-write\n  npm/Yarn/pnpm/Bun tab sets.\n- Tabs sync via a shared `groupId`. Fixed orders: package managers\n  **npm → Yarn → pnpm → Bun**; frameworks **React → Angular → Vue → Svelte**; JS\n  before TS.\n\n**Admonitions** — [details](./AGENTS_REFERENCE.md#admonition-blocks)\n\n- `:::info` (default), `:::tip`, `:::note`, `:::caution` (prefer over\n  `:::warning`), `:::danger`. Keep them short and infrequent.\n\n**Linking** — [details](./AGENTS_REFERENCE.md#linking)\n\n- Doc-to-doc: absolute site path, no `.mdx` extension (`/api/commands/origin`).\n- Heading anchors **preserve case** and hyphenate spaces\n  (`## Disabling Web Security` → `#Disabling-Web-Security`); avoid custom\n  `{#id}` anchors.\n- Links to `www.cypress.io` / `on.cypress.io` / `learn.cypress.io` need UTM\n  params (`utm_source=docs.cypress.io` + a placement `utm_medium`). Do not add\n  them to internal links or `cloud.cypress.io`.\n\n**GitHub Actions workflows** — [details](./.github/workflows/AGENTS.md)\n\n- Read that guide before adding or editing a workflow. Every file in\n  `.github/workflows/` is copied into each fork and runs there with reduced\n  permissions, so an unguarded job that pushes commits, opens pull requests, or\n  reads secrets fails in somebody else's repository.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# Repository Guide for AI Agents\n\nCypress Documentation: a **Docusaurus 3** (TypeScript) docs site. Content is in\n`docs/**/*.mdx`. These are the always-apply rules. For examples and the full\ndetail behind each rule, read **[`AGENTS_REFERENCE.md`](./AGENTS_REFERENCE.md)**\n(and the section links below).\n\n## Directory guides\n\nSome directories carry their own `AGENTS.md` (plus a `CLAUDE.md` that imports\nit) for conventions that apply only inside them. Read the one for the directory\nyou're working in:\n\n| Directory              | Covers                                                      |\n| ---------------------- | ----------------------------------------------------------- |\n| `docs/api/`            | the Cypress source behind a page, frontmatter, the skeleton |\n| `docs/partials/`       | when a partial is warranted, naming, registration           |\n| `docs/app/releases/`   | changelog entry format                                      |\n| `src/`                 | component layout, registration, swizzled theme files        |\n| `plugins/`             | the sub-package build and dependency rules                  |\n| `cypress/`             | the generated page list, what the crawl specs are for       |\n| `.github/workflows/`   | pinning actions, what forks copy, required checks           |\n| `scripts/screenshots/` | editing the Puppeteer capture scripts                       |\n\nThree conventions hold for every one of them:\n\n1. **Each opens with a pointer back here.** Tools differ on whether they merge a\n   nested file with its ancestors or read only the nearest one, so a nested file\n   never assumes this file was loaded.\n2. **They are additive, never contradictory.** A nested rule that conflicts with\n   a rule in this file is a sign the rule in this file is wrong. Fix it here.\n3. **Keep them short**, under about 75 lines. They are the rules that apply\n   here, not a second reference manual. Treat 75 as a ceiling rather than a\n   target: most directories need far less, and a guide that splits one\n   convention across two files to hit a number costs the reader more than the\n   lines saved. Detail belongs in `AGENTS_REFERENCE.md`; link its anchor rather\n   than restating it.\n\nFour things walk `docs/` independently, and each skips these two filenames: the\ndocs build (`exclude` in `docusaurus.config.js`), the LLM export (`walkDocs` in\n`plugins/llm`), `npm run lint:frontmatter`, and `npm run preview:og`. Because\nthey match on filename, adding a nested guide to a **new** directory needs no\nconfig change. Prettier still formats them, so `npm run lint:fix` applies as\nusual — check `.prettierignore` when adding a guide outside `docs/`, since a\nguide inside an ignored directory is silently skipped and a negation cannot pull\nit back out.\n\n## Commands\n\n```bash\nnpm i                 # install (runs patch-package via postinstall)\nnpm run start         # local dev server at http://localhost:3000\nnpm run build         # production build into dist/ (also rebuilds plugins)\nnpm run lint:fix      # Prettier autofix on **/*.{md,mdx}\nnpm run typecheck     # tsc\nnpm test              # cypress e2e (needs `npm run serve`, not the dev server)\nnpm run test:plugins  # vitest unit tests for plugins/\nnpm run api:source -- blur   # locate the Cypress source a /api page documents\n```\n\nInstall before you lint. With no `node_modules` present, `npm run lint:fix`\nstill runs, but on whatever Prettier `npx` fetches rather than the pinned one,\nand a different version reformats files the pinned one leaves alone. For\ncontent-only work, `CYPRESS_INSTALL_BINARY=0 npm i` skips a 250 MB download and\nis enough for every command above except `npm test`.\n\n## Verify ladder (cheap → authoritative)\n\n1. `npm run lint:fix` — **required before every commit** (a Husky/lint-staged\n   hook and CI both enforce Prettier on `*.{md,mdx}`).\n2. `npm run build` — the real safety net for content: `onBrokenLinks` and\n   `onBrokenMarkdownLinks` are `throw`, so any bad link or anchor fails the build.\n3. `npm run typecheck` — when you touched TypeScript in `src/` or `cypress/`, or\n   a script in `scripts/screenshots/`.\n4. `npm run test:plugins` — only when you touched `plugins/`.\n5. `npm test` — for nav/routing or broad changes. Serve a production build\n   first (`npm run build`, then `npm run serve`), which is what CI does. The dev\n   server injects page titles during hydration, so the specs that assert on\n   server-rendered HTML fail against it.\n\nCI runs all of these, so a miss fails the PR rather than `main`. None of them\nexecutes the code inside a code block, so an added or rewritten example also\nneeds [running it yourself](./AGENTS_REFERENCE.md#verifying-code-examples).\n\n## Pull requests\n\nWhen opening a PR, fill out **[`.github/pull_request_template.md`](./.github/pull_request_template.md)**\n(GitHub loads it into the PR body automatically). It is the historical record of\nthe change: complete every section, explaining _why_ the change was made, not\njust _what_ changed.\n\nFor a **release PR** (opened from a `releases/*` branch to document a specific\nproduct release), use the release template instead:\n**[`.github/PULL_REQUEST_TEMPLATE/release.md`](./.github/PULL_REQUEST_TEMPLATE/release.md)**.\nSelect it by appending `?template=release.md` to the compare URL. Name the\ntarget release, list every included change, and make sure a new changelog entry\nis one of them.\n\n## Rules\n\nEach rule is a hard convention. See the linked section for the how and why.\n\n**Pages** — [details](./AGENTS_REFERENCE.md#adding-moving--removing-pages)\n\n- A page is an `.mdx` file under `docs/<section>/`; sidebars are autogenerated, so\n  never hand-edit `sidebars.js` to add one.\n- Include the standard frontmatter (`title`, `description`, `sidebar_label`,\n  `slug`). `title` and `description` are the page's `<title>` and meta\n  description, so make them **SEO-friendly**: lead with the key term and\n  summarize the page accurately. Match the section's house style and mirror a\n  sibling file when unsure. Never append `| Cypress Documentation` to a `title`:\n  a per-section suffix is appended at build time from `src/sectionTitles.js`,\n  and `cypress/e2e/page_titles.cy.ts` asserts it. Never add a `keywords` field to\n  frontmatter —\n  Docusaurus only emits it as a `<meta name=\"keywords\">` tag that modern search\n  engines ignore and that the site's own search doesn't index, so it adds noise\n  with no benefit.\n- Order with `sidebar_position` and `_category_.json`, not `sidebars.js`. Without\n  a `sidebar_position`, pages sort alphabetically; if sibling files don't define\n  one, match them and skip it rather than introducing positions.\n- Moving/renaming/deleting a page **requires** a `301` in both `netlify.toml`\n  and `static/_redirects` (Netlify serves production while Cloudflare builds\n  previews), plus updating in-repo links to it.\n\n**Authoring** — [components](./AGENTS_REFERENCE.md#mdx-components),\n[partials](./AGENTS_REFERENCE.md#partials),\n[naming](./AGENTS_REFERENCE.md#product-heading--naming),\n[code blocks](./AGENTS_REFERENCE.md#code-blocks),\n[AI prompts vs code blocks](./AGENTS_REFERENCE.md#ai-prompts-copyprompt-vs-a-code-block),\n[alt text](./AGENTS_REFERENCE.md#accessible-image-alt-text),\n[diagram contrast](./AGENTS_REFERENCE.md#diagram-color-contrast),\n[screenshots](./scripts/screenshots/README.md)\n\n- Use the MDX components, not raw HTML: `<DocsImage>` / `<DocsVideo>` / `<Icon>`.\n  Always give images meaningful `alt` (describe purpose, not \"screenshot of…\").\n- Capture Cypress App screenshots from a real run of the page's own snippet, never\n  a mock-up: follow the [capture procedure](./scripts/screenshots/README.md).\n- Check every diagram you add or change against WCAG 2.2 AA color contrast before\n  committing it: 4.5:1 for text and 3:1 for lines and shapes the reader needs.\n  Measure each color pair against what it sits on, and report the ratios.\n- Start every product page with `<ProductHeading product=\"…\" />`. Use canonical\n  names: Cypress App, Cypress Cloud, Cypress Accessibility, UI Coverage.\n- Reuse `docs/partials/_*.mdx` instead of repeating content, but only create a\n  partial for content rendered in **more than one location**. If it's used in a\n  single page, inline it there instead.\n- End related pages with a `## See also` section (sentence-case H2, as the page's\n  last section): a short bulleted list of doc-to-doc links to closely related\n  pages, command names in backticks, with an optional `- short description` after\n  a link. It's standard on API reference pages; add it to guides and other pages\n  only when there are genuinely related pages worth surfacing. Don't pad it with\n  tangential links or repeat links already prominent in the page body.\n- Tag every code block with a language; add `title=\"file.ext\"` for file snippets.\n  When an example pairs test code with the app code it runs against (markup,\n  source, a fixture), title every block in the pair with its filename, such as\n  `index.html` and `spec.cy.js`, so the reader tells them apart at a glance.\n- For a copyable, reusable AI prompt (or an agent skill/rule), use `<CopyPrompt>`,\n  not a code block; keep example-specific prompts, code, commands, and diagrams in\n  code blocks. Prompts are expanded by default; add `defaultCollapsed` past 350\n  characters, and never wrap the prompt in quotes. Write `subtext` as the outcome\n  the reader gets, not a restatement that the card copies a prompt for an AI\n  assistant.\n\n**Code examples** — [details](./AGENTS_REFERENCE.md#verifying-code-examples)\n\n- Run every code example you add or rewrite before committing it: typecheck and\n  run it in the throwaway `.example-check/` harness, pasted in verbatim, with an\n  assertion for each claim the prose makes. `npm run build` never executes the\n  code inside a block, so this is the only check it gets.\n- Report every result in the thread, passes included. For each failure, give the\n  error as Cypress printed it, the cause, and a fix with a worked code example\n  you ran and watched pass. Never commit an example that failed.\n- An example you can't run locally (a record key, a Cloud or third-party\n  service) gets reported as not run, with the reason. Being short is not a\n  reason.\n- In Claude Code, the first `git commit` after examples change stops once with\n  a reminder listing them. Run them and report (or say in your report why one\n  doesn't need a run), then commit again. The judgment is yours.\n\n**API reference** — [details](./AGENTS_REFERENCE.md#api-source-of-truth)\n\n- The behavior an `/api` page describes is implemented in `cypress-io/cypress`,\n  not here. Before writing or changing a behavior claim, read that source:\n  `npm run api:source -- <command>` syncs a pinned, sparse checkout of it into\n  `.cypress-source/` and resolves the command to its implementation, published\n  types, error messages, and driver specs.\n- Where the source contradicts the page, flag the conflict rather than rewriting\n  the page to match. The fix may belong in `cypress-io/cypress`.\n\n**Writing style** — [details](./AGENTS_REFERENCE.md#writing-style)\n\n- **Lead a guide with the value of the feature**, what it does for the reader,\n  before getting into configuration or steps. How you do that is up to the page.\n- **Write headings that stand on their own**, since search engines and answer\n  engines surface them without the page around them. \"Cypress Cloud MCP\n  workflows to try\", not \"Workflows to try\". Add the context that makes the\n  heading this page's, keep it to roughly 40 to 60 characters, and use sentence\n  case. The fixed API page skeleton and `## See also` are exempt.\n- Address the reader as **you**. Reserve \"we\" for Cypress speaking as a team\n  (\"we recommend\"), never as a stand-in for the reader.\n- **Present tense, active voice.** \"Cypress retries the assertion\", not \"Cypress\n  will retry the assertion\" or \"the assertion is retried\".\n- **Keep body text current.** Describe how the product works today, without\n  naming the Cypress release that added or changed it (\"supports Escape\", not\n  \"supports Escape in Cypress 15.3.0 and later\"). Version history goes in the\n  page's `## History` table and the changelog. Deprecation, removal, and\n  migration notes are the exception, since the reader needs the version to\n  upgrade.\n- **Say what something does**, not what it lets the reader do. \"`cy.session()`\n  caches and restores session state\", not \"allows you to cache…\".\n- Plain words over formal ones: not `leverage`, `utilize`, or `in order to`.\n- Cut filler. `please`, `note that`, and hedges that carry no information.\n- Don't use minimizing words like \"simply\", \"just\", \"easy\", or \"obviously\" in\n  instructions. They undermine a reader who is struggling and add nothing; state\n  the step plainly instead. Don't tell the reader a feature is easy or fast,\n  either. Show it with a short example and let them draw the conclusion. The\n  rule is the minimizing sense, not the letters: \"not just\", \"just as\", and\n  `just-in-time` are other words doing other work.\n- Go easy on em dashes. Overused, they read as AI-generated, so prefer a comma,\n  period, colon, or parentheses and rework the sentence rather than reaching for\n  a dash. Keep one where it is clearly the best fit, rarely more than one per\n  paragraph.\n- **Link text names its destination.** Never `[here]`, `[this link]`, or\n  `[learn more]`.\n- Oxford comma. US English, except that every `cancel` form doubles the `l`:\n  **cancellation**, **cancelled**, **cancelling**. Leave a single `l` only where\n  it is a literal you are quoting, such as an API value or UI string.\n- Write \"accessibility\", not \"a11y\", in prose. Keep `a11y` where it is part of an\n  actual name, such as the `data-a11y-ignore` attribute, the `checkA11y()`\n  command, or an identifier like a `groupId` or an image filename.\n- Bullets take no terminal punctuation when they are fragments and a period when\n  they are full sentences. Don't mix the two within one list.\n- Use **bold** only for real UI controls the reader acts on in a walkthrough\n  (actual buttons, links, tabs, and flows in Cypress Cloud or the Cypress App,\n  e.g. the **App Quality** tab). Put hypothetical UI labels from illustrative\n  examples in `\"quotes\"` instead (e.g. an `\"Add to cart\"` button in a sample),\n  so invented examples stay distinct from the real UI a tutorial navigates.\n- Describe configuration by what it does and accepts. Don't call out fields or\n  features a property lacks (e.g. \"there is no `comment` field\") unless the\n  absence is a documented point of confusion.\n- Frame behavior explanations positively and reader-first. Avoid phrasings that\n  sound like caveats about the product's design, such as \"consequences of this\n  design\"; prefer neutral lead-ins like \"Keep these behaviors in mind\".\n\n**Directives & tabs** — [tabs](./AGENTS_REFERENCE.md#tabs),\n[config](./AGENTS_REFERENCE.md#cypress-config-examples),\n[e2e/ct](./AGENTS_REFERENCE.md#e2e-vs-component-examples)\n\n- Cypress config snippets → `:::cypress-config-example` (or\n  `:::cypress-config-plugin-example`). Never hand-write `defineConfig` + tabs.\n- TS/JS examples → one `ts` block tagged `copyTsToJs`; never maintain a JS copy.\n- E2E-vs-component snippets → `:::visit-mount-example`.\n- Package-manager commands → `<PackageManagerTabs>` (with `install`, `run`, or\n  `exec`) or `<CypressCommandTabs>` for `cypress` subcommands. Never hand-write\n  npm/Yarn/pnpm/Bun tab sets.\n- Tabs sync via a shared `groupId`. Fixed orders: package managers\n  **npm → Yarn → pnpm → Bun**; frameworks **React → Angular → Vue → Svelte**; JS\n  before TS.\n\n**Admonitions** — [details](./AGENTS_REFERENCE.md#admonition-blocks)\n\n- `:::info` (default), `:::tip`, `:::note`, `:::caution` (prefer over\n  `:::warning`), `:::danger`. Keep them short and infrequent.\n\n**Linking** — [details](./AGENTS_REFERENCE.md#linking)\n\n- Doc-to-doc: absolute site path, no `.mdx` extension (`/api/commands/origin`).\n- Heading anchors **preserve case** and hyphenate spaces\n  (`## Disabling Web Security` → `#Disabling-Web-Security`); avoid custom\n  `{#id}` anchors.\n- Links to `www.cypress.io` / `on.cypress.io` / `learn.cypress.io` need UTM\n  params (`utm_source=docs.cypress.io` + a placement `utm_medium`). Do not add\n  them to internal links or `cloud.cypress.io`.\n\n**GitHub Actions workflows** — [details](./.github/workflows/AGENTS.md)\n\n- Read that guide before adding or editing a workflow. Every file in\n  `.github/workflows/` is copied into each fork and runs there with reduced\n  permissions, so an unguarded job that pushes commits, opens pull requests, or\n  reads secrets fails in somebody else's repository.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Repository Guide for AI Agents\n\nCypress Documentation: a **Docusaurus 3** (TypeScript) docs site. Content is in\n`docs/**/*.mdx`. These are the always-apply rules. For examples and the full\ndetail behind each rule, read **[`AGENTS_REFERENCE.md`](./AGENTS_REFERENCE.md)**\n(and the section links below).\n\n## Directory guides\n\nSome directories carry their own `AGENTS.md` (plus a `CLAUDE.md` that imports\nit) for conventions that apply only inside them. Read the one for the directory\nyou're working in:\n\n| Directory              | Covers                                                      |\n| ---------------------- | ----------------------------------------------------------- |\n| `docs/api/`            | the Cypress source behind a page, frontmatter, the skeleton |\n| `docs/partials/`       | when a partial is warranted, naming, registration           |\n| `docs/app/releases/`   | changelog entry format                                      |\n| `src/`                 | component layout, registration, swizzled theme files        |\n| `plugins/`             | the sub-package build and dependency rules                  |\n| `cypress/`             | the generated page list, what the crawl specs are for       |\n| `.github/workflows/`   | pinning actions, what forks copy, required checks           |\n| `scripts/screenshots/` | editing the Puppeteer capture scripts                       |\n\nThree conventions hold for every one of them:\n\n1. **Each opens with a pointer back here.** Tools differ on whether they merge a\n   nested file with its ancestors or read only the nearest one, so a nested file\n   never assumes this file was loaded.\n2. **They are additive, never contradictory.** A nested rule that conflicts with\n   a rule in this file is a sign the rule in this file is wrong. Fix it here.\n3. **Keep them short**, under about 75 lines. They are the rules that apply\n   here, not a second reference manual. Treat 75 as a ceiling rather than a\n   target: most directories need far less, and a guide that splits one\n   convention across two files to hit a number costs the reader more than the\n   lines saved. Detail belongs in `AGENTS_REFERENCE.md`; link its anchor rather\n   than restating it.\n\nFour things walk `docs/` independently, and each skips these two filenames: the\ndocs build (`exclude` in `docusaurus.config.js`), the LLM export (`walkDocs` in\n`plugins/llm`), `npm run lint:frontmatter`, and `npm run preview:og`. Because\nthey match on filename, adding a nested guide to a **new** directory needs no\nconfig change. Prettier still formats them, so `npm run lint:fix` applies as\nusual — check `.prettierignore` when adding a guide outside `docs/`, since a\nguide inside an ignored directory is silently skipped and a negation cannot pull\nit back out.\n\n## Commands\n\n```bash\nnpm i                 # install (runs patch-package via postinstall)\nnpm run start         # local dev server at http://localhost:3000\nnpm run build         # production build into dist/ (also rebuilds plugins)\nnpm run lint:fix      # Prettier autofix on **/*.{md,mdx}\nnpm run typecheck     # tsc\nnpm test              # cypress e2e (needs `npm run serve`, not the dev server)\nnpm run test:plugins  # vitest unit tests for plugins/\nnpm run api:source -- blur   # locate the Cypress source a /api page documents\n```\n\nInstall before you lint. With no `node_modules` present, `npm run lint:fix`\nstill runs, but on whatever Prettier `npx` fetches rather than the pinned one,\nand a different version reformats files the pinned one leaves alone. For\ncontent-only work, `CYPRESS_INSTALL_BINARY=0 npm i` skips a 250 MB download and\nis enough for every command above except `npm test`.\n\n## Verify ladder (cheap → authoritative)\n\n1. `npm run lint:fix` — **required before every commit** (a Husky/lint-staged\n   hook and CI both enforce Prettier on `*.{md,mdx}`).\n2. `npm run build` — the real safety net for content: `onBrokenLinks` and\n   `onBrokenMarkdownLinks` are `throw`, so any bad link or anchor fails the build.\n3. `npm run typecheck` — when you touched TypeScript in `src/` or `cypress/`, or\n   a script in `scripts/screenshots/`.\n4. `npm run test:plugins` — only when you touched `plugins/`.\n5. `npm test` — for nav/routing or broad changes. Serve a production build\n   first (`npm run build`, then `npm run serve`), which is what CI does. The dev\n   server injects page titles during hydration, so the specs that assert on\n   server-rendered HTML fail against it.\n\nCI runs all of these, so a miss fails the PR rather than `main`. None of them\nexecutes the code inside a code block, so an added or rewritten example also\nneeds [running it yourself](./AGENTS_REFERENCE.md#verifying-code-examples).\n\n## Pull requests\n\nWhen opening a PR, fill out **[`.github/pull_request_template.md`](./.github/pull_request_template.md)**\n(GitHub loads it into the PR body automatically). It is the historical record of\nthe change: complete every section, explaining _why_ the change was made, not\njust _what_ changed.\n\nFor a **release PR** (opened from a `releases/*` branch to document a specific\nproduct release), use the release template instead:\n**[`.github/PULL_REQUEST_TEMPLATE/release.md`](./.github/PULL_REQUEST_TEMPLATE/release.md)**.\nSelect it by appending `?template=release.md` to the compare URL. Name the\ntarget release, list every included change, and make sure a new changelog entry\nis one of them.\n\n## Rules\n\nEach rule is a hard convention. See the linked section for the how and why.\n\n**Pages** — [details](./AGENTS_REFERENCE.md#adding-moving--removing-pages)\n\n- A page is an `.mdx` file under `docs/<section>/`; sidebars are autogenerated, so\n  never hand-edit `sidebars.js` to add one.\n- Include the standard frontmatter (`title`, `description`, `sidebar_label`,\n  `slug`). `title` and `description` are the page's `<title>` and meta\n  description, so make them **SEO-friendly**: lead with the key term and\n  summarize the page accurately. Match the section's house style and mirror a\n  sibling file when unsure. Never append `| Cypress Documentation` to a `title`:\n  a per-section suffix is appended at build time from `src/sectionTitles.js`,\n  and `cypress/e2e/page_titles.cy.ts` asserts it. Never add a `keywords` field to\n  frontmatter —\n  Docusaurus only emits it as a `<meta name=\"keywords\">` tag that modern search\n  engines ignore and that the site's own search doesn't index, so it adds noise\n  with no benefit.\n- Order with `sidebar_position` and `_category_.json`, not `sidebars.js`. Without\n  a `sidebar_position`, pages sort alphabetically; if sibling files don't define\n  one, match them and skip it rather than introducing positions.\n- Moving/renaming/deleting a page **requires** a `301` in both `netlify.toml`\n  and `static/_redirects` (Netlify serves production while Cloudflare builds\n  previews), plus updating in-repo links to it.\n\n**Authoring** — [components](./AGENTS_REFERENCE.md#mdx-components),\n[partials](./AGENTS_REFERENCE.md#partials),\n[naming](./AGENTS_REFERENCE.md#product-heading--naming),\n[code blocks](./AGENTS_REFERENCE.md#code-blocks),\n[AI prompts vs code blocks](./AGENTS_REFERENCE.md#ai-prompts-copyprompt-vs-a-code-block),\n[alt text](./AGENTS_REFERENCE.md#accessible-image-alt-text),\n[diagram contrast](./AGENTS_REFERENCE.md#diagram-color-contrast),\n[screenshots](./scripts/screenshots/README.md)\n\n- Use the MDX components, not raw HTML: `<DocsImage>` / `<DocsVideo>` / `<Icon>`.\n  Always give images meaningful `alt` (describe purpose, not \"screenshot of…\").\n- Capture Cypress App screenshots from a real run of the page's own snippet, never\n  a mock-up: follow the [capture procedure](./scripts/screenshots/README.md).\n- Check every diagram you add or change against WCAG 2.2 AA color contrast before\n  committing it: 4.5:1 for text and 3:1 for lines and shapes the reader needs.\n  Measure each color pair against what it sits on, and report the ratios.\n- Start every product page with `<ProductHeading product=\"…\" />`. Use canonical\n  names: Cypress App, Cypress Cloud, Cypress Accessibility, UI Coverage.\n- Reuse `docs/partials/_*.mdx` instead of repeating content, but only create a\n  partial for content rendered in **more than one location**. If it's used in a\n  single page, inline it there instead.\n- End related pages with a `## See also` section (sentence-case H2, as the page's\n  last section): a short bulleted list of doc-to-doc links to closely related\n  pages, command names in backticks, with an optional `- short description` after\n  a link. It's standard on API reference pages; add it to guides and other pages\n  only when there are genuinely related pages worth surfacing. Don't pad it with\n  tangential links or repeat links already prominent in the page body.\n- Tag every code block with a language; add `title=\"file.ext\"` for file snippets.\n  When an example pairs test code with the app code it runs against (markup,\n  source, a fixture), title every block in the pair with its filename, such as\n  `index.html` and `spec.cy.js`, so the reader tells them apart at a glance.\n- For a copyable, reusable AI prompt (or an agent skill/rule), use `<CopyPrompt>`,\n  not a code block; keep example-specific prompts, code, commands, and diagrams in\n  code blocks. Prompts are expanded by default; add `defaultCollapsed` past 350\n  characters, and never wrap the prompt in quotes. Write `subtext` as the outcome\n  the reader gets, not a restatement that the card copies a prompt for an AI\n  assistant.\n\n**Code examples** — [details](./AGENTS_REFERENCE.md#verifying-code-examples)\n\n- Run every code example you add or rewrite before committing it: typecheck and\n  run it in the throwaway `.example-check/` harness, pasted in verbatim, with an\n  assertion for each claim the prose makes. `npm run build` never executes the\n  code inside a block, so this is the only check it gets.\n- Report every result in the thread, passes included. For each failure, give the\n  error as Cypress printed it, the cause, and a fix with a worked code example\n  you ran and watched pass. Never commit an example that failed.\n- An example you can't run locally (a record key, a Cloud or third-party\n  service) gets reported as not run, with the reason. Being short is not a\n  reason.\n- In Claude Code, the first `git commit` after examples change stops once with\n  a reminder listing them. Run them and report (or say in your report why one\n  doesn't need a run), then commit again. The judgment is yours.\n\n**API reference** — [details](./AGENTS_REFERENCE.md#api-source-of-truth)\n\n- The behavior an `/api` page describes is implemented in `cypress-io/cypress`,\n  not here. Before writing or changing a behavior claim, read that source:\n  `npm run api:source -- <command>` syncs a pinned, sparse checkout of it into\n  `.cypress-source/` and resolves the command to its implementation, published\n  types, error messages, and driver specs.\n- Where the source contradicts the page, flag the conflict rather than rewriting\n  the page to match. The fix may belong in `cypress-io/cypress`.\n\n**Writing style** — [details](./AGENTS_REFERENCE.md#writing-style)\n\n- **Lead a guide with the value of the feature**, what it does for the reader,\n  before getting into configuration or steps. How you do that is up to the page.\n- **Write headings that stand on their own**, since search engines and answer\n  engines surface them without the page around them. \"Cypress Cloud MCP\n  workflows to try\", not \"Workflows to try\". Add the context that makes the\n  heading this page's, keep it to roughly 40 to 60 characters, and use sentence\n  case. The fixed API page skeleton and `## See also` are exempt.\n- Address the reader as **you**. Reserve \"we\" for Cypress speaking as a team\n  (\"we recommend\"), never as a stand-in for the reader.\n- **Present tense, active voice.** \"Cypress retries the assertion\", not \"Cypress\n  will retry the assertion\" or \"the assertion is retried\".\n- **Keep body text current.** Describe how the product works today, without\n  naming the Cypress release that added or changed it (\"supports Escape\", not\n  \"supports Escape in Cypress 15.3.0 and later\"). Version history goes in the\n  page's `## History` table and the changelog. Deprecation, removal, and\n  migration notes are the exception, since the reader needs the version to\n  upgrade.\n- **Say what something does**, not what it lets the reader do. \"`cy.session()`\n  caches and restores session state\", not \"allows you to cache…\".\n- Plain words over formal ones: not `leverage`, `utilize`, or `in order to`.\n- Cut filler. `please`, `note that`, and hedges that carry no information.\n- Don't use minimizing words like \"simply\", \"just\", \"easy\", or \"obviously\" in\n  instructions. They undermine a reader who is struggling and add nothing; state\n  the step plainly instead. Don't tell the reader a feature is easy or fast,\n  either. Show it with a short example and let them draw the conclusion. The\n  rule is the minimizing sense, not the letters: \"not just\", \"just as\", and\n  `just-in-time` are other words doing other work.\n- Go easy on em dashes. Overused, they read as AI-generated, so prefer a comma,\n  period, colon, or parentheses and rework the sentence rather than reaching for\n  a dash. Keep one where it is clearly the best fit, rarely more than one per\n  paragraph.\n- **Link text names its destination.** Never `[here]`, `[this link]`, or\n  `[learn more]`.\n- Oxford comma. US English, except that every `cancel` form doubles the `l`:\n  **cancellation**, **cancelled**, **cancelling**. Leave a single `l` only where\n  it is a literal you are quoting, such as an API value or UI string.\n- Write \"accessibility\", not \"a11y\", in prose. Keep `a11y` where it is part of an\n  actual name, such as the `data-a11y-ignore` attribute, the `checkA11y()`\n  command, or an identifier like a `groupId` or an image filename.\n- Bullets take no terminal punctuation when they are fragments and a period when\n  they are full sentences. Don't mix the two within one list.\n- Use **bold** only for real UI controls the reader acts on in a walkthrough\n  (actual buttons, links, tabs, and flows in Cypress Cloud or the Cypress App,\n  e.g. the **App Quality** tab). Put hypothetical UI labels from illustrative\n  examples in `\"quotes\"` instead (e.g. an `\"Add to cart\"` button in a sample),\n  so invented examples stay distinct from the real UI a tutorial navigates.\n- Describe configuration by what it does and accepts. Don't call out fields or\n  features a property lacks (e.g. \"there is no `comment` field\") unless the\n  absence is a documented point of confusion.\n- Frame behavior explanations positively and reader-first. Avoid phrasings that\n  sound like caveats about the product's design, such as \"consequences of this\n  design\"; prefer neutral lead-ins like \"Keep these behaviors in mind\".\n\n**Directives & tabs** — [tabs](./AGENTS_REFERENCE.md#tabs),\n[config](./AGENTS_REFERENCE.md#cypress-config-examples),\n[e2e/ct](./AGENTS_REFERENCE.md#e2e-vs-component-examples)\n\n- Cypress config snippets → `:::cypress-config-example` (or\n  `:::cypress-config-plugin-example`). Never hand-write `defineConfig` + tabs.\n- TS/JS examples → one `ts` block tagged `copyTsToJs`; never maintain a JS copy.\n- E2E-vs-component snippets → `:::visit-mount-example`.\n- Package-manager commands → `<PackageManagerTabs>` (with `install`, `run`, or\n  `exec`) or `<CypressCommandTabs>` for `cypress` subcommands. Never hand-write\n  npm/Yarn/pnpm/Bun tab sets.\n- Tabs sync via a shared `groupId`. Fixed orders: package managers\n  **npm → Yarn → pnpm → Bun**; frameworks **React → Angular → Vue → Svelte**; JS\n  before TS.\n\n**Admonitions** — [details](./AGENTS_REFERENCE.md#admonition-blocks)\n\n- `:::info` (default), `:::tip`, `:::note`, `:::caution` (prefer over\n  `:::warning`), `:::danger`. Keep them short and infrequent.\n\n**Linking** — [details](./AGENTS_REFERENCE.md#linking)\n\n- Doc-to-doc: absolute site path, no `.mdx` extension (`/api/commands/origin`).\n- Heading anchors **preserve case** and hyphenate spaces\n  (`## Disabling Web Security` → `#Disabling-Web-Security`); avoid custom\n  `{#id}` anchors.\n- Links to `www.cypress.io` / `on.cypress.io` / `learn.cypress.io` need UTM\n  params (`utm_source=docs.cypress.io` + a placement `utm_medium`). Do not add\n  them to internal links or `cloud.cypress.io`.\n\n**GitHub Actions workflows** — [details](./.github/workflows/AGENTS.md)\n\n- Read that guide before adding or editing a workflow. Every file in\n  `.github/workflows/` is copied into each fork and runs there with reduced\n  permissions, so an unguarded job that pushes commits, opens pull requests, or\n  reads secrets fails in somebody else's repository.\n","isInternal":false,"tokens":4118,"sizeBytes":16679},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":211},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":197},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":190}],"systemPromptSnippet":"<yakaai_skills repo=\"cypress-io/cypress-documentation\">\n<!-- File: AGENTS.md (Tokens: ~4118 | Category: root-instruction) -->\n# Repository Guide for AI Agents\n\nCypress Documentation: a **Docusaurus 3** (TypeScript) docs site. Content is in\n`docs/**/*.mdx`. These are the always-apply rules. For examples and the full\ndetail behind each rule, read **[`AGENTS_REFERENCE.md`](./AGENTS_REFERENCE.md)**\n(and the section links below).\n\n## Directory guides\n\nSome directories carry their own `AGENTS.md` (plus a `CLAUDE.md` that imports\nit) for conventions that apply only inside them. Read the one for the directory\nyou're working in:\n\n| Directory              | Covers                                                      |\n| ---------------------- | ----------------------------------------------------------- |\n| `docs/api/`            | the Cypress source behind a page, frontmatter, the skeleton |\n| `docs/partials/`       | when a partial is warranted, naming, registration           |\n| `docs/app/releases/`   | changelog entry format                                      |\n| `src/`                 | component layout, registration, swizzled theme files        |\n| `plugins/`             | the sub-package build and dependency rules                  |\n| `cypress/`             | the generated page list, what the crawl specs are for       |\n| `.github/workflows/`   | pinning actions, what forks copy, required checks           |\n| `scripts/screenshots/` | editing the Puppeteer capture scripts                       |\n\nThree conventions hold for every one of them:\n\n1. **Each opens with a pointer back here.** Tools differ on whether they merge a\n   nested file with its ancestors or read only the nearest one, so a nested file\n   never assumes this file was loaded.\n2. **They are additive, never contradictory.** A nested rule that conflicts with\n   a rule in this file is a sign the rule in this file is wrong. Fix it here.\n3. **Keep them short**, under about 75 lines. They are the rules that apply\n   here, not a second reference manual. Treat 75 as a ceiling rather than a\n   target: most directories need far less, and a guide that splits one\n   convention across two files to hit a number costs the reader more than the\n   lines saved. Detail belongs in `AGENTS_REFERENCE.md`; link its anchor rather\n   than restating it.\n\nFour things walk `docs/` independently, and each skips these two filenames: the\ndocs build (`exclude` in `docusaurus.config.js`), the LLM export (`walkDocs` in\n`plugins/llm`), `npm run lint:frontmatter`, and `npm run preview:og`. Because\nthey match on filename, adding a nested guide to a **new** directory needs no\nconfig change. Prettier still formats them, so `npm run lint:fix` applies as\nusual — check `.prettierignore` when adding a guide outside `docs/`, since a\nguide inside an ignored directory is silently skipped and a negation cannot pull\nit back out.\n\n## Commands\n\n```bash\nnpm i                 # install (runs patch-package via postinstall)\nnpm run start         # local dev server at http://localhost:3000\nnpm run build         # production build into dist/ (also rebuilds plugins)\nnpm run lint:fix      # Prettier autofix on **/*.{md,mdx}\nnpm run typecheck     # tsc\nnpm test              # cypress e2e (needs `npm run serve`, not the dev server)\nnpm run test:plugins  # vitest unit tests for plugins/\nnpm run api:source -- blur   # locate the Cypress source a /api page documents\n```\n\nInstall before you lint. With no `node_modules` present, `npm run lint:fix`\nstill runs, but on whatever Prettier `npx` fetches rather than the pinned one,\nand a different version reformats files the pinned one leaves alone. For\ncontent-only work, `CYPRESS_INSTALL_BINARY=0 npm i` skips a 250 MB download and\nis enough for every command above except `npm test`.\n\n## Verify ladder (cheap → authoritative)\n\n1. `npm run lint:fix` — **required before every commit** (a Husky/lint-staged\n   hook and CI both enforce Prettier on `*.{md,mdx}`).\n2. `npm run build` — the real safety net for content: `onBrokenLinks` and\n   `onBrokenMarkdownLinks` are `throw`, so any bad link or anchor fails the build.\n3. `npm run typecheck` — when you touched TypeScript in `src/` or `cypress/`, or\n   a script in `scripts/screenshots/`.\n4. `npm run test:plugins` — only when you touched `plugins/`.\n5. `npm test` — for nav/routing or broad changes. Serve a production build\n   first (`npm run build`, then `npm run serve`), which is what CI does. The dev\n   server injects page titles during hydration, so the specs that assert on\n   server-rendered HTML fail against it.\n\nCI runs all of these, so a miss fails the PR rather than `main`. None of them\nexecutes the code inside a code block, so an added or rewritten example also\nneeds [running it yourself](./AGENTS_REFERENCE.md#verifying-code-examples).\n\n## Pull requests\n\nWhen opening a PR, fill out **[`.github/pull_request_template.md`](./.github/pull_request_template.md)**\n(GitHub loads it into the PR body automatically). It is the historical record of\nthe change: complete every section, explaining _why_ the change was made, not\njust _what_ changed.\n\nFor a **release PR** (opened from a `releases/*` branch to document a specific\nproduct release), use the release template instead:\n**[`.github/PULL_REQUEST_TEMPLATE/release.md`](./.github/PULL_REQUEST_TEMPLATE/release.md)**.\nSelect it by appending `?template=release.md` to the compare URL. Name the\ntarget release, list every included change, and make sure a new changelog entry\nis one of them.\n\n## Rules\n\nEach rule is a hard convention. See the linked section for the how and why.\n\n**Pages** — [details](./AGENTS_REFERENCE.md#adding-moving--removing-pages)\n\n- A page is an `.mdx` file under `docs/<section>/`; sidebars are autogenerated, so\n  never hand-edit `sidebars.js` to add one.\n- Include the standard frontmatter (`title`, `description`, `sidebar_label`,\n  `slug`). `title` and `description` are the page's `<title>` and meta\n  description, so make them **SEO-friendly**: lead with the key term and\n  summarize the page accurately. Match the section's house style and mirror a\n  sibling file when unsure. Never append `| Cypress Documentation` to a `title`:\n  a per-section suffix is appended at build time from `src/sectionTitles.js`,\n  and `cypress/e2e/page_titles.cy.ts` asserts it. Never add a `keywords` field to\n  frontmatter —\n  Docusaurus only emits it as a `<meta name=\"keywords\">` tag that modern search\n  engines ignore and that the site's own search doesn't index, so it adds noise\n  with no benefit.\n- Order with `sidebar_position` and `_category_.json`, not `sidebars.js`. Without\n  a `sidebar_position`, pages sort alphabetically; if sibling files don't define\n  one, match them and skip it rather than introducing positions.\n- Moving/renaming/deleting a page **requires** a `301` in both `netlify.toml`\n  and `static/_redirects` (Netlify serves production while Cloudflare builds\n  previews), plus updating in-repo links to it.\n\n**Authoring** — [components](./AGENTS_REFERENCE.md#mdx-components),\n[partials](./AGENTS_REFERENCE.md#partials),\n[naming](./AGENTS_REFERENCE.md#product-heading--naming),\n[code blocks](./AGENTS_REFERENCE.md#code-blocks),\n[AI prompts vs code blocks](./AGENTS_REFERENCE.md#ai-prompts-copyprompt-vs-a-code-block),\n[alt text](./AGENTS_REFERENCE.md#accessible-image-alt-text),\n[diagram contrast](./AGENTS_REFERENCE.md#diagram-color-contrast),\n[screenshots](./scripts/screenshots/README.md)\n\n- Use the MDX components, not raw HTML: `<DocsImage>` / `<DocsVideo>` / `<Icon>`.\n  Always give images meaningful `alt` (describe purpose, not \"screenshot of…\").\n- Capture Cypress App screenshots from a real run of the page's own snippet, never\n  a mock-up: follow the [capture procedure](./scripts/screenshots/README.md).\n- Check every diagram you add or change against WCAG 2.2 AA color contrast before\n  committing it: 4.5:1 for text and 3:1 for lines and shapes the reader needs.\n  Measure each color pair against what it sits on, and report the ratios.\n- Start every product page with `<ProductHeading product=\"…\" />`. Use canonical\n  names: Cypress App, Cypress Cloud, Cypress Accessibility, UI Coverage.\n- Reuse `docs/partials/_*.mdx` instead of repeating content, but only create a\n  partial for content rendered in **more than one location**. If it's used in a\n  single page, inline it there instead.\n- End related pages with a `## See also` section (sentence-case H2, as the page's\n  last section): a short bulleted list of doc-to-doc links to closely related\n  pages, command names in backticks, with an optional `- short description` after\n  a link. It's standard on API reference pages; add it to guides and other pages\n  only when there are genuinely related pages worth surfacing. Don't pad it with\n  tangential links or repeat links already prominent in the page body.\n- Tag every code block with a language; add `title=\"file.ext\"` for file snippets.\n  When an example pairs test code with the app code it runs against (markup,\n  source, a fixture), title every block in the pair with its filename, such as\n  `index.html` and `spec.cy.js`, so the reader tells them apart at a glance.\n- For a copyable, reusable AI prompt (or an agent skill/rule), use `<CopyPrompt>`,\n  not a code block; keep example-specific prompts, code, commands, and diagrams in\n  code blocks. Prompts are expanded by default; add `defaultCollapsed` past 350\n  characters, and never wrap the prompt in quotes. Write `subtext` as the outcome\n  the reader gets, not a restatement that the card copies a prompt for an AI\n  assistant.\n\n**Code examples** — [details](./AGENTS_REFERENCE.md#verifying-code-examples)\n\n- Run every code example you add or rewrite before committing it: typecheck and\n  run it in the throwaway `.example-check/` harness, pasted in verbatim, with an\n  assertion for each claim the prose makes. `npm run build` never executes the\n  code inside a block, so this is the only check it gets.\n- Report every result in the thread, passes included. For each failure, give the\n  error as Cypress printed it, the cause, and a fix with a worked code example\n  you ran and watched pass. Never commit an example that failed.\n- An example you can't run locally (a record key, a Cloud or third-party\n  service) gets reported as not run, with the reason. Being short is not a\n  reason.\n- In Claude Code, the first `git commit` after examples change stops once with\n  a reminder listing them. Run them and report (or say in your report why one\n  doesn't need a run), then commit again. The judgment is yours.\n\n**API reference** — [details](./AGENTS_REFERENCE.md#api-source-of-truth)\n\n- The behavior an `/api` page describes is implemented in `cypress-io/cypress`,\n  not here. Before writing or changing a behavior claim, read that source:\n  `npm run api:source -- <command>` syncs a pinned, sparse checkout of it into\n  `.cypress-source/` and resolves the command to its implementation, published\n  types, error messages, and driver specs.\n- Where the source contradicts the page, flag the conflict rather than rewriting\n  the page to match. The fix may belong in `cypress-io/cypress`.\n\n**Writing style** — [details](./AGENTS_REFERENCE.md#writing-style)\n\n- **Lead a guide with the value of the feature**, what it does for the reader,\n  before getting into configuration or steps. How you do that is up to the page.\n- **Write headings that stand on their own**, since search engines and answer\n  engines surface them without the page around them. \"Cypress Cloud MCP\n  workflows to try\", not \"Workflows to try\". Add the context that makes the\n  heading this page's, keep it to roughly 40 to 60 characters, and use sentence\n  case. The fixed API page skeleton and `## See also` are exempt.\n- Address the reader as **you**. Reserve \"we\" for Cypress speaking as a team\n  (\"we recommend\"), never as a stand-in for the reader.\n- **Present tense, active voice.** \"Cypress retries the assertion\", not \"Cypress\n  will retry the assertion\" or \"the assertion is retried\".\n- **Keep body text current.** Describe how the product works today, without\n  naming the Cypress release that added or changed it (\"supports Escape\", not\n  \"supports Escape in Cypress 15.3.0 and later\"). Version history goes in the\n  page's `## History` table and the changelog. Deprecation, removal, and\n  migration notes are the exception, since the reader needs the version to\n  upgrade.\n- **Say what something does**, not what it lets the reader do. \"`cy.session()`\n  caches and restores session state\", not \"allows you to cache…\".\n- Plain words over formal ones: not `leverage`, `utilize`, or `in order to`.\n- Cut filler. `please`, `note that`, and hedges that carry no information.\n- Don't use minimizing words like \"simply\", \"just\", \"easy\", or \"obviously\" in\n  instructions. They undermine a reader who is struggling and add nothing; state\n  the step plainly instead. Don't tell the reader a feature is easy or fast,\n  either. Show it with a short example and let them draw the conclusion. The\n  rule is the minimizing sense, not the letters: \"not just\", \"just as\", and\n  `just-in-time` are other words doing other work.\n- Go easy on em dashes. Overused, they read as AI-generated, so prefer a comma,\n  period, colon, or parentheses and rework the sentence rather than reaching for\n  a dash. Keep one where it is clearly the best fit, rarely more than one per\n  paragraph.\n- **Link text names its destination.** Never `[here]`, `[this link]`, or\n  `[learn more]`.\n- Oxford comma. US English, except that every `cancel` form doubles the `l`:\n  **cancellation**, **cancelled**, **cancelling**. Leave a single `l` only where\n  it is a literal you are quoting, such as an API value or UI string.\n- Write \"accessibility\", not \"a11y\", in prose. Keep `a11y` where it is part of an\n  actual name, such as the `data-a11y-ignore` attribute, the `checkA11y()`\n  command, or an identifier like a `groupId` or an image filename.\n- Bullets take no terminal punctuation when they are fragments and a period when\n  they are full sentences. Don't mix the two within one list.\n- Use **bold** only for real UI controls the reader acts on in a walkthrough\n  (actual buttons, links, tabs, and flows in Cypress Cloud or the Cypress App,\n  e.g. the **App Quality** tab). Put hypothetical UI labels from illustrative\n  examples in `\"quotes\"` instead (e.g. an `\"Add to cart\"` button in a sample),\n  so invented examples stay distinct from the real UI a tutorial navigates.\n- Describe configuration by what it does and accepts. Don't call out fields or\n  features a property lacks (e.g. \"there is no `comment` field\") unless the\n  absence is a documented point of confusion.\n- Frame behavior explanations positively and reader-first. Avoid phrasings that\n  sound like caveats about the product's design, such as \"consequences of this\n  design\"; prefer neutral lead-ins like \"Keep these behaviors in mind\".\n\n**Directives & tabs** — [tabs](./AGENTS_REFERENCE.md#tabs),\n[config](./AGENTS_REFERENCE.md#cypress-config-examples),\n[e2e/ct](./AGENTS_REFERENCE.md#e2e-vs-component-examples)\n\n- Cypress config snippets → `:::cypress-config-example` (or\n  `:::cypress-config-plugin-example`). Never hand-write `defineConfig` + tabs.\n- TS/JS examples → one `ts` block tagged `copyTsToJs`; never maintain a JS copy.\n- E2E-vs-component snippets → `:::visit-mount-example`.\n- Package-manager commands → `<PackageManagerTabs>` (with `install`, `run`, or\n  `exec`) or `<CypressCommandTabs>` for `cypress` subcommands. Never hand-write\n  npm/Yarn/pnpm/Bun tab sets.\n- Tabs sync via a shared `groupId`. Fixed orders: package managers\n  **npm → Yarn → pnpm → Bun**; frameworks **React → Angular → Vue → Svelte**; JS\n  before TS.\n\n**Admonitions** — [details](./AGENTS_REFERENCE.md#admonition-blocks)\n\n- `:::info` (default), `:::tip`, `:::note`, `:::caution` (prefer over\n  `:::warning`), `:::danger`. Keep them short and infrequent.\n\n**Linking** — [details](./AGENTS_REFERENCE.md#linking)\n\n- Doc-to-doc: absolute site path, no `.mdx` extension (`/api/commands/origin`).\n- Heading anchors **preserve case** and hyphenate spaces\n  (`## Disabling Web Security` → `#Disabling-Web-Security`); avoid custom\n  `{#id}` anchors.\n- Links to `www.cypress.io` / `on.cypress.io` / `learn.cypress.io` need UTM\n  params (`utm_source=docs.cypress.io` + a placement `utm_medium`). Do not add\n  them to internal links or `cloud.cypress.io`.\n\n**GitHub Actions workflows** — [details](./.github/workflows/AGENTS.md)\n\n- Read that guide before adding or editing a workflow. Every file in\n  `.github/workflows/` is copied into each fork and runs there with reduced\n  permissions, so an unguarded job that pushes commits, opens pull requests, or\n  reads secrets fails in somebody else's repository.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/cypress-io/cypress-documentation/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}