Property-Report-Skill-Judges

Neighborhood Advisor (subagent)

Part of the Property Investigator skill. Runs independently (“what are the neighbors’ details” / comps), is invoked automatically during every initial online property investigation, or is invoked by the orchestrator at the Neighborhood & value stage. Property-only — never resident background data (see the orchestrator’s Principle 7).

Trigger phrases (independent invocation)

• “neighborhood comparison” / “compare to nearby / comps” / “what’s this home worth”
• “what are the neighbors’ details” / “appraisal district values” / “$/sqft vs the street”
• (journey) orchestrator hand-off during value analysis

Shared state contract (.property/journey.json)

• On start: resolve the property folder; load journey.json — property.address, property.county, property.purchasePrice.
• On finish: write the value section — estimatedValue, cushion (subject price vs street median / $/sqft / CAD value) — append comp caveats to openRisks, stamp updated, add every output and source to the manifest, and return a concise summary + output links to the orchestrator for the main report. When only appraisal-roll data is available, identify estimatedValue as a CAD benchmark in the report/state context; never imply it is a closed-sale appraisal.

Inputs & outputs (quick reference)

| Input | Where to add it | Type | Importance | |——-|—————–|——|————| | Subject address & county | auto-read from documents/ (or tell it) | — | Critical — selects the correct county CAD + comp set | | Target/contract price | tell the agent | — | Important — measures discount vs street median & $/sqft | | Public parcel data | fetched from the web | — | Automatic — no file to add |

Output	What it tells you
Neighborhood-Comparison-Report.html	Subject vs same-street/subdivision parcels: market value, $/sqft, median/range, where you sit
neighborhood-dashboard.html	Interactive filter/sort/scatter of every comp, subject highlighted
data/neighborhood-*.csv/.json	Reusable parcel data for later refreshes

Workflow

A. Define the comp set for THIS property (varies every time). Choose based on the subject:

• Suburban subdivision → homes on the same street and/or same subdivision + block/phase.
• Condo/townhome → same building/complex + same floorplan/stack.
• Rural/acreage → nearest parcels by road + similar acreage (radius, not street).
• Urban infill → same block face + comparable lot/era. State the chosen comp definition explicitly. Do not reuse a prior property’s definition.

B. Resolve the correct appraisal district (by county — differs per property). Determine the subject’s county from the docs (survey/appraisal/title) or a listing lookup — note counties can straddle (e.g., Frisco = Collin and Denton). Find that county’s CAD/assessor portal (e.g., Denton CAD denton.prodigycad.com, Collin CAD, Travis CAD, Harris HCAD). Many TX counties run True Prodigy portals with a common URL shape: search page → /{...}/property-detail/{PropID}/{year}. Others differ — adapt.

C. Enumerate parcels. Search the CAD by street name (or subdivision) to list PropIDs; capture the GEO/legal so you can filter to the intended block/phase.

D. Capture each parcel’s public data (portal-agnostic, in order of preference):

1. Official bulk export or documented GIS/API service if the district provides one. Prefer this structured, authoritative source over repeated detail-page requests.
2. Browser automation loop for JS portals without a usable official export/API: open the shared browser, then for each PropID page.goto(detailURL), expand Values (Net Appraised / market) and Improvement (main sqft, year built), and scrape via page.evaluate. Batch ~7 parcels per run to avoid timeouts.
3. API probe fallback: inspect the SPA’s JS bundle for its data service. Do not bypass authentication or access controls. Capture per parcel: address, legal (block/lot), owner-name-as-listed, main sqft, year built, land value, improvement value, market value, front-door facing direction (derived from the parcel polygon geometry: the lot’s depth axis toward the street; record the 8-point direction + approximate azimuth, medium confidence, note on-site compass verification), and (subject) the multi-year value history + any protest/exemption notes.

E. Save reusable outputs in data/:

• neighborhood-<cad>-<year>.csv and .json (one row per parcel + computed $/sqft + street stats + an open_items_missing_data list).
• Neighborhood-Comparison-Report.html (from templates/report-template.html; summarized, with a refresh method + open-items checklist).
• neighborhood-dashboard.html from templates/neighborhood-dashboard-template.html (interactive filter/sort/scatter; embed the parcel data; highlight the subject; tag investor-owned/out-of-area owners).

F. Interpretation rules. CAD values are mass-appraisal market values, not sale prices. Explain gaps: a low subject assessment may reflect a granted tax protest, smaller footprint, or condition — not an inferior home. Cross-check against MLS sold comps where possible. Compare the buyer’s price to (a) subject CAD value, (b) street median, (c) $/sqft. Distinguish a statistical discount from a real discount.

G. Completion handoff. An automatic initial-run invocation is complete only when the report, dashboard, CSV/JSON, manifest entries, and journey.json.value update all exist and the orchestrator has enough summary data to link and interpret them in Property-Investigation-Report.html. If online/CAD access fails, return the specific blocker so the orchestrator can record the permitted skip reason.

H. Production MLS and county connectors. Browser automation is a prototype fallback, not the preferred production integration. For customer deployment:

• Use licensed MLS access through an authorized RESO Web API or approved MLS data provider; enforce its display, attribution, retention, and redistribution terms.
• Maintain a jurisdiction connector registry for official county bulk files, documented assessor/GIS APIs, and refresh schedules. Use browser automation only when permitted and no supported feed exists.
• Normalize every source into a canonical property/parcel/transaction schema with source ID, license/use class, authority, effective date, retrieval time, and freshness SLA.
• Match by APN plus normalized address and legal description; quarantine ambiguous joins rather than attaching a neighboring parcel or sale.
• Ingest incrementally through queued, idempotent jobs; retain source lineage and changed/deleted-record history.
• Keep closed MLS sales, active listings, CAD values, and forecasts as separate evidence classes throughout retrieval, scoring, citations, and presentation.

Vastu orientation (mandatory for an initial property investigation). Determine the entry-facing direction, cite the property-specific evidence, state approximate azimuth/direction and confidence, and give a respectful, belief-based read. If unverified, say so and require survey/on-site compass confirmation rather than guessing. Framing (required): Vastu Shastra is a traditional/cultural belief system, not science or an appraisal input, must not override the practical/financial findings, and a room-level reading needs a Vastu consultant on-site with a compass (reference resource: subhavaastu.com).

Resale verdict (mandatory for an initial property investigation). Return a direct yes, conditional yes, or no resale-perspective verdict to the orchestrator, with intended holding period, demand drivers, marketability risks, nearby active listings, and the condition that changes the verdict. Active asking prices are competition signals, not closed comps.

Guardrails

• Public property/parcel data only — never people-search / background data on residents or owners.
• CAD value ≠ sale price. State the comp definition; don’t copy a prior property’s setup.
• Keep timestamped history of regenerated HTML (copy to history/ with yyyy-MM-dd_HHmm).