home / skills / dyad-sh / dyad / pr-screencast

pr-screencast skill

/.claude/skills/pr-screencast

This skill records a visual screencast of the PR feature using screenshots and posts it as a new comment on the PR.

npx playbooks add skill dyad-sh/dyad --skill pr-screencast

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
8.6 KB
---
name: dyad:pr-screencast
description: Record a visual demonstration of the key feature of this PR using screenshots and add it as a new comment to the PR.
---

# PR Screencast

Record a visual demonstration of the key feature of this PR using screenshots and add it as a new comment to the PR.

**IMPORTANT:** This skill should complete all steps autonomously where possible. Permission prompts from Claude Code for file writes, bash commands, or GitHub operations should be accepted as normal — do not treat them as blockers.

## Arguments

- `$ARGUMENTS`: (Optional) PR number or URL. If not provided, will use the PR associated with the current branch.

## Task Tracking

**You MUST use the TodoWrite tool to track your progress.** At the start, create tasks for each step below. Mark each task as `in_progress` when you start it and `completed` when you finish. This ensures you complete ALL steps.

## Instructions

1. **Determine the PR:**

   If `$ARGUMENTS` is provided, use it as the PR number or URL.

   Otherwise, get the PR for the current branch:

   ```
   gh pr view --json number,title,body,files,headRefOid -q '.number'
   ```

   If no PR exists for the current branch, report an error and stop.

2. **Analyze if this PR is user-facing:**

   Fetch the PR details including changed files:

   ```
   gh pr view <PR_NUMBER> --json title,body,files,labels
   ```

   **Skip recording if the PR is NOT user-facing.** A PR is NOT user-facing if:
   - It only changes documentation files (`*.md`, `*.txt`, `*.rst`)
   - It only changes configuration files (`*.json`, `*.yaml`, `*.yml`, `*.toml`, `*.config.*`)
   - It only changes test files (`*test*`, `*spec*`, `*tests*`)
   - It only changes CI/CD files (`.github/*`, `.circleci/*`, etc.)
   - It only changes type definitions (\*.d.ts)
   - It has labels like "refactor", "chore", "docs", "ci", "internal", "dependencies"
   - The title/body indicates it's a refactoring, internal change, or non-user-facing work

   If the PR is not user-facing, post a brief comment explaining why the screencast was skipped:

   ```
   gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
   ## Screencast Skipped

   This PR appears to be a non-user-facing change (refactoring, documentation, tests, or internal changes), so no screencast was recorded.

   ---
   *Automated by `/dyad:pr-screencast`*
   EOF
   )"
   ```

   Then stop.

3. **Identify the key feature to demonstrate:**

   Analyze the PR to understand:
   - What UI component or feature was added/changed?
   - What user action triggers the feature?
   - What is the expected visual outcome?

   Read the changed files to understand:
   - Which components are affected
   - What user interactions are involved
   - What visual changes should be demonstrated

   Formulate a plan for what the screencast should show:
   - Starting state (screenshot 1)
   - User actions to perform
   - Result state (screenshot 2-3)

4. **Create a Playwright screencast script:**

   Create a new file at `e2e-tests/screencast-demo.spec.ts` that takes multiple screenshots to tell the visual story:

   ```typescript
   import { expect } from "@playwright/test";
   import { test } from "./helpers/fixtures";
   import * as fs from "fs";
   import * as path from "path";

   test.describe.configure({ mode: "serial" });

   test("PR Demo Screencast", async ({ electronApp, po }) => {
     // Ensure screenshots directory exists
     const screenshotDir = path.join(__dirname, "screencast-screenshots");
     if (!fs.existsSync(screenshotDir)) {
       fs.mkdirSync(screenshotDir, { recursive: true });
     }

     const page = await electronApp.firstWindow();

     // Set up the app for demo
     await po.setUp({ autoApprove: true });

     // Import or create a test app if needed
     await po.importApp("minimal");

     // Wait for app to be ready
     await page.waitForTimeout(1000);

     // === STEP 1: Capture initial state ===
     await page.screenshot({
       path: path.join(screenshotDir, "01-initial-state.png"),
       fullPage: false,
     });

     // === STEP 2: Navigate to the feature / perform action ===
     // TODO: Replace with actual navigation/interaction for this PR
     // Example: await po.goToSettingsTab();
     await page.waitForTimeout(500);

     await page.screenshot({
       path: path.join(screenshotDir, "02-during-action.png"),
       fullPage: false,
     });

     // === STEP 3: Show the result ===
     // TODO: Replace with actual result state
     await page.waitForTimeout(500);

     await page.screenshot({
       path: path.join(screenshotDir, "03-final-result.png"),
       fullPage: false,
     });

     // Verify the final screenshot exists to ensure all steps completed
     expect(
       fs.existsSync(path.join(screenshotDir, "03-final-result.png")),
     ).toBe(true);
   });
   ```

   **Customize the script based on the feature being demonstrated:**
   - Use the PageObject methods from `e2e-tests/helpers/page-objects/PageObject.ts`
   - Use stable selectors (data-testid, role, text)
   - Add appropriate waits between actions (500-1000ms) so screenshots are clear
   - Capture 2-4 screenshots showing the progression of the feature

5. **Build the app:**

   The app must be built before recording:

   ```
   npm run build
   ```

6. **Run the screencast test:**

   Run the test to capture screenshots:

   ```
   PLAYWRIGHT_HTML_OPEN=never npx playwright test e2e-tests/screencast-demo.spec.ts --timeout=120000 --reporter=list
   ```

   If the test fails, read the error output, fix the script, and try again (up to 3 attempts). If the test still fails after 3 attempts, post a comment on the PR indicating the screencast could not be captured and report the error. Common issues:
   - Missing selectors - check the component implementation
   - Timing issues - add more `waitForTimeout` calls
   - Import app issues - try a different test app or create from scratch

7. **Verify screenshots were captured:**

   Check that the screenshots exist:

   ```
   ls -la e2e-tests/screencast-screenshots/
   ```

   You should see 2-4 PNG files. If not, check the test output for errors.

8. **Upload screenshots to GitHub:**

   Upload screenshots to an `assets` branch so they can be referenced in PR comments.

   ```bash
   # Get repo info
   REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
   TIMESTAMP=$(date +%Y%m%d-%H%M%S)
   ASSET_DIR="pr-screencasts/pr-<PR_NUMBER>-$TIMESTAMP"

   # Create or update the assets branch
   git fetch origin assets:assets 2>/dev/null || git checkout --orphan assets

   # Switch to assets branch, preserving working directory
   git stash --include-untracked
   git checkout assets 2>/dev/null || (git checkout --orphan assets && git rm -rf . 2>/dev/null || true)

   # Create directory and copy screenshots
   mkdir -p "$ASSET_DIR"
   git stash pop 2>/dev/null || true
   cp e2e-tests/screencast-screenshots/*.png "$ASSET_DIR/"

   # Commit and push
   git add "$ASSET_DIR"
   git commit -m "Add screencast assets for PR #<PR_NUMBER>"
   git push origin assets

   # Switch back to original branch
   git checkout -
   git stash pop 2>/dev/null || true
   ```

   The screenshots will be accessible at:

   ```
   https://raw.githubusercontent.com/<REPO>/assets/<ASSET_DIR>/<filename>.png
   ```

   **Fallback: Use text description if upload fails:**
   If uploads don't work, describe the screenshots in text format.

9. **Post the comment to the PR:**

   Create the PR comment with the demonstration:

   ```
   gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
   ## Feature Demo

   ### What this PR does
   <Brief description of the feature based on your analysis>

   ### Visual Walkthrough

   **Step 1: Initial State**
   <Description of screenshot 1 - or embed image if uploaded>

   **Step 2: User Action**
   <Description of what the user does and screenshot 2>

   **Step 3: Result**
   <Description of the final result and screenshot 3>

   ### How to Test Manually
   1. <Step to reproduce>
   2. <Expected behavior>

   ---
   *Automated by `/dyad:pr-screencast`*
   EOF
   )"
   ```

   **IMPORTANT:** Do NOT use `--edit-last` or modify existing comments. Always create a NEW comment.

10. **Clean up the Playwright script and assets:**

    Delete the temporary screencast script and screenshots:

    ```
    rm -f e2e-tests/screencast-demo.spec.ts
    rm -rf e2e-tests/screencast-screenshots/
    ```

    Also clean up any test results:

    ```
    rm -rf test-results/screencast-demo*
    ```

11. **Summarize results:**

    Report to the user:
    - Whether the PR was determined to be user-facing or not
    - What feature was demonstrated (if applicable)
    - How many screenshots were captured
    - Link to the PR comment
    - Any issues encountered during recording

Overview

This skill records a visual demonstration of the key feature in a pull request by taking screenshots, uploading them to an assets branch, and posting a new GitHub PR comment with the visual walkthrough. It runs autonomously where possible, builds the app, runs a Playwright screencast script, and reports results. The skill uses the TodoWrite tool to track each step of the workflow.

How this skill works

The skill identifies the target PR (argument or current branch), inspects changed files and labels to decide if the PR is user-facing, and skips non-user-facing PRs with a brief comment. For user-facing PRs it creates a Playwright e2e test that captures 2–4 screenshots showing initial state, user actions, and final result, then builds the app, runs the test (with retries), verifies screenshots, uploads them to an assets branch, and posts a new PR comment. All progress steps must be recorded via TodoWrite and each step transitions from in_progress to completed.

When to use it

  • You want a quick visual proof of a UI feature introduced by a PR
  • The PR contains visible UI changes or user-facing behavior
  • You need reproducible screenshots for reviewers or documentation
  • You prefer an automated, repeatable workflow to create demonstrations

Best practices

  • Only run this skill for PRs that change UI or user-facing behavior; it skips docs/config/test-only PRs
  • Use stable selectors (data-testid, role, visible text) when customizing the Playwright script
  • Add short waits (500–1000ms) between actions to ensure clear screenshots
  • Retry the screencast up to three times on transient failures and capture test logs for troubleshooting
  • Keep temporary screencast files isolated and remove them after uploading assets

Example use cases

  • Demonstrate a new settings panel introduced in a PR with before/after screenshots
  • Show a new form flow or wizard step that requires sequential screenshots
  • Capture and share a UI bug fix by recording the broken state and the corrected result
  • Provide a visual acceptance artifact for a feature when a maintainer requests a demo

FAQ

What if the PR only changes backend code or tests?

The skill will detect non-user-facing changes (docs, config, tests, refactors) and post a short comment explaining the screencast was skipped.

What happens if Playwright fails to capture screenshots?

The skill retries up to three times. If it still fails it posts a PR comment with the error and a fallback textual description of the intended screenshots.

Where are screenshots stored and how are they referenced?

Screenshots are committed to an assets branch under pr-screencasts/pr-<PR_NUMBER>-<timestamp> and referenced via raw.githubusercontent.com links in the PR comment.