Review Prs

gh pr diff <number>

Step 3: Apply review criteria

Evaluate each PR against the criteria from references/review-criteria.md. Key filters:

• Scope: Is it Playwright-first? Reject generic automation, cross-framework tools, or "AI agent platforms."
• Category fit: Does it land in the right section (Integrations/Utils/Reporters/Guides/Showcases)?
• Quality signals: Stars, downloads, docs quality, active maintenance. Be skeptical of repos with near-zero adoption.
• Neutrality: Strip marketing language. Descriptions should be short and factual.
• Ethics/ToS: Auto-reject CAPTCHA bypassing, stealth/anti-detection, government portal automation with ToS concerns.
• Licensing: Must be publicly accessible. License should be stated.
• Duplication: Is something similar already listed? Only add if clearly better/different.
• Formatting: Alphabetical order, one bullet per entry, correct naming, no tracking links.

Step 4: Generate review document

Produce a document with:

1. Per-PR details including:

   • PR number, title, author
   • What it adds (one sentence)
   • Project stats: stars, license, last activity
   • Verdict: MERGE, CLOSE, or REQUEST CHANGES
   • Reason (one sentence)
   • For CLOSE: a draft closing comment that is friendly but not verbose

2. Summary table at the end: | PR | Title | Recommendation | Reason |

3. Present to the user and explicitly ask for approval or overrides before proceeding to Phase 2.

Phase 2: Actuation

Only proceed after the user explicitly approves the recommendations (they may override some decisions).

Closing PRs

For each PR marked CLOSE:

gh pr close <number> --comment "<friendly closing message>"

Merging PRs

For each PR marked MERGE, use squash merge (this repo disallows merge commits):

gh pr merge <number> --squash

Post-merge verification

After all merges, pull latest and run the CI lint check:

git pull
npx -y awesome-lint 'README.md'

If lint fails, investigate and fix before considering the job done.

Final report

Summarize what was done: how many merged, how many closed, any issues encountered.

Important Guidelines

• Always present findings before acting. Never close or merge without user approval.
• Be strict. A project with 0-2 GitHub stars and no npm downloads is too early-stage, regardless of how nice the README looks.
• Closed-source SaaS products without a public repo or detailed integration docs should generally be rejected.
• Projects not using Playwright (e.g., using CDP directly) do not belong on this list.
• Stealth/anti-detection tools or forks are an automatic reject.
• Use parallel subagents to research PRs efficiently - batch 5-6 PRs per agent.
• Friendly closing comments - always thank the submitter and explain why briefly. Invite them to resubmit if circumstances change.