Cypress Docs
Look up verified Cypress APIs, defaults, and behavior from official docs before writing or fixing E2E and component tests.
Overview
Cypress-docs is an agent skill for the Ship phase that searches and extracts verified Cypress facts from official documentation, preferring `/llm/*` sources.
Install
npx skills add https://github.com/cypress-io/ai-toolkit --skill cypress-docsWhat is this skill?
- Prioritizes official docs.cypress.io and cypress.io with LLM-oriented paths under `/llm/*` and `llms.txt`
- Refuses unverified API signatures, defaults, and deprecated behavior claims
- Covers E2E vs component testing, cy.intercept, hooks, CLI flags, plugins, and TypeScript types
- Use before stating “Cypress can or cannot” do something in code review or user answers
- Structured extraction for summarizing doc pages without inventing APIs
Adoption & trust: 563 installs on skills.sh; 27 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need exact Cypress command signatures and behavior but memory and blog posts disagree with what the current docs actually say.
Who is it for?
Solo builders writing or reviewing Cypress E2E or component tests who want doc-grounded agent answers.
Skip if: Tasks that only need generic JavaScript testing patterns with no Cypress-specific doc lookup, or projects using Playwright exclusively.
When should I use this skill?
The task depends on finding, reading, or quoting Cypress official documentation rather than general testing intuition.
What do I get? / Deliverables
Answers and test code cite official Cypress documentation paths so APIs, defaults, and deprecations match docs.cypress.io.
- Doc-sourced excerpts with official URLs or `/llm/*` paths
- Behavior confirmations for APIs and configuration
- Examples aligned with retrieved documentation
Recommended Skills
Journey fit
Ship/testing is where Cypress knowledge matters: commands, intercept, config, and version-specific semantics must be correct before tests ship. Testing subphase covers framework-accurate test authoring and reviews grounded in docs.cypress.io rather than guesswork.
How it compares
Use instead of asking the model to recall Cypress APIs from training data when correctness must match official docs.
Common Questions / FAQ
Who is cypress-docs for?
Indie web developers and agent users who depend on Cypress and need documentation-backed lookups during test work.
When should I use cypress-docs?
During Ship/testing when looking up commands, confirming version behavior, extracting `/llm/*` doc content, or before claiming Cypress support for a feature.
Is cypress-docs safe to install?
It implies network access to official Cypress sites; review the Security Audits panel on this page and restrict network if your policy requires it.
SKILL.md
READMESKILL.md - Cypress Docs
# Cypress Documentation ## Purpose Enable the agent to retrieve accurate, up-to-date, and verifiable information about the Cypress testing framework by prioritizing official documentation and structured sources. ## When to use Apply this skill whenever the task depends on **finding, reading, or quoting Cypress documentation** rather than general testing intuition: - **Look up facts**: commands, APIs, assertions, lifecycle hooks, configuration options, environment variables, CLI flags, plugins, or TypeScript types as documented by Cypress. - **Confirm behavior**: how something works in a given Cypress version, E2E vs component testing differences, browser support, or networking/cy.intercept semantics. - **Before asserting “Cypress can/cannot…”**: search docs first; do not rely on memory for exact signatures, defaults, or deprecated APIs. - **Extract structured content**: follow the LLM-optimized docs strategy below (`llms.txt`, `/llm/*`) when fetching or summarizing doc pages. - **Ground answers for others**: when explaining Cypress to a user, writing examples, or reviewing code where correctness must match official docs. If the user only needs **writing or fixing tests** without a documentation lookup, prefer `cypress-author`; if they only need **test explanation** without fetching docs, prefer `cypress-explain`. Use **this** skill when official documentation is the source of truth. ## Source Prioritization ### Primary Sources (ALWAYS search first) - https://docs.cypress.io - https://www.cypress.io ## 🤖 LLM-Optimized Docs Strategy When accessing `docs.cypress.io`: 1. Fetch `/llms.txt` 2. Parse it to discover: - LLM-friendly documentation paths - Structured content endpoints 3. Prefer content under `/llm/*`. Every path on the site has an optimized version hosted under `/llm` - for example, `https://docs.cypress.io/app/faq` is available at `https://docs.cypress.io/llm/markdown/app/faq.md`. 4. Why: - Markdown / JSON format - Cleaner structure - Less noise than HTML 5. Fallback: - If `/llm/*` is incomplete, use standard docs pages ## Critical Rules ### Never Assume Missing Features - NEVER assume Cypress does not support a feature - ALWAYS search before concluding - Retry with alternate terminology if needed ### Anti-Hallucination Guard If documentation cannot verify a claim: - Say: "I could not verify this in Cypress docs" - Provide closest supported alternative (if available) - DO NOT invent APIs or behavior ## Search Strategy ### 1. Classify the Query | Query Type | Search Location | |------------------|------------------------------| | How do I... | /guides/, /core-concepts/ | | What is... | /core-concepts/ | | API / Commands | /api/commands/ | | Assertions | /api/assertions/ | | Config issues | /configuration/ | | CI/CD | /guides/ci-cd/ | | Errors | /references/error-messages/ | ### 2. Search Flow 1. `/llm/*` (via `/llms.txt`) 2. Standard docs pages 3. `/changelog/` 4. `cypress.io` (blog, updates) ### 3. Error-Aware Routing If the query includes: - Error messages - Stack traces Then: 1. Search `/references/error-messages` 2. Expand to guides and API docs ## Structured Extraction Rules ### Commands - Syntax - Required arguments - Optional options - Return behavior - Example usage ### Concepts - Definition - Key rules - Common pitfalls - Example ### Configuration - Option name - Type - Default value - Example ## Version Awareness - Detect Cypress version if provided - If NOT provided: assume latest stable version - If behavior differs by version: - Explicitly call it out