菜单
Rigorous checklist for triaging PRs on the awesome-real-estate list. Use whenever asked to review, process, triage, or vet open pull requests on this repo — an HTTP 200 on the submitted link is not sufficient by itself.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/etewiah/awesome-real-estate --skill vet-pr命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | vet-pr |
| description | Rigorous checklist for triaging PRs on the awesome-real-estate list. Use whenever asked to review, process, triage, or vet open pull requests on this repo — an HTTP 200 on the submitted link is not sufficient by itself. |
This is a community "awesome list." The barrier to entry is low (anyone can open a PR adding one line), which means the volume of low-effort, AI-generated, or spam/SEO submissions is high. A link returning HTTP 200 is the weakest signal, not the deciding one — treat it as necessary, never sufficient.
For every PR, in this order, run ALL of the following checks — do not skip the author check because the link looks fine, and do not skip the content check because the author looks fine. A single passing check does not offset a failing one.
curl -sIL the URL — non-200/3xx final status, parked-domain redirect, or a bare "coming soon" page is an automatic fail.<title> matches the PR's claim is not enough — the homepage is marketing copy; the listing page is where mass-generated content shows itself.curl cannot see JS-rendered content. Many sites are client-rendered SPAs — curl returns a near-empty shell (a bare "Redirecting...", or a <body> that's almost all <script> tags with a few hundred characters of real text once stripped). If stripping tags/scripts from the curl body yields little to no real text, that is NOT evidence the content is fine — it means the check wasn't actually performed. Do not write "title matches claim" as if that settles it when the body is a JS shell. In that case, either (a) render the page with the mcp__claude-in-chrome__* browser tools (navigate + get_page_text — load them via ToolSearch if not already available) and read the real text, or (b) if browser tools aren't practical in this run (e.g. parallel forks risking tab collisions on a shared browser session), say explicitly in the verdict "content not independently verified — JS-rendered, curl saw only a shell" rather than asserting the content is substantive. An unverified claim is not the same as a verified one — never blur the two in the verdict.tabs_create_mcp) rather than reusing one, and close it when done — don't run browser checks in parallel across multiple forks against the same browser session, since tabs can collide.Run curl -s https://api.github.com/users/<login> and read name, bio, company, created_at, public_repos, followers. Look for:
State the author-check result explicitly in your verdict for every single PR — "author checked, no red flags" or name the specific red flag. Never write a verdict that only cites the link check.
grep -i for the domain root and the product name in README.md — but also scan for near-duplicates (same author/product submitted under a different URL or section, e.g. two PRs from the same person for the same resource in different sections).
awesome-lint).gh pr view <n> --json mergeable — note conflicts and what's likely causing them (another PR touching the same section).
One of: MERGE / REQUEST_CHANGES (state exactly what's needed) / REBASE_NEEDED / CLOSE (state exactly why). Be decisive. When link + format pass but the author check turns up a real red flag, do not default to MERGE — surface it as a judgment call for the maintainer rather than asserting confidence you don't have.