القائمة
Guide for writing, running, and debugging Playwright E2E tests.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/jdelfino/agent-workflow --skill playwright-debuggingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
Single entry point for all implementation work. Triages tasks, manages beads issues, delegates to implementer skill, runs reviewers, creates PRs.
Pure development workflow with required test coverage and a coverage audit. Used by coordinator as a subagent. Commits work but never manages beads issues.
Collaboratively plan epics by exploring the codebase, discussing tradeoffs, filing issues, and running plan review. Invoked via /plan.
عرض SKILL.md
| name | playwright-debugging |
| description | Guide for writing, running, and debugging Playwright E2E tests. |
Guide for writing, running, and debugging Playwright E2E tests.
When a test fails, follow this sequence:
Playwright error messages are descriptive. They tell you exactly what selector failed and why. Start there.
Failed tests generate test-results/<test-name>/error-context.md with a YAML representation of the page structure:
- heading "Dashboard" [level=1] [ref=e10]
- paragraph [ref=e11]: Enter your section code to
[] []
[] []
This shows the actual DOM state at failure time — often more useful than screenshots for understanding what elements are rendered and their states.
On failure, Playwright captures:
test-results/<test-name>/ — shows what the page looked likeOpen the HTML report:
npx playwright show-report
Look for non-200 responses or unexpected error bodies in the browser console logs or network tab of the trace viewer.
Common failure patterns:
For interactive debugging:
# Run a single test with browser visible
npx playwright test e2e/your-test.spec.ts --headed
# Or with Playwright Inspector (step-by-step debugging)
npx playwright test e2e/your-test.spec.ts --debug
npx playwright test
npx playwright test e2e/your-test.spec.ts
npx playwright test -g "test name substring"
Every test file follows this pattern:
import { test, expect } from '@playwright/test';
test.describe('Feature Name', () => {
test('what it does', async ({ page }) => {
// 1. SETUP — create test data (via API helpers or fixtures)
// 2. UI INTERACTION — navigate and interact
await page.goto('/some-page');
// 3. ASSERTIONS — verify expected state
await expect(page.locator('h1')).toHaveText('Expected Title');
});
});
browser.newContext() when testing interactions between different users.expect(...).toBeVisible(), page.waitForURL() etc. handle retries automatically. Avoid waitForTimeout except for debounce windows.test.setTimeout(60000) for complex multi-step tests; { timeout: 15000 } for slow assertions.Use separate browser contexts for different users:
test('multi-user flow', async ({ page, browser }) => {
// Create a separate browser context for user B
const userBContext = await browser.newContext();
const userBPage = await userBContext.newPage();
try {
// ... user A actions on `page` ...
// ... user B actions on `userBPage` ...
} finally {
await userBContext.close();
}
});