Audit Entries

If the API returns 404, the repo has been deleted or made private.

For repos that look borderline, also check if the README mentions deprecation:

gh api repos/<owner>/<repo>/readme --jq '.content' | base64 -d | head -20

Step 3: Check non-GitHub links

For entries linking to websites, npm packages, or docs (not GitHub), verify the link is live:

curl -sL -o /dev/null -w '%{http_code}' --max-time 10 "<url>"

A 200 is fine. A 404 or timeout means the link is broken.

For npm packages, also check publish date:

npm view <package-name> time.modified --json 2>/dev/null

Step 4: Apply removal criteria

Consult references/removal-criteria.md and classify each entry:

• KEEP - Healthy, maintained, link works, still relevant
• REMOVE - Meets one or more removal criteria (broken, archived, abandoned, deprecated, pivoted)
• FLAG - Borderline cases that need maintainer judgment (stale but popular, possibly superseded)

Step 5: Generate audit report

Produce a report with:

1. Healthy entries (brief, just confirm they're fine - no need for detail)

2. Entries recommended for removal, each with:

   • Entry name, section, and URL
   • Removal reason with evidence (e.g., "Archived on GitHub since 2024-03", "Last commit 3 years ago, 5 stars", "Returns 404")
   • Successor or alternative if known

3. Flagged entries needing maintainer input, with context

4. Summary table: | Entry | Section | Status | Reason |

Present the report and wait for explicit user approval before making any changes.

Phase 2: Actuation

Only proceed after the user confirms which entries to remove.

Remove entries

Edit README.md to remove the approved entries. Remove the entire bullet line for each entry.

Verify

Run the CI lint check to ensure the list is still valid:

npx -y awesome-lint 'README.md'

If lint fails, investigate and fix (e.g., empty sections, formatting issues).

Report

Summarize: how many entries removed, how many kept, how many flagged for future review.

Important Guidelines

• Never remove without presenting evidence first. Always show the data.
• Language Support entries are special - official Playwright ports rarely need removal. Community ports may go stale but are still valuable if they're the only option for that language.
• Showcases are snapshot-in-time - a showcase project doesn't need to still use Playwright today; it was notable when added. Be lenient here.
• Guides can go stale - blog posts and tutorials may become outdated or links may rot. Check these carefully.
• "Done" is not "dead" - some tools (e.g., selector engines, small plugins) may not need frequent updates. Don't confuse stability with abandonment. Look at issue activity and whether the tool still works with current Playwright versions.
• Use parallel subagents to check entries efficiently - batch 8-10 per agent since these are simpler checks than full PR reviews.