Community Skills (32): - jat: jat-start, jat-verify, jat-complete - pi-mono: codex-cli, codex-5.3-prompting, interactive-shell - picoclaw: github, weather, tmux, summarize, skill-creator - dyad: 18 skills (swarm-to-plan, multi-pr-review, fix-issue, lint, etc.) - dexter: dcf valuation skill Agents (23): - pi-mono subagents: scout, planner, reviewer, worker - toad: 19 agent configs (Claude, Codex, Gemini, Copilot, OpenCode, etc.) System Prompts (91): - Anthropic: 15 Claude prompts (opus-4.6, code, cowork, etc.) - OpenAI: 49 GPT prompts (gpt-5 series, o3, o4-mini, tools) - Google: 13 Gemini prompts (2.5-pro, 3-pro, workspace, cli) - xAI: 5 Grok prompts - Other: 9 misc prompts (Notion, Raycast, Warp, Kagi, etc.) Hooks (9): - JAT hooks for session management, signal tracking, activity logging Prompts (6): - pi-mono templates for PR review, issue analysis, changelog audit Sources analyzed: jat, ralph-desktop, toad, pi-mono, cmux, pi-interactive-shell, craft-agents-oss, dexter, picoclaw, dyad, system_prompts_leaks, Prometheus, zed, clawdbot, OS-Copilot, and more
4.3 KiB
name, description
| name | description |
|---|---|
| dyad:debug-with-playwright | Debug E2E tests by taking screenshots at key points to visually inspect application state. |
Debug with Playwright Screenshots
Debug E2E tests by taking screenshots at key points to visually inspect application state.
Arguments
$ARGUMENTS: (Optional) Specific E2E test file to debug (e.g.,main.spec.tsore2e-tests/main.spec.ts). If not provided, will ask the user which test to debug.
Background
Dyad uses Electron + Playwright for E2E tests. Because Playwright's built-in screenshot: "on" option does NOT work with Electron (see https://github.com/microsoft/playwright/issues/8208), you must take screenshots manually via page.screenshot().
The test fixtures in e2e-tests/helpers/fixtures.ts already auto-capture a screenshot on test failure and attach it to the test report. But for debugging, you often need screenshots at specific points during test execution.
Instructions
-
Identify the test to debug:
If
$ARGUMENTSis empty, ask the user which test file they want to debug.- If provided without the
e2e-tests/prefix, add it - If provided without the
.spec.tssuffix, add it
- If provided without the
-
Read the test file:
Read the test file to understand what it does and where it might be failing.
-
Add debug screenshots to the test:
Add
page.screenshot()calls at key points in the test to capture visual state. Access the page from thepofixture:// Get the page from the electronApp fixture const page = await electronApp.firstWindow(); // Or if you only have `po`, access the page directly: // po is a PageObject which has a `page` propertyScreenshot patterns for debugging:
import * as fs from "fs"; import * as path from "path"; // Create a debug screenshots directory const debugDir = path.join(__dirname, "debug-screenshots"); if (!fs.existsSync(debugDir)) { fs.mkdirSync(debugDir, { recursive: true }); } // Take a full-page screenshot await page.screenshot({ path: path.join(debugDir, "01-before-action.png"), }); // Take a screenshot of a specific element const element = page.locator('[data-testid="chat-input"]'); await element.screenshot({ path: path.join(debugDir, "02-chat-input.png"), }); // Take a screenshot after some action await po.sendPrompt("hi"); await page.screenshot({ path: path.join(debugDir, "03-after-send.png"), });Important: The test fixture signature provides
{ electronApp, po }. To get the page:- Use
await electronApp.firstWindow()to get the page - Or use
po.pageif PageObject exposes it
Add screenshots before and after the failing step to understand what the UI looks like at that point.
- Use
-
Build the app (if needed):
E2E tests run against the built binary. If you made any application code changes:
npm run buildIf you only changed test files, you can skip this step.
-
Run the test:
PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_HTML_OPEN=never npm run e2e -- e2e-tests/<testfile>.spec.ts -
View the screenshots:
Use the Read tool to view the captured PNG screenshots. Claude Code can read and display images directly:
Read the PNG files in e2e-tests/debug-screenshots/Analyze the screenshots to understand:
- Is the expected UI element visible?
- Is there an error dialog or unexpected state?
- Is a loading spinner still showing?
- Is the layout correct?
-
Check the Playwright trace (for additional context):
The Playwright config has
trace: "retain-on-failure". If the test failed, a trace file will be intest-results/. You can reference this for additional debugging context. -
Iterate:
Based on what you see in the screenshots:
- Add more targeted screenshots if needed
- Fix the issue in the test or application code
- Re-run to verify
-
Clean up:
After debugging is complete, remove the debug screenshots and any temporary screenshot code you added to the test:
rm -rf e2e-tests/debug-screenshots/Remove any
page.screenshot()calls you added for debugging purposes. -
Report findings:
Tell the user:
- What the screenshots revealed about the test failure
- What fix was applied (if any)
- Whether the test now passes