{"owner":"microsoft","repo":"playwright-mcp","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":2045,"categories":["anthropic-skill","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".claude/skills/release.md","CLAUDE.md"],"skills":{".claude/skills/release.md":"---\nname: release\ndescription: Prepare a playwright-mcp release — roll Playwright, bump the version, and open a `chore: mark v0.0.` PR whose body IS the release notes (changes from this repo and upstream microsoft/playwright since the last release).\n---\n\n# Preparing a Release\n\nA release is a `chore: mark v0.0.` commit whose **PR body is the release notes**. There is a single PR — the version bump and the notes ship together. Most MCP source lives upstream at `~/playwright/packages/playwright-core/src/tools/` (and `tests/mcp/`), so the notes draw from both this repo and upstream.\n\n## 1. Roll Playwright\n\nFollow the \"Rolling Playwright\" steps in `CLAUDE.md`: run `node roll.js`, branch as `roll-pw-`, run `npm test`, and open a `chore: roll Playwright to ` PR. **Wait for it to merge into `main`** before proceeding.\n\n## 2. Bump the version\n\n```bash\ngit checkout main && git pull\ngit checkout -b mark-v0.0.\n# Bump \"version\" in package.json, package-lock.json (both occurrences), and server.json (both occurrences)\n```\n\nDo NOT open the PR yet — its body must be the release notes, so write those first (steps 3–5).\n\n## 3. Find the exact commit window\n\nThe reliable boundary is the **`gitHead` of each published alpha build**, not a fuzzy date window (date windows double-count commits that land on the boundary day — e.g. a commit written on the previous release's build date but not actually in that build).\n\n```bash\n# Playwright version pinned by the previous release (last \"mark v\" commit) and by this release\ngit log --oneline | grep \"mark v\" | head -1\ngit show :package.json | grep '\"playwright\":' # baseline alpha\ngrep '\"playwright\":' package.json # new alpha (already rolled)\n\n# Resolve each alpha to the exact upstream commit it was built from\nnpm view playwright-core@ gitHead # e.g. -> 287ad476...\nnpm view playwright-core@ gitHead # e.g. -> a061d963...\n```\n\nThe window is `..`.\n\n## 4. Collect changes\n\n```bash\n# Upstream playwright — MCP code path widened to catch tools/extension/dashboard too\ncd ~/playwright\ngit log .. --reverse --pretty='%h %s' -- \\\n packages/playwright-core/src/tools/ packages/playwright-core/src/extension/ tests/mcp/\n\n# This repo\ncd -\ngit log ..HEAD --oneline\n```\n\nFilter for `feat(mcp)`, `fix(mcp)`, `feat(extension)`, `fix(extension)`, `feat(aria)` snapshot changes, and dashboard changes. Many extension PRs land in *both* repos because the extension source lives upstream now — prefer the `microsoft/playwright` PR link. Use `git show --stat` to disambiguate ambiguous subjects.\n\n**Drop:** test-only changes, docs, `chore(deps)`, CLI-daemon internals with no MCP-facing effect, reverted commits, and anything not user-visible. **Verify membership** of boundary commits with `git merge-base --is-ancestor ` — a commit can be listed in the previous release's notes yet not actually be in that build; if it was already announced, do not repeat it.\n\n## 5. Write `release-notes.md`\n\nFollow the format from the prior release (`gh pr view --repo microsoft/playwright-mcp --json body -q .body`; v0.0.82, [#1764](https://github.com/microsoft/playwright-mcp/pull/1764), is the reference). **No top-level `#` header** — the PR title is the heading. Three sections:\n\n````markdown\n## ✨ Highlights\n\n- ** Short headline** ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)) — . . ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 🐛 Fixes\n\n- `` — ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)). ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 📦 Upgrading\n\nConfigs that use `@playwright/mcp@latest` pick this release up on the next client restart. To pin it:\n\n```bash\nnpx @playwright/mcp@0.0.\n```\n````\n\n- **Highlights** — one bullet per feature, most exciting first, each with its own emoji. Lead with the motivation (the linked issue, when there is one; omit the issue link otherwise), then what is new. New tools, tool improvements, options, extension and dashboard changes all go here. Fold follow-up PRs into the feature they extend (e.g. a `browser_find` enhancement joins the `browser_find` bullet).\n- **Fixes** — start with the commit subject in backticks, then say what changes for the user. Reword the subject when it does not match what landed.\n- Link PRs as `[microsoft/playwright#NNNNN](https://github.com/microsoft/playwright/pull/NNNNN)`, or `[#NNNN](https://github.com/microsoft/playwright-mcp/pull/NNNN)` for this repo.\n\nWording rules:\n- Only list things that change user-visible behavior.\n- **Describe what landed, not what the PR description says** — read the diff (`git show `). Descriptions go stale during review: parts get dropped, behavior changes (e.g. \"ignores\" became \"returns an error\").\n- **Do not mention features that are not enabled by default** — confirm with the user before listing experimental flags. A fix to an opt-in tool can be listed when annotated, e.g. `browser_route` (opt-in via `--caps=network`).\n- When a release removes or replaces something announced earlier, say so in the bullet of the feature that replaces it.\n\n## 6. Commit, push, open the PR with the notes as its body\n\n```bash\ngit commit -am \"chore: mark v0.0.\"\ngit push -u origin mark-v0.0.\ngh pr create --repo microsoft/playwright-mcp --head :mark-v0.0. \\\n --base main \\\n --title \"chore: mark v0.0.\" \\\n --body-file release-notes.md\n```\n\nThe PR body is the release notes verbatim — no `#` header, no filename, nothing else.\n\n## Pitfalls\n\n- **Don't open the version-bump PR with a placeholder body** and backfill later — write the notes first so the PR is created with them.\n- **Don't use a date window** for the upstream diff — use the `gitHead` range. Dates double-count boundary-day commits.\n- **Don't re-announce** a commit that already appeared in the previous release's notes; check ancestry with `git merge-base --is-ancestor`.\n- **Don't include a `#` header** in the PR body — GitHub renders the PR title already.\n","CLAUDE.md":"## Commit Convention\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add \ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n --body \"$(cat <<'EOF'\n## Summary\n- \n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add Co-Authored-By agents in commit message.\nBranch naming for issue fixes: `fix-`\n\n## Rolling Playwright\n\n1. Run `node roll.js` (or `npm run roll`) to bump `playwright`, `playwright-core`, and `@playwright/test`, refresh `config.d.ts`, and regenerate the README. The script prints the resolved version — use its suffix for the branch name.\n2. Create a branch: `git checkout -b roll-pw-`.\n3. Run `npm test`. Only proceed if all tests pass.\n4. Commit with `chore: roll Playwright to `, push, and open a PR against `microsoft/playwright-mcp` with the same title.\n\n## Preparing a Release\n\nSee [.claude/skills/release.md](.claude/skills/release.md).\n"},"files":{".claude/skills/release.md":"---\nname: release\ndescription: Prepare a playwright-mcp release — roll Playwright, bump the version, and open a `chore: mark v0.0.` PR whose body IS the release notes (changes from this repo and upstream microsoft/playwright since the last release).\n---\n\n# Preparing a Release\n\nA release is a `chore: mark v0.0.` commit whose **PR body is the release notes**. There is a single PR — the version bump and the notes ship together. Most MCP source lives upstream at `~/playwright/packages/playwright-core/src/tools/` (and `tests/mcp/`), so the notes draw from both this repo and upstream.\n\n## 1. Roll Playwright\n\nFollow the \"Rolling Playwright\" steps in `CLAUDE.md`: run `node roll.js`, branch as `roll-pw-`, run `npm test`, and open a `chore: roll Playwright to ` PR. **Wait for it to merge into `main`** before proceeding.\n\n## 2. Bump the version\n\n```bash\ngit checkout main && git pull\ngit checkout -b mark-v0.0.\n# Bump \"version\" in package.json, package-lock.json (both occurrences), and server.json (both occurrences)\n```\n\nDo NOT open the PR yet — its body must be the release notes, so write those first (steps 3–5).\n\n## 3. Find the exact commit window\n\nThe reliable boundary is the **`gitHead` of each published alpha build**, not a fuzzy date window (date windows double-count commits that land on the boundary day — e.g. a commit written on the previous release's build date but not actually in that build).\n\n```bash\n# Playwright version pinned by the previous release (last \"mark v\" commit) and by this release\ngit log --oneline | grep \"mark v\" | head -1\ngit show :package.json | grep '\"playwright\":' # baseline alpha\ngrep '\"playwright\":' package.json # new alpha (already rolled)\n\n# Resolve each alpha to the exact upstream commit it was built from\nnpm view playwright-core@ gitHead # e.g. -> 287ad476...\nnpm view playwright-core@ gitHead # e.g. -> a061d963...\n```\n\nThe window is `..`.\n\n## 4. Collect changes\n\n```bash\n# Upstream playwright — MCP code path widened to catch tools/extension/dashboard too\ncd ~/playwright\ngit log .. --reverse --pretty='%h %s' -- \\\n packages/playwright-core/src/tools/ packages/playwright-core/src/extension/ tests/mcp/\n\n# This repo\ncd -\ngit log ..HEAD --oneline\n```\n\nFilter for `feat(mcp)`, `fix(mcp)`, `feat(extension)`, `fix(extension)`, `feat(aria)` snapshot changes, and dashboard changes. Many extension PRs land in *both* repos because the extension source lives upstream now — prefer the `microsoft/playwright` PR link. Use `git show --stat` to disambiguate ambiguous subjects.\n\n**Drop:** test-only changes, docs, `chore(deps)`, CLI-daemon internals with no MCP-facing effect, reverted commits, and anything not user-visible. **Verify membership** of boundary commits with `git merge-base --is-ancestor ` — a commit can be listed in the previous release's notes yet not actually be in that build; if it was already announced, do not repeat it.\n\n## 5. Write `release-notes.md`\n\nFollow the format from the prior release (`gh pr view --repo microsoft/playwright-mcp --json body -q .body`; v0.0.82, [#1764](https://github.com/microsoft/playwright-mcp/pull/1764), is the reference). **No top-level `#` header** — the PR title is the heading. Three sections:\n\n````markdown\n## ✨ Highlights\n\n- ** Short headline** ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)) — . . ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 🐛 Fixes\n\n- `` — ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)). ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 📦 Upgrading\n\nConfigs that use `@playwright/mcp@latest` pick this release up on the next client restart. To pin it:\n\n```bash\nnpx @playwright/mcp@0.0.\n```\n````\n\n- **Highlights** — one bullet per feature, most exciting first, each with its own emoji. Lead with the motivation (the linked issue, when there is one; omit the issue link otherwise), then what is new. New tools, tool improvements, options, extension and dashboard changes all go here. Fold follow-up PRs into the feature they extend (e.g. a `browser_find` enhancement joins the `browser_find` bullet).\n- **Fixes** — start with the commit subject in backticks, then say what changes for the user. Reword the subject when it does not match what landed.\n- Link PRs as `[microsoft/playwright#NNNNN](https://github.com/microsoft/playwright/pull/NNNNN)`, or `[#NNNN](https://github.com/microsoft/playwright-mcp/pull/NNNN)` for this repo.\n\nWording rules:\n- Only list things that change user-visible behavior.\n- **Describe what landed, not what the PR description says** — read the diff (`git show `). Descriptions go stale during review: parts get dropped, behavior changes (e.g. \"ignores\" became \"returns an error\").\n- **Do not mention features that are not enabled by default** — confirm with the user before listing experimental flags. A fix to an opt-in tool can be listed when annotated, e.g. `browser_route` (opt-in via `--caps=network`).\n- When a release removes or replaces something announced earlier, say so in the bullet of the feature that replaces it.\n\n## 6. Commit, push, open the PR with the notes as its body\n\n```bash\ngit commit -am \"chore: mark v0.0.\"\ngit push -u origin mark-v0.0.\ngh pr create --repo microsoft/playwright-mcp --head :mark-v0.0. \\\n --base main \\\n --title \"chore: mark v0.0.\" \\\n --body-file release-notes.md\n```\n\nThe PR body is the release notes verbatim — no `#` header, no filename, nothing else.\n\n## Pitfalls\n\n- **Don't open the version-bump PR with a placeholder body** and backfill later — write the notes first so the PR is created with them.\n- **Don't use a date window** for the upstream diff — use the `gitHead` range. Dates double-count boundary-day commits.\n- **Don't re-announce** a commit that already appeared in the previous release's notes; check ancestry with `git merge-base --is-ancestor`.\n- **Don't include a `#` header** in the PR body — GitHub renders the PR title already.\n","CLAUDE.md":"## Commit Convention\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add \ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n --body \"$(cat <<'EOF'\n## Summary\n- \n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add Co-Authored-By agents in commit message.\nBranch naming for issue fixes: `fix-`\n\n## Rolling Playwright\n\n1. Run `node roll.js` (or `npm run roll`) to bump `playwright`, `playwright-core`, and `@playwright/test`, refresh `config.d.ts`, and regenerate the README. The script prints the resolved version — use its suffix for the branch name.\n2. Create a branch: `git checkout -b roll-pw-`.\n3. Run `npm test`. Only proceed if all tests pass.\n4. Commit with `chore: roll Playwright to `, push, and open a PR against `microsoft/playwright-mcp` with the same title.\n\n## Preparing a Release\n\nSee [.claude/skills/release.md](.claude/skills/release.md).\n"},"items":[{"name":"release.md","path":".claude/skills/release.md","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright-mcp/HEAD/.claude/skills/release.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"---\nname: release\ndescription: Prepare a playwright-mcp release — roll Playwright, bump the version, and open a `chore: mark v0.0.` PR whose body IS the release notes (changes from this repo and upstream microsoft/playwright since the last release).\n---\n\n# Preparing a Release\n\nA release is a `chore: mark v0.0.` commit whose **PR body is the release notes**. There is a single PR — the version bump and the notes ship together. Most MCP source lives upstream at `~/playwright/packages/playwright-core/src/tools/` (and `tests/mcp/`), so the notes draw from both this repo and upstream.\n\n## 1. Roll Playwright\n\nFollow the \"Rolling Playwright\" steps in `CLAUDE.md`: run `node roll.js`, branch as `roll-pw-`, run `npm test`, and open a `chore: roll Playwright to ` PR. **Wait for it to merge into `main`** before proceeding.\n\n## 2. Bump the version\n\n```bash\ngit checkout main && git pull\ngit checkout -b mark-v0.0.\n# Bump \"version\" in package.json, package-lock.json (both occurrences), and server.json (both occurrences)\n```\n\nDo NOT open the PR yet — its body must be the release notes, so write those first (steps 3–5).\n\n## 3. Find the exact commit window\n\nThe reliable boundary is the **`gitHead` of each published alpha build**, not a fuzzy date window (date windows double-count commits that land on the boundary day — e.g. a commit written on the previous release's build date but not actually in that build).\n\n```bash\n# Playwright version pinned by the previous release (last \"mark v\" commit) and by this release\ngit log --oneline | grep \"mark v\" | head -1\ngit show :package.json | grep '\"playwright\":' # baseline alpha\ngrep '\"playwright\":' package.json # new alpha (already rolled)\n\n# Resolve each alpha to the exact upstream commit it was built from\nnpm view playwright-core@ gitHead # e.g. -> 287ad476...\nnpm view playwright-core@ gitHead # e.g. -> a061d963...\n```\n\nThe window is `..`.\n\n## 4. Collect changes\n\n```bash\n# Upstream playwright — MCP code path widened to catch tools/extension/dashboard too\ncd ~/playwright\ngit log .. --reverse --pretty='%h %s' -- \\\n packages/playwright-core/src/tools/ packages/playwright-core/src/extension/ tests/mcp/\n\n# This repo\ncd -\ngit log ..HEAD --oneline\n```\n\nFilter for `feat(mcp)`, `fix(mcp)`, `feat(extension)`, `fix(extension)`, `feat(aria)` snapshot changes, and dashboard changes. Many extension PRs land in *both* repos because the extension source lives upstream now — prefer the `microsoft/playwright` PR link. Use `git show --stat` to disambiguate ambiguous subjects.\n\n**Drop:** test-only changes, docs, `chore(deps)`, CLI-daemon internals with no MCP-facing effect, reverted commits, and anything not user-visible. **Verify membership** of boundary commits with `git merge-base --is-ancestor ` — a commit can be listed in the previous release's notes yet not actually be in that build; if it was already announced, do not repeat it.\n\n## 5. Write `release-notes.md`\n\nFollow the format from the prior release (`gh pr view --repo microsoft/playwright-mcp --json body -q .body`; v0.0.82, [#1764](https://github.com/microsoft/playwright-mcp/pull/1764), is the reference). **No top-level `#` header** — the PR title is the heading. Three sections:\n\n````markdown\n## ✨ Highlights\n\n- ** Short headline** ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)) — . . ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 🐛 Fixes\n\n- `` — ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)). ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 📦 Upgrading\n\nConfigs that use `@playwright/mcp@latest` pick this release up on the next client restart. To pin it:\n\n```bash\nnpx @playwright/mcp@0.0.\n```\n````\n\n- **Highlights** — one bullet per feature, most exciting first, each with its own emoji. Lead with the motivation (the linked issue, when there is one; omit the issue link otherwise), then what is new. New tools, tool improvements, options, extension and dashboard changes all go here. Fold follow-up PRs into the feature they extend (e.g. a `browser_find` enhancement joins the `browser_find` bullet).\n- **Fixes** — start with the commit subject in backticks, then say what changes for the user. Reword the subject when it does not match what landed.\n- Link PRs as `[microsoft/playwright#NNNNN](https://github.com/microsoft/playwright/pull/NNNNN)`, or `[#NNNN](https://github.com/microsoft/playwright-mcp/pull/NNNN)` for this repo.\n\nWording rules:\n- Only list things that change user-visible behavior.\n- **Describe what landed, not what the PR description says** — read the diff (`git show `). Descriptions go stale during review: parts get dropped, behavior changes (e.g. \"ignores\" became \"returns an error\").\n- **Do not mention features that are not enabled by default** — confirm with the user before listing experimental flags. A fix to an opt-in tool can be listed when annotated, e.g. `browser_route` (opt-in via `--caps=network`).\n- When a release removes or replaces something announced earlier, say so in the bullet of the feature that replaces it.\n\n## 6. Commit, push, open the PR with the notes as its body\n\n```bash\ngit commit -am \"chore: mark v0.0.\"\ngit push -u origin mark-v0.0.\ngh pr create --repo microsoft/playwright-mcp --head :mark-v0.0. \\\n --base main \\\n --title \"chore: mark v0.0.\" \\\n --body-file release-notes.md\n```\n\nThe PR body is the release notes verbatim — no `#` header, no filename, nothing else.\n\n## Pitfalls\n\n- **Don't open the version-bump PR with a placeholder body** and backfill later — write the notes first so the PR is created with them.\n- **Don't use a date window** for the upstream diff — use the `gitHead` range. Dates double-count boundary-day commits.\n- **Don't re-announce** a commit that already appeared in the previous release's notes; check ancestry with `git merge-base --is-ancestor`.\n- **Don't include a `#` header** in the PR body — GitHub renders the PR title already.\n","isInternal":false,"tokens":1683,"sizeBytes":6534},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright-mcp/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"## Commit Convention\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add \ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n --body \"$(cat <<'EOF'\n## Summary\n- \n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add Co-Authored-By agents in commit message.\nBranch naming for issue fixes: `fix-`\n\n## Rolling Playwright\n\n1. Run `node roll.js` (or `npm run roll`) to bump `playwright`, `playwright-core`, and `@playwright/test`, refresh `config.d.ts`, and regenerate the README. The script prints the resolved version — use its suffix for the branch name.\n2. Create a branch: `git checkout -b roll-pw-`.\n3. Run `npm test`. Only proceed if all tests pass.\n4. Commit with `chore: roll Playwright to `, push, and open a PR against `microsoft/playwright-mcp` with the same title.\n\n## Preparing a Release\n\nSee [.claude/skills/release.md](.claude/skills/release.md).\n","isInternal":false,"tokens":362,"sizeBytes":1352}],"systemPromptSnippet":"\n\n---\nname: release\ndescription: Prepare a playwright-mcp release — roll Playwright, bump the version, and open a `chore: mark v0.0.` PR whose body IS the release notes (changes from this repo and upstream microsoft/playwright since the last release).\n---\n\n# Preparing a Release\n\nA release is a `chore: mark v0.0.` commit whose **PR body is the release notes**. There is a single PR — the version bump and the notes ship together. Most MCP source lives upstream at `~/playwright/packages/playwright-core/src/tools/` (and `tests/mcp/`), so the notes draw from both this repo and upstream.\n\n## 1. Roll Playwright\n\nFollow the \"Rolling Playwright\" steps in `CLAUDE.md`: run `node roll.js`, branch as `roll-pw-`, run `npm test`, and open a `chore: roll Playwright to ` PR. **Wait for it to merge into `main`** before proceeding.\n\n## 2. Bump the version\n\n```bash\ngit checkout main && git pull\ngit checkout -b mark-v0.0.\n# Bump \"version\" in package.json, package-lock.json (both occurrences), and server.json (both occurrences)\n```\n\nDo NOT open the PR yet — its body must be the release notes, so write those first (steps 3–5).\n\n## 3. Find the exact commit window\n\nThe reliable boundary is the **`gitHead` of each published alpha build**, not a fuzzy date window (date windows double-count commits that land on the boundary day — e.g. a commit written on the previous release's build date but not actually in that build).\n\n```bash\n# Playwright version pinned by the previous release (last \"mark v\" commit) and by this release\ngit log --oneline | grep \"mark v\" | head -1\ngit show :package.json | grep '\"playwright\":' # baseline alpha\ngrep '\"playwright\":' package.json # new alpha (already rolled)\n\n# Resolve each alpha to the exact upstream commit it was built from\nnpm view playwright-core@ gitHead # e.g. -> 287ad476...\nnpm view playwright-core@ gitHead # e.g. -> a061d963...\n```\n\nThe window is `..`.\n\n## 4. Collect changes\n\n```bash\n# Upstream playwright — MCP code path widened to catch tools/extension/dashboard too\ncd ~/playwright\ngit log .. --reverse --pretty='%h %s' -- \\\n packages/playwright-core/src/tools/ packages/playwright-core/src/extension/ tests/mcp/\n\n# This repo\ncd -\ngit log ..HEAD --oneline\n```\n\nFilter for `feat(mcp)`, `fix(mcp)`, `feat(extension)`, `fix(extension)`, `feat(aria)` snapshot changes, and dashboard changes. Many extension PRs land in *both* repos because the extension source lives upstream now — prefer the `microsoft/playwright` PR link. Use `git show --stat` to disambiguate ambiguous subjects.\n\n**Drop:** test-only changes, docs, `chore(deps)`, CLI-daemon internals with no MCP-facing effect, reverted commits, and anything not user-visible. **Verify membership** of boundary commits with `git merge-base --is-ancestor ` — a commit can be listed in the previous release's notes yet not actually be in that build; if it was already announced, do not repeat it.\n\n## 5. Write `release-notes.md`\n\nFollow the format from the prior release (`gh pr view --repo microsoft/playwright-mcp --json body -q .body`; v0.0.82, [#1764](https://github.com/microsoft/playwright-mcp/pull/1764), is the reference). **No top-level `#` header** — the PR title is the heading. Three sections:\n\n````markdown\n## ✨ Highlights\n\n- ** Short headline** ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)) — . . ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 🐛 Fixes\n\n- `` — ([microsoft/playwright#](https://github.com/microsoft/playwright/issues/)). ([microsoft/playwright#](https://github.com/microsoft/playwright/pull/))\n\n## 📦 Upgrading\n\nConfigs that use `@playwright/mcp@latest` pick this release up on the next client restart. To pin it:\n\n```bash\nnpx @playwright/mcp@0.0.\n```\n````\n\n- **Highlights** — one bullet per feature, most exciting first, each with its own emoji. Lead with the motivation (the linked issue, when there is one; omit the issue link otherwise), then what is new. New tools, tool improvements, options, extension and dashboard changes all go here. Fold follow-up PRs into the feature they extend (e.g. a `browser_find` enhancement joins the `browser_find` bullet).\n- **Fixes** — start with the commit subject in backticks, then say what changes for the user. Reword the subject when it does not match what landed.\n- Link PRs as `[microsoft/playwright#NNNNN](https://github.com/microsoft/playwright/pull/NNNNN)`, or `[#NNNN](https://github.com/microsoft/playwright-mcp/pull/NNNN)` for this repo.\n\nWording rules:\n- Only list things that change user-visible behavior.\n- **Describe what landed, not what the PR description says** — read the diff (`git show `). Descriptions go stale during review: parts get dropped, behavior changes (e.g. \"ignores\" became \"returns an error\").\n- **Do not mention features that are not enabled by default** — confirm with the user before listing experimental flags. A fix to an opt-in tool can be listed when annotated, e.g. `browser_route` (opt-in via `--caps=network`).\n- When a release removes or replaces something announced earlier, say so in the bullet of the feature that replaces it.\n\n## 6. Commit, push, open the PR with the notes as its body\n\n```bash\ngit commit -am \"chore: mark v0.0.\"\ngit push -u origin mark-v0.0.\ngh pr create --repo microsoft/playwright-mcp --head :mark-v0.0. \\\n --base main \\\n --title \"chore: mark v0.0.\" \\\n --body-file release-notes.md\n```\n\nThe PR body is the release notes verbatim — no `#` header, no filename, nothing else.\n\n## Pitfalls\n\n- **Don't open the version-bump PR with a placeholder body** and backfill later — write the notes first so the PR is created with them.\n- **Don't use a date window** for the upstream diff — use the `gitHead` range. Dates double-count boundary-day commits.\n- **Don't re-announce** a commit that already appeared in the previous release's notes; check ancestry with `git merge-base --is-ancestor`.\n- **Don't include a `#` header** in the PR body — GitHub renders the PR title already.\n\n\n## Commit Convention\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add \ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n --body \"$(cat <<'EOF'\n## Summary\n- \n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add Co-Authored-By agents in commit message.\nBranch naming for issue fixes: `fix-`\n\n## Rolling Playwright\n\n1. Run `node roll.js` (or `npm run roll`) to bump `playwright`, `playwright-core`, and `@playwright/test`, refresh `config.d.ts`, and regenerate the README. The script prints the resolved version — use its suffix for the branch name.\n2. Create a branch: `git checkout -b roll-pw-`.\n3. Run `npm test`. Only proceed if all tests pass.\n4. Commit with `chore: roll Playwright to `, push, and open a PR against `microsoft/playwright-mcp` with the same title.\n\n## Preparing a Release\n\nSee [.claude/skills/release.md](.claude/skills/release.md).\n"}