` matches the PR's claim is not enough — the homepage is marketing copy; the listing page is where mass-generated content shows itself. - On that listing/inner page, look for content-farm tells: dozens/hundreds of entries with near-identical templated one-sentence descriptions (e.g. "X is a Y combining A, B, C, and D"); categories spanning unrelated verticals (NFT tools, retirement planning, video editing, startup communities alongside real estate) despite the site framing itself as niche-specific; boilerplate trust-signal phrases ("no sponsored rankings," "independent reviews," "no pay-to-play") that are themselves a genre marker of SEO directory sites, not evidence of substance. A site that is *itself* a generic multi-vertical AI-tool directory reskinned toward real estate fails "on-topic" and "genuine resource" even though the domain resolves and the title superficially matches — this is a CLOSE, not a formatting nitpick. - Generic marketing copy with no verifiable substance ("AI-powered," "revolutionary," "graded by AI") on an otherwise single-purpose product page is a yellow flag, not by itself a fail — corroborate against #2. - **`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. - If using the browser tools, create your own tab (`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. ## 2. Author signal — mandatory for every PR, not just ones you're inclined to merge Run `curl -s https://api.github.com/users/<login>` and read `name`, `bio`, `company`, `created_at`, `public_repos`, `followers`. Look for: - Bio/company full of decorative unicode, disconnected buzzword salad, or claims unrelated to the submitted product (e.g. "Pegasus detector," "77+ MCP tools," symbol-stuffed company names). This is a strong spam/noise signal even if the linked site itself loads fine — flag it explicitly and do not silently fold it into a MERGE verdict. - A brand-new account (days old) is *not* disqualifying on its own — legitimate indie builders often are. But a brand-new account **combined with** a noisy/irrelevant bio, or **combined with** an unfilled PR template, raises the bar for scrutiny. - A bio/company that plausibly matches the submitted product (e.g. "Founder of X — the thing they're submitting") is a positive signal, not just neutral. 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. ## 3. Duplicate 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). ## 4. Format compliance (contributing.md) - One line, ends with a period, doesn't just restate the name as the description. - Correct existing section, or a reasonable new-section proposal. - Matches the list's existing punctuation style (plain " - " separator, not em dash) and doesn't break blank-line list structure (would fail `awesome-lint`). ## 5. Mergeable state `gh pr view <n> --json mergeable` — note conflicts and what's likely causing them (another PR touching the same section). ## Verdict 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.

# Vet Pr > 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. - Skill: `etewiah/vet-pr` (Agent Skill) - Install (CLI): `npx skillmds@latest add etewiah/vet-pr` - Raw SKILL.md: https://api.skillmd.com/api/skills/etewiah/vet-pr/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: etewiah (https://skillmd.com/u/etewiah) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/etewiah/vet-pr --- # Vetting a PR on this repo 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. ## 1. Link liveness AND substance - `curl -sIL` the URL — non-200/3xx final status, parked-domain redirect, or a bare "coming soon" page is an automatic fail. - Fetch the actual page body, not just headers — and for anything that presents as a directory, listing, "reviews," or "tools" hub, **fetch a listing/inner page too, not just the homepage**. Checking that the homepage `` matches the PR's claim is not enough — the homepage is marketing copy; the listing page is where mass-generated content shows itself. - On that listing/inner page, look for content-farm tells: dozens/hundreds of entries with near-identical templated one-sentence descriptions (e.g. "X is a Y combining A, B, C, and D"); categories spanning unrelated verticals (NFT tools, retirement planning, video editing, startup communities alongside real estate) despite the site framing itself as niche-specific; boilerplate trust-signal phrases ("no sponsored rankings," "independent reviews," "no pay-to-play") that are themselves a genre marker of SEO directory sites, not evidence of substance. A site that is *itself* a generic multi-vertical AI-tool directory reskinned toward real estate fails "on-topic" and "genuine resource" even though the domain resolves and the title superficially matches — this is a CLOSE, not a formatting nitpick. - Generic marketing copy with no verifiable substance ("AI-powered," "revolutionary," "graded by AI") on an otherwise single-purpose product page is a yellow flag, not by itself a fail — corroborate against #2. - **`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. - If using the browser tools, create your own tab (`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. ## 2. Author signal — mandatory for every PR, not just ones you're inclined to merge Run `curl -s https://api.github.com/users/<login>` and read `name`, `bio`, `company`, `created_at`, `public_repos`, `followers`. Look for: - Bio/company full of decorative unicode, disconnected buzzword salad, or claims unrelated to the submitted product (e.g. "Pegasus detector," "77+ MCP tools," symbol-stuffed company names). This is a strong spam/noise signal even if the linked site itself loads fine — flag it explicitly and do not silently fold it into a MERGE verdict. - A brand-new account (days old) is *not* disqualifying on its own — legitimate indie builders often are. But a brand-new account **combined with** a noisy/irrelevant bio, or **combined with** an unfilled PR template, raises the bar for scrutiny. - A bio/company that plausibly matches the submitted product (e.g. "Founder of X — the thing they're submitting") is a positive signal, not just neutral. 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. ## 3. Duplicate 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). ## 4. Format compliance (contributing.md) - One line, ends with a period, doesn't just restate the name as the description. - Correct existing section, or a reasonable new-section proposal. - Matches the list's existing punctuation style (plain " - " separator, not em dash) and doesn't break blank-line list structure (would fail `awesome-lint`). ## 5. Mergeable state `gh pr view <n> --json mergeable` — note conflicts and what's likely causing them (another PR touching the same section). ## Verdict 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.