Create e2e-re claude skill (#2273)

.claude/commands/e2e-rebase.md

+# E2E Snapshot Rebase
+
+Rebase E2E test snapshots based on failed tests from the PR comments.
+
+## Instructions
+
+1. Get the current PR number using `gh pr view --json number --jq '.number'`
+
+2. Fetch PR comments and look for the Playwright test results comment. Parse out the failed test filenames from either:
+   - The "Failed Tests" section (lines starting with `- \`filename.spec.ts`)
+   - The "Update Snapshot Commands" section (contains `npm run e2e e2e-tests/filename.spec.ts`)
+
+3. If no failed tests are found in the PR comments, inform the user and stop.
+
+4. Run the pre-e2e setup:
+   ```
+   npm run pre:e2e
+   ```
+
+5. For each failed test file, run the e2e test with snapshot update:
+   ```
+   npm run e2e e2e-tests/<testFilename>.spec.ts -- --update-snapshots
+   ```
+
+6. After updating snapshots, re-run the same tests WITHOUT `--update-snapshots` to verify they pass consistently:
+   ```
+   npm run e2e e2e-tests/<testFilename>.spec.ts
+   ```
+   If any test fails on this verification run, inform the user that the snapshots may be flaky and stop.
+
+7. Show the user which snapshots were updated using `git diff` on the snapshot files.
+
+8. Review the snapshot changes to ensure they look reasonable and are consistent with the PR's purpose. Consider:
+   - Do the changes align with what the PR is trying to accomplish?
+   - Are there any unexpected or suspicious changes?
+
+9. If the snapshots look reasonable, commit and push the changes:
+   ```
+   git add e2e-tests/snapshots/
+   git commit -m "Update E2E snapshots"
+   git push
+   ```
+
+10. Inform the user that the snapshots have been updated and pushed to the PR.

.claude/commands/pr-fix.md

+# PR Fix
+
+Address review comments and failing checks on a GitHub Pull Request.
+
+## Arguments
+
+- `$ARGUMENTS`: Optional PR number or URL. If not provided, uses the current branch's PR.
+
+## Instructions
+
+1. **Determine the PR to work on:**
+   - If `$ARGUMENTS` contains a PR number or URL, use that
+   - Otherwise, get the current branch's PR using `gh pr view --json number,url,title,body --jq '.'`
+   - If no PR is found, inform the user and stop
+
+2. **Fetch all PR review comments:**
+   ```
+   gh pr view <PR_NUMBER> --json reviews,comments --jq '.'
+   gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments
+   ```
+
+3. **Analyze the PR comments and identify actionable items:**
+   - Look for code review comments that request changes
+   - Look for general review comments with feedback
+   - Prioritize comments from reviewers that are:
+     - Requesting specific code changes
+     - Pointing out bugs or issues
+     - Suggesting improvements that should be addressed
+   - Ignore comments that are:
+     - Simple acknowledgments or approvals
+     - Questions that have already been answered
+     - Nitpicks explicitly marked as optional
+
+4. **Check for failing CI checks:**
+   ```
+   gh pr checks <PR_NUMBER>
+   ```
+   Note which checks are failing, particularly Playwright/E2E tests.
+
+5. **For each actionable review comment:**
+   - Read the relevant file(s) mentioned in the comment
+   - Understand the context and the requested change
+   - Make the necessary code changes to address the feedback
+   - Keep track of what was changed
+
+6. **If there are failing Playwright/E2E tests:**
+   - Check if the failures are snapshot-related by examining the PR comments for Playwright test results
+   - If snapshots need updating, run the `/e2e-rebase` skill to fix them
+   - If the failures are not snapshot-related, investigate and fix the underlying test issues
+
+7. **After making all changes, verify the fixes:**
+   - Run relevant linters: `npm run lint:fix`
+   - Run type checks if TypeScript files were modified: `npm run typecheck`
+   - Run any relevant unit tests for modified code
+
+8. **Review all changes made:**
+   ```
+   git diff
+   git status
+   ```
+   Ensure the changes are reasonable and address the review feedback appropriately.
+
+9. **Commit and push the changes:**
+   - Stage all modified files
+   - Create a commit with a descriptive message summarizing what was addressed:
+     ```
+     git add -A
+     git commit -m "Address PR review feedback
+
+     - <summary of change 1>
+     - <summary of change 2>
+     ...
+
+     Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
+     git push
+     ```
+
+10. **Provide a summary to the user:**
+    - List the review comments that were addressed
+    - List any failing checks that were fixed
+    - Note any comments that were intentionally not addressed and why
+    - Mention if any issues could not be resolved and require human attention

AGENTS.md

@@ -74,3 +74,11 @@ Use E2E testing when you need to test a complete user flow for a feature.
 If you would need to mock a lot of things to unit test a feature, prefer to write an E2E test instead.
 
 Do NOT write lots of e2e test cases for one feature. Each e2e test case adds a significant amount of overhead, so instead prefer just one or two E2E test cases that each have broad coverage of the feature in question.
+
+## Git workflow
+
+When pushing changes and creating PRs:
+
+1. If the branch already has an associated PR, push to whichever remote the branch is tracking.
+2. If the branch hasn't been pushed before, default to pushing to `origin` (the fork `wwwillchen/dyad`), then create a PR from the fork to the upstream repo (`dyad-sh/dyad`).
+3. If you cannot push to the fork due to permissions, push directly to `upstream` (`dyad-sh/dyad`) as a last resort.