Skip to content
Testing
Skill

/playwright-release-notes

Write the release notes for a Playwright release - the Node.js notes in docs/src/release-notes-js.md together with the Python, Java and .NET translations, and the GitHub markdown for each language's release. Use when asked to write, translate or publish release notes.

GuideBOOST
From plugin
playwright
98k9 skills7 agents
Install
$ npx -y skills add microsoft/playwright --skill playwright-release-notes --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/playwright-release-notes

Context preview

The summary Claude sees to decide when to auto-load this skill.

Write the release notes for a Playwright release - the Node.js notes in docs/src/release-notes-js.md together with the Python, Java and .NET translations, and the GitHub markdown for each language's release. Use when asked to write, translate or publish release notes.

SKILL.md

playwright-release-notes.SKILL.md
name: playwright-release-notes
description: Write the release notes for a Playwright release - the Node.js notes in docs/src/release-notes-js.md together with the Python, Java and .NET translations, and the GitHub markdown for each language's release. Use when asked to write, translate or publish release notes.

Release notes

In this skill, `1.xx` is the release (for example `1.64`).

Every release has a `## Version 1.xx` section in four files in `docs/src/`:

| Language | Notes | Docs base URL | GitHub release in | |---|---|---|---| | Node.js | `release-notes-js.md` | `https://playwright.dev/docs/` | `microsoft/playwright` | | Python | `release-notes-python.md` | `https://playwright.dev/python/docs/` | `microsoft/playwright-python` | | Java | `release-notes-java.md` | `https://playwright.dev/java/docs/` | `microsoft/playwright-java` | | .NET | `release-notes-csharp.md` | `https://playwright.dev/dotnet/docs/` | `microsoft/playwright-dotnet` |

Write the Node.js notes and the three translations in the same PR, so every language has its notes when it starts its release. The language repos then add only their own significant changes, and each one writes its GitHub release from its section (step 3).

1. Node.js notes

In `docs/src/release-notes-js.md`, add a `## Version 1.xx` section above the previous version, and use previous versions as a guide:

  • Highlights come first, each with an emoji heading and a short sample. Ask teammates for help with them.
  • Then `### New APIs` with `####` groups, `### Breaking Changes ⚠️`, `### Announcements` and `### Browser Versions`. Print the browser versions with `node utils/print_versions.js`.
  • Refer to APIs with docs link macros: `` [`method: Page.frameLocator`] ``, `` [`property: Page.webmcp`] ``, `` [`event: Page.dialogClosed`] ``, `` [`option: Tracing.start.ariaSnapshots`] ``, `[Locator]`. Each language's docs show them with that language's names.
  • Link other docs pages with relative paths: `[test locks](./test-parallel.md#test-locks)`.

2. Python, Java and .NET translations

In each of `release-notes-python.md`, `release-notes-java.md` and `release-notes-csharp.md`, add a `## Version 1.xx` section above the previous version. Translate it from the Node.js section. Compare the `Version 1.63` sections of the files to see what past translations dropped and changed.

For every language:

  • Keep the structure: highlights with emoji headings, `### New APIs` with `####` groups, `### Breaking Changes ⚠️`, `### Announcements` and `### Browser Versions`.
  • Remove what the language does not have:
  • the test runner: `@playwright/test`, `test.*`, config, fixtures, projects, reporters and `npx playwright test` options
  • UI mode, the HTML report, component testing and the VS Code extension
  • TypeScript-only features (generics, JSX, `tsconfig`) and `devices` descriptors
  • every API whose `langs` excludes the language (`python`, `java`, `csharp`). Check `langs` in `docs/src/api/`; options shared between methods are defined in `docs/src/api/params.md`.
  • Use the language's API where it differs from Node.js:
  • A language-specific option has its own `langs`. For example, `recordVideoFps` is `langs: csharp, java, python`, while Node.js has `recordVideo.fps`.
  • `alias-<lang>` renames a member, e.g. `alias-java: isVisible` for `LocatorAssertions.toBeVisible`.
  • The generated APIs in sibling checkouts confirm the names: `../playwright-python/playwright/sync_api/_generated.py`, `../playwright-java/playwright/src/main/java/com/microsoft/playwright/` and `../playwright-dotnet/src/Playwright/API/Generated/`.
  • When a Node.js sample shows a library feature through `playwright.config.ts`, show the API call instead. For example, the 1.64 video config became calls to `Screencast.start` and `Screencast.showActions`.
  • Keep API links as docs link macros, and link the language's own option where it differs (`` [`option: Browser.newContext.recordVideoFps`] ``). In plain text, use the language's names.
  • A relative link must point to a page that exists in the language: `*-js.md` pages are Node.js only. `npm run doc` reports broken links for each language.
  • Do not add changes that only a language port made. The language repo adds those to its notes.

Rewrite code samples in each language's style. The `infra` workflow checks the syntax of `python`, `java` and `csharp` snippets.

Python

  • Use the sync API: `page.get_by_role("button").click()`. Use snake_case names and Python values (`True`, `False`, `None`).
  • Options become keyword arguments: `page.get_by_role("button", name="Save")`. Objects and arrays become dicts and lists: `size={"width": 1920, "height": 1080}`.
  • Aria roles and other string values stay strings: `"button"`, `"ai"`.
  • Events: `page.on("dialogclosed", handler)`. Assertions: `expect(locator).to_have_text([...])`. Print with `print(...)`.
  • Use the `alias-python` names: `route.continue_()`, `locator.or_()`, `page.expect_request()`.
  • Commands: write `playwright install`, not `npx playwright install`.

Java

| Node.js | Java | |---|---| | `await page.goto('...')` | `page.navigate("...");`: no `await`, double quotes, semicolons, typed locals (`Locator dialog = ...`) | | `page.getByRole('button', { name: 'Save' })` | `page.getByRole(AriaRole.BUTTON, new Page.GetByRoleOptions().setName("Save"))` | | options object `{ path: 'video.webm', fps: 60 }` | options builder `new Screencast.StartOptions().setPath(Paths.get("video.webm")).setFps(60)` | | object literal `{ name: 'session-id', value: '42', url }` | value class `new Cookie("session-id", "42").setUrl(url)` | | `['a', 'b']`, `{ a: 2 }` | `Arrays.asList("a", "b")`, `Map.of("a", 2)`; `new String[] {"a", "b"}` for assertion arguments | | property `page.webmcp`, `context.tracing` | getter `page.webmcp()`, `context.tracing()` | | event `page.on('dialogclosed', handler)` | `page.onDialogClosed(handler)` | | `expect(locator).toHaveText(...)` | `assertThat(locator).hasText(...)`. Likewise `

Read more
Ships withplaywright

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.

Get the whole plugin

Other skills on playwright.