Awesome Web Agents PR Review
Overview
Review PRs in this repository by applying the local policy and checking the changed files. Treat CONTRIBUTING.md as the source of truth for acceptance criteria.
Read First
CONTRIBUTING.mdREADME.mdARCHIVE.md when the change might belong in the archivescripts/validate_contribution.py when you need structural validation details
Do not restate repo policy from memory when those files are available. Quote or summarize the repository's own rules instead.
Workflow
1. Inspect the PR
Use gh first:
gh pr view <number> --repo steel-dev/awesome-web-agents --json title,number,state,isDraft,author,baseRefName,headRefName,files,additions,deletions,mergeable,mergeStateStatus,labels,url,bodygh pr diff <number> --repo steel-dev/awesome-web-agents --patchgh pr checks <number> --repo steel-dev/awesome-web-agents
If you need the exact branch locally, fetch it with:
git fetch origin refs/pull/<number>/head:pr-<number>
2. Apply local policy
Use CONTRIBUTING.md for the actual acceptance rubric. Use README.md and ARCHIVE.md only to judge section fit, duplicates, and whether a project belongs in the main list or archive.
3. Run structural validation when useful
When reviewing a local branch or checking CI behavior, run:
python3 scripts/validate_contribution.py
Treat the script as a structural check, not the decision-maker. Human review still decides repository fit.
4. Produce the review
Use a code-review mindset:
- Present findings first, ordered by severity, with file references when applicable.
- If there are no findings, say that explicitly.
- After findings, give one clear decision:
Accept, Request changes, or Close.
- Separate policy fit from technical mergeability. A PR can be mergeable in GitHub and still fail repository scope.
Output Shape
Keep the final review compact:
- one sentence on PR state or scope if useful
- findings first
- verdict second
- short rationale last
1---2name: awesome-web-agents-pr-review3description: Review pull requests for the awesome-web-agents repository. Use when asked to validate a PR, assess whether a submission fits the repo, inspect README or ARCHIVE additions, check merge readiness, or apply the repository's web-agent-first contribution policy to a GitHub pull request.4---56# Awesome Web Agents PR Review78## Overview910Review PRs in this repository by applying the local policy and checking the changed files. Treat `CONTRIBUTING.md` as the source of truth for acceptance criteria.1112## Read First1314- `CONTRIBUTING.md`15- `README.md`16- `ARCHIVE.md` when the change might belong in the archive17- `scripts/validate_contribution.py` when you need structural validation details1819Do not restate repo policy from memory when those files are available. Quote or summarize the repository's own rules instead.2021## Workflow2223### 1. Inspect the PR2425Use `gh` first:2627- `gh pr view <number> --repo steel-dev/awesome-web-agents --json title,number,state,isDraft,author,baseRefName,headRefName,files,additions,deletions,mergeable,mergeStateStatus,labels,url,body`28- `gh pr diff <number> --repo steel-dev/awesome-web-agents --patch`29- `gh pr checks <number> --repo steel-dev/awesome-web-agents`3031If you need the exact branch locally, fetch it with:3233- `git fetch origin refs/pull/<number>/head:pr-<number>`3435### 2. Apply local policy3637Use `CONTRIBUTING.md` for the actual acceptance rubric. Use `README.md` and `ARCHIVE.md` only to judge section fit, duplicates, and whether a project belongs in the main list or archive.3839### 3. Run structural validation when useful4041When reviewing a local branch or checking CI behavior, run:4243- `python3 scripts/validate_contribution.py`4445Treat the script as a structural check, not the decision-maker. Human review still decides repository fit.4647### 4. Produce the review4849Use a code-review mindset:5051- Present findings first, ordered by severity, with file references when applicable.52- If there are no findings, say that explicitly.53- After findings, give one clear decision: `Accept`, `Request changes`, or `Close`.54- Separate policy fit from technical mergeability. A PR can be mergeable in GitHub and still fail repository scope.5556## Output Shape5758Keep the final review compact:5960- one sentence on PR state or scope if useful61- findings first62- verdict second63- short rationale last
steel-dev