Cypress AI Skills: Teaching Your AI Assistant to Write Better Tests

I’ve been using AI tools like Cursor and Claude Code to help write Cypress tests. It’s fast, and for simple cases, it works well enough.

But as soon as you try to use it in a real project, the cracks start to show.

You ask the AI to write a test, and you get something like this:

cy.get('.btn-primary').click()
cy.wait(3000)
cy.get('.modal-content .success').should('be.visible')

It works, technically. But it doesn’t look like something your team would ever commit.

In most real-world projects, we avoid CSS selectors, we don’t rely on arbitrary waits, and we lean heavily on custom commands to keep tests maintainable. So instead of saving time, you end up rewriting most of what the AI generated.

That’s the gap Cypress AI Skills is trying to close.

The Real Shift: From Code Generation to Code Alignment

Most AI tools are good at generating code, but they don’t understand your codebase.

They don’t know your selector strategy.
They don’t know your custom commands.
They don’t know your conventions or patterns.

So they produce generic output.

Cypress AI Skills introduces a simple but powerful idea: instead of asking AI to generate code, you teach it how your team writes tests.

These skills live inside your project. They are not a service or a black box. Your AI assistant reads them, along with your existing code, and uses that context when generating or reviewing tests.

Getting Started

The setup is intentionally simple:

npx skills add cypress-io/ai-toolkit

Once installed, your AI assistant can use two key capabilities: cypress-author and cypress-explain.

Writing Tests with cypress-author

The difference becomes obvious when you actually use the skill.

Instead of a generic prompt, you explicitly guide the AI:

/cypress-author Create a login test using existing custom commands and data-cy selectors

Before generating anything, the AI looks into your project. It scans your Cypress configuration, your support files, and your custom commands.

So instead of producing something like:

cy.get('.email-input').type('[e-mail]')
cy.get('.password-input').type('password')
cy.get('.login-btn').click()

It generates something aligned with your actual setup:

describe('Authentication Flow', () => {
  it('logs in successfully and redirects to dashboard', () => {
    const user = { email: '[e-mail]', password: 'Password123' }

    cy.login(user.email, user.password)

    cy.url().should('include', '/dashboard')
    cy.getByCy('welcome-message').should('be.visible')
  })
})

The important part is not just cleaner code. The AI is now:

• Reusing your abstractions instead of duplicating logic
• Following your selector conventions
• Structuring tests the way your team already does

This is where AI starts becoming useful in a real codebase.

Reviewing and Improving Tests with cypress-explain

If cypress-author helps you write tests, cypress-explain helps you improve them.

You can take an existing test and ask:

/cypress-explain Review this test for flakiness and bad practices

Given something like this:

cy.get('.checkout-btn').click()
cy.wait(2000)
cy.get('.confirmation').should('be.visible')

The AI doesn’t just describe the test. It evaluates how it’s written.

It will point out things like:

• Reliance on arbitrary waits
• Brittle selectors
• Missing synchronization with network calls

And it typically suggests a more stable version:

cy.intercept('POST', '/api/checkout').as('checkout')
cy.getByCy('checkout-btn').click()
cy.wait('@checkout')
cy.getByCy('order-confirmation').should('be.visible')

In practice, this feels less like code generation and more like having a second reviewer who understands Cypress-specific pitfalls.

What Actually Changes in a Real Project

One of the most useful ways to think about this is through transformation.

Without context, AI writes tests that are technically valid but fragile:

cy.get('.login-btn').click()
cy.wait(2000)
cy.get('.dashboard').should('exist')

With Cypress AI Skills, the same intent becomes:

cy.intercept('POST', '/api/login').as('loginRequest')
cy.getByCy('login-btn').click()
cy.wait('@loginRequest')
cy.getByCy('dashboard').should('be.visible')

The shift is subtle but meaningful. The test becomes more stable, easier to read, and consistent with the rest of your suite.

This is not about writing faster tests. It’s about writing tests that don’t need to be rewritten later.

Where This Helps the Most

In real projects, the value shows up in a few consistent places.

When refactoring older tests, the AI can take brittle patterns and align them with your current standards. Instead of manually fixing selectors and waits across files, you can guide the transformation with a prompt.

When generating tests from requirements, the AI produces code that already fits your project structure, including your helpers and naming conventions.

When debugging flaky tests, cypress-explain helps quickly identify the root cause, especially around timing issues and missing intercepts.

It also becomes surprisingly useful for onboarding. New engineers can ask the AI to explain how tests are structured or how certain flows are implemented, and the answers are grounded in your actual codebase.

A Note on cy.prompt()

There is also an emerging pattern around intent-based testing using cy.prompt().

Instead of targeting elements directly, you describe the action:

cy.prompt('Navigate to the final payment screen')

The idea is to express intent rather than implementation.

This can be useful in cases where the UI changes frequently or when working with third-party components where selectors are unstable.

That said, this approach is still evolving. It introduces variability and can be slower than traditional tests, so it’s better suited for exploratory or non-critical flows rather than core test paths.

Making This Work for Your Team

For Cypress AI Skills to be effective, a few foundational things matter.

Your project should have clear conventions. If your selectors and patterns are inconsistent, the AI won’t have a strong signal to follow.

It also helps to make those conventions visible. Even a simple document describing your testing approach can improve the quality of AI output.

One important practice is to treat these skills as part of your codebase. Commit them, version them, and let your entire team benefit from the same behavior. This ensures that AI-assisted code remains consistent regardless of who generates it.

And like any generated code, it still needs review. The goal is not to remove that step, but to make it faster and more focused.

What This Is (and What It’s Not)

Cypress AI Skills are not a solution for fully automated testing. They don’t magically fix flaky tests, and they don’t replace the need for thoughtful test design.

What they do is much more practical.

They reduce the gap between what AI generates and what your team expects.

Instead of treating AI as a generic code generator, you start treating it as a project-aware assistant.

Conclusion

AI is already changing how we write code, but testing has been slower to benefit because generic output rarely aligns with real-world practices.

Cypress AI Skills takes a meaningful step forward by making AI aware of your project, your conventions, and your workflows.

It’s not a dramatic shift, but it’s a practical one. And in day-to-day engineering, those are the improvements that actually stick.

If you’re already using AI tools with Cypress, this small change can make a noticeable difference.

Reference:
Cypress AI Skill