菜单
Write Playwright E2E tests for user flows and browser interactions. Use when testing HTMX, user journeys, or when the user mentions E2E, Playwright, or browser testing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | playwright-tests |
| description | Write Playwright E2E tests for user flows and browser interactions. Use when testing HTMX, user journeys, or when the user mentions E2E, Playwright, or browser testing. |
| allowed-tools | Read, Grep, Glob |
This Skill helps write end-to-end tests for browser-required behavior.
Use this Skill when:
@pytest.mark.playwrightpage and live_server fixturesreverse() for URLs, never hardcodeexpect(locator).to_be_visible() and similar expect() matchers — they auto-wait and surface better failure messages than wait_for_selector / is_visible.get_by_role → get_by_label → get_by_text → get_by_test_id → CSS as a last resort.tests/e2e/@pytest.mark.playwright (all under tests/e2e/) is the browser set a downstream excludes — keep every browser test under this marker and don't rename it. For why, and the exact downstream selection, see the Portability note in the resource file and the fls:testing skill's marker taxonomy.expect() API is (currently available) — use it for all auto-waiting assertions instead of wait_for_selector / is_visible.storage_state) so most tests skip the login flow. See the resource file for the full pattern.--tracing=retain-on-failure --screenshot=only-on-failure in pyproject.toml addopts). Traces land in test-results/<nodeid>/trace.zip and CI uploads test-results/ as the playwright-traces artifact on failure. Treat trace artefacts as sensitive — they may contain fixture credentials or session cookies.HX-Trigger assertions, 422 validation responses) see the fls:testing skill.fls:htmx skill.Refer to ${CLAUDE_PLUGIN_ROOT}/resources/playwright-testing.md for full patterns.
Refer to ${CLAUDE_PLUGIN_ROOT}/resources/testing.md for general testing guidelines.
FLS content types, file formats, and frontmatter schemas. Use when authoring a topic, form, quiz, survey, course, course part, chapter, module, or any content file.
FLS course-authoring conventions — numbering, file naming, UUID rules, and HTML-escaping rules. Use when asking about uuid, numbering, ordering, file name, folder, or directory structure.
Define and manage per-app Django settings via per-app config.py modules. Use when adding, reading, or enforcing a setting an app owns, when a downstream project must supply a value, or when the user mentions config.py, AppSettings, declared_settings, required settings, or COURSE_ACCESS_BACKEND.
Write pytest tests. Use when implementing features, fixing bugs, or when the user mentions testing, TDD, or pytest
Every FLS c-* widget — purpose, attributes, and examples. Use when asking about a widget, component, admonition, flashcard, accordion, youtube, picture, table, code block, card, pull quote, or equation.
When and how to convert messy Markdown into valid FLS content structure. Use when converting, restructuring, or importing markdown, or when pasting content into FLS.