Skip to main content
ClaudeWave
Skill155.4k repo starsupdated today

e2e-cucumber-playwright

This Claude Code skill handles writing, updating, and reviewing end-to-end tests in the Dify repository's `e2e/` directory using Cucumber feature files, Gherkin syntax, and Playwright for browser automation. Use it when working with `.feature` files, step definitions, the `DifyWorld` context object, scenario tags, locator selection, assertions, or E2E testing best practices specific to Dify's testing architecture and conventions.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/langgenius/dify /tmp/e2e-cucumber-playwright && cp -r /tmp/e2e-cucumber-playwright/.agents/skills/e2e-cucumber-playwright ~/.claude/skills/e2e-cucumber-playwright
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# E2E Cucumber And Playwright

`e2e/AGENTS.md` owns the suite architecture, lifecycle, commands, tags, generated-client boundaries, fixtures, and cleanup contracts. Read the nearest feature-scoped `AGENTS.md` when one exists. This skill adds no parallel package policy.

## Topic Routing

Read only the bundled reference required by the change:

- Locator, assertion, isolation, or waiting decisions: [`references/playwright-best-practices.md`][playwright]
- Scenario wording, step granularity, expressions, or tag design: [`references/cucumber-best-practices.md`][cucumber]

Check current official Playwright or Cucumber documentation before introducing a framework pattern that local code and references do not already establish.

## Workflow

1. Add E2E coverage only for a critical user journey with a cross-boundary outcome that cheaper owner-level tests do not already prove.
2. Identify the user-visible behavior and its feature owner. Start from real product defaults and actor roles; setup may establish preconditions but must not manufacture the opposite state to make the scenario meaningful.
3. Read the target scenario, matching step definitions, and lifecycle files only when session or shared state matters.
4. Reuse an existing step when wording and behavior match; add one coherent scenario or step when they do not.
5. Keep browser actions and assertions at the public user boundary; keep setup, seed, polling, and cleanup at their package-defined owners.
6. Run the narrowest tagged scenario and package checks documented in `e2e/AGENTS.md`; broaden only for shared hooks, tags, or support changes.

For review requests, lead with reproducible correctness failures, flake sources, or demonstrated architecture drift. Report the behavior verified and any external-runtime, browser, or environment gap.

[cucumber]: references/cucumber-best-practices.md
[playwright]: references/playwright-best-practices.md
backend-code-reviewSkill

Use only when the user explicitly requests a review or audit of backend code under `api/`. Supports pending-change, file-focused, and pasted-diff reviews. Do not use for implementation-only requests, diagnosis without review intent, frontend code, or backend code outside `api/`.

component-refactoringSkill

Refactor high-complexity React components in Dify frontend. Use when `pnpm analyze-component --json` shows complexity > 50 or lineCount > 300, when the user asks for code splitting, hook extraction, or complexity reduction, or when `pnpm analyze-component` warns to refactor before testing; avoid for simple/well-structured components, third-party wrappers, or when the user explicitly wants testing without refactoring.

frontend-code-reviewSkill

Use only when the user explicitly requests a review or audit of frontend code under `web/` or `packages/dify-ui/`. Supports pending-change, file-focused, and pasted-diff reviews. Do not use for implementation-only requests, diagnosis without review intent, or backend-only code.

frontend-testingSkill

Use when writing or changing Vitest or React Testing Library tests under `web/` or `packages/dify-ui/`, or when the user explicitly requests frontend test strategy, including evaluation of an existing strategy. Do not use for frontend code-review-only requests, general testability discussion, Python tests, or Cucumber/Playwright E2E.

how-to-write-componentSkill

Use when implementing or refactoring React/TypeScript components and the task requires decisions about component ownership, feature boundaries, state, data flow, effects, or interaction ownership. Do not use for review-only requests, test-only work, copy-only edits, or styling-only changes.

karpathy-guidelinesSkill

Lightweight coding guardrails for making focused, simple, and verifiable changes in this repo. Use for all coding work.