Dev
Maintain the playwright-cli repo with documented roll-and-release workflows when you fork or contribute to Microsoft’s CLI wrapper.
Overview
dev is an agent skill for the Operate phase that walks maintainers through rolling Playwright and cutting patch releases for the playwright-cli repository.
Install
npx skills add https://github.com/microsoft/playwright-cli --skill devWhat is this skill?
- Documents rolling the pinned Playwright dependency and syncing package-lock after patch bumps
- 6-step release flow: version bump → baseline from last chore: mark v commit → alpha window → commit diff from local Play
- Indexes roll.md and release.md as the two primary maintenance playbooks
- Uses grep/git show on prior mark v commits to establish Playwright baseline for changelog scope
- Expects a local ~/code/playwright clone for --after/--before commit listing in the window
- 6-step numbered release preparation flow
- 2 linked playbooks: roll.md and release.md
Adoption & trust: 1.9k installs on skills.sh; 11.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You own or contribute to playwright-cli but lack a repeatable checklist for bumping Playwright and shipping a version-tagged release PR.
Who is it for?
Maintainers of playwright-cli (or a close fork) who already have npm, git, and a local Playwright repo for commit archaeology.
Skip if: Builders who only want to run Playwright tests in their app without touching this CLI package’s release pipeline.
When should I use this skill?
User asks about rolling dependencies, releasing, or other playwright-cli repository maintenance tasks.
What do I get? / Deliverables
You get a version-aligned chore release PR with notes derived from a defined Playwright commit window instead of ad-hoc changelog guesses.
- chore: mark v<version> release PR with release notes body
- Updated package.json patch and synced package-lock.json
Recommended Skills
Journey fit
Repo maintenance and versioned releases sit after the product is live—you iterate the toolchain rather than ship net-new features. Patch bumps, lockfile sync, and chore release PRs are classic iteration loops on an existing OSS artifact.
How it compares
Use instead of generic "bump version and tag" chat advice when the repo’s mark-v chore convention and Playwright alpha windows matter.
Common Questions / FAQ
Who is dev for?
Solo or indie maintainers—and small OSS teams—who ship playwright-cli patches and need Microsoft’s documented roll and release rituals.
When should I use dev?
Use it in Operate when rolling Playwright, preparing chore: mark v releases, or answering other playwright-cli repo maintenance tasks after the tool is already in use.
Is dev safe to install?
Treat it as procedural guidance that implies shell, git, and npm on your machine; review the Security Audits panel on this Prism page before trusting third-party skill packs.
SKILL.md
READMESKILL.md - Dev
# Development skills * **Rolling Playwright dependency** [roll.md](roll.md) * **Preparing Release** [release.md](release.md) # How to prepare a release A release is a `chore: mark v<next-patch>` commit whose PR body is the release notes. Example: https://github.com/microsoft/playwright-cli/pull/367. ## Steps 1. **Bump the patch version** in `package.json` (e.g. `0.1.7` → `0.1.8`), then `npm install` to sync `package-lock.json`. This is the entry point — everything else (branch name, PR title, release notes filename) keys off the new version. 2. **Find the baseline.** The previous release is the last `chore: mark v...` commit on `main`. Read the Playwright version pinned at that commit — that's the baseline for the diff. ```bash git log --oneline | grep "mark v" | head -1 git show <sha>:package.json | grep '"playwright"' ``` 3. **Figure out the playwright commit window.** Convert the baseline's alpha timestamp to a UTC date, and use the new alpha's date as the upper bound. Alphas are either `1.X.0-alpha-<ms-epoch>` or `1.X.0-alpha-<YYYY-MM-DD>`. ```bash date -u -d @<seconds> '+%Y-%m-%d %H:%M:%S UTC' # for ms-epoch, divide by 1000 first ``` 4. **List Playwright commits in the window.** Run from `~/code/playwright` (a local Playwright checkout). `--after` / `--before` work on any ref regardless of what `origin/main` currently points at; `--since` / `--until` can silently return empty if the branch is behind. ```bash cd ~/code/playwright && git log --after='<baseline-date>' --before='<new-date>' --pretty=format:'%h %ci %s' ``` 5. **Filter to CLI-relevant commits.** Keep anything touching the CLI surface or its runtime; drop internal/unrelated churn. - **Keep:** `src/tools/cli-client/**`, `src/tools/cli-daemon/**`, `src/tools/mcp/**`, `remote/playwrightConnection`, CDP-attach paths, tracing/video APIs the CLI exposes, and anything with a `fix(cli)` / `feat(cli)` / `fix(mcp)` / `feat(mcp)` prefix. - **Drop:** test-runner rolls, firefox/chromium/webkit version bumps, docs-only, test infra, unrelated refactors. - Use `git show --stat <sha>` to sanity-check whether a commit's files touch the CLI. 6. **Pull issue context for each kept PR.** The PR's linked issue often has better user-facing wording than the PR/commit title. ```bash gh pr view <pr> --repo microsoft/playwright --json title,body,closingIssuesReferences gh issue view <issue> --repo microsoft/playwright-cli --json title,body,state ``` 7. **Write the release notes** to `RELEASE_NOTES_v<version>.md`. Use this exact shape — **no top-level `#` header**, the PR title is the heading: ```markdown ## Highlights - **<issue wording, not commit wording>** ([#<issue>](https://github.com/microsoft/playwright-cli/issues/<issue>)) — one sentence on the user-facing effect. ([microsoft/playwright#<pr>](https://github.com/microsoft/playwright/pull/<pr>)) ## Fixes - `<commit subject>` — what changed and why it matters. ([#<pr>](https://github.com/microsoft/playwright/pull/<pr>)) ## Upgrading ```bash npm install -g @playwright/cli@<version> ``` ``` Wording rules: - **Highlights lead with the user-reported problem from the linked issue**, not the commit subject. Drop internal terms (`cdpPort`, `tombstones`) from highlight bullets. - Only list things that change user-visible behavior. Skip internal cleanups unless they have a user-facing effect. - Reference both the playwright-cli issue (if any) and the microsoft/playwright PR. 8. **Commit, push, open PR.** The PR body is the contents of the release notes file (no `#` header, no filename). ```bash git checkout -b mark-v<version> git add package.json package-lock.json git commit -m "chore: mark v<version>" git push -u origin mark-v<version