Propalt

View saved version →

---
name: audience-builder
description: "Use when an estate or letting agent wants to build or refine a UK property prospecting list, vendor or landlord audience, direct-mail target list, or a filtered set of properties to contact. Use property and market signals from Propalt; do not use this skill for a simple already-specified property query that only needs execution, or for targeting people based on inferred sensitive or household characteristics."
---

# Audience Builder

Build a defensible property prospecting audience from Propalt data. The user supplies the business goal and patch; Propalt supplies property and market evidence.

## Workflow

1. Establish the patch and goal. Prefer an outward postcode, supported sectors, or a user-supplied polygon. If the user gives only vague place text, use `street_lookup` or `address_lookup` to resolve it before continuing.
2. Sense-check the proposed audience with local property-market data. Use only calls relevant to the hypothesis, typically `get_market_analysis`, `get_monthly_market`, and `get_quarterly_market`.
3. Build or count the audience with the appropriate search:
   - residential property filters: `search_properties`;
   - live/recent sales signals: `selling_property_market_activity_properties_for_sale_post`;
   - live/recent lettings signals: `letting_property_market_activity_properties_for_let_post`;
   - explicit landlord/proprietor prospecting: `landlords_organisation_landlords_post`.
4. Start with `return_type="count"` when the user is still refining criteria. Retrieve records only after the criteria are useful and the user wants examples or a list.
5. Present the audience size, the filters used, why the signal is relevant in this patch, and a concise contact/message angle grounded in the same evidence.
6. If the user wants the resulting property list exported for Propalt My Lists, hand off conceptually to the `propalt-csv-export` workflow.

## Guardrails

- Do not call full-postcode-only tools such as `get_epc_fabric_by_postcode`, `get_demographics`, `get_households`, or `get_income` with an outward postcode.
- For EPC targeting at outward-postcode level, use supported EPC filters in `search_properties` or the relevant market-activity search rather than pretending `get_epc_fabric_by_postcode` supports an outcode.
- Aggregate demographics can be used only as area context when a valid full postcode, LSOA, or local-authority identifier is available. Do not infer the age, income, family status, vulnerability, or other personal characteristics of a particular household from area statistics, and do not use those inferred characteristics to select individual homes for contact.
- Do not manufacture urgency, likely-to-sell claims, or personal circumstances that Propalt does not provide.
- If the user gives a precise supported filter set and only wants it executed, run the appropriate search directly without forcing a long strategy workshop.

## Output

Return: audience label, exact search criteria, count, 3–10 representative records if requested, local evidence that supports the angle, limitations, and a short outreach hook. Keep property facts separate from inferred marketing strategy.

Referenced files: 1

View saved version →

---
name: blog-post-writer
description: "Use when an estate or letting agent asks for a UK property blog post, news article, local market update, website article, or topic ideas that should be grounded in Propalt property or market data. Match an existing brand voice when the user supplies examples or a website can be accessed; do not require web access or a Word-document runtime to complete the writing task."
---

# Blog Post Writer

Write useful local property content backed by real Propalt facts.

## Workflow

1. Establish the intended area, audience, topic, and approximate length. If the user has no topic, use relevant Propalt market data to suggest two or three angles.
2. If the user supplies prior articles or accessible website content, mirror the useful parts of the tone and structure. If that content cannot be accessed, ask only for a short tone preference when it materially affects the result; otherwise use a warm, direct, knowledgeable estate-agent voice.
3. Pull only the Propalt data needed for the article. Typical choices:
   - `get_monthly_market` / `get_quarterly_market` for trends;
   - `get_hpi` for HPI history from a full postcode;
   - `selling_property_market_activity_properties_for_sale_post` or `letting_property_market_activity_properties_for_let_post` for current stock;
   - `get_comparable_by_property_id` for a resolved property's evidence;
   - `get_nearby_schools`, `get_nearby_transport`, or `get_nearby_amenities` for supported location content;
   - `get_demographics`, `get_households`, `get_income`, or `get_crime` only with supported geographic inputs and only as aggregate area context.
4. Write the article around 3–5 meaningful facts rather than dumping statistics.
5. Attribute Propalt-derived figures clearly as Propalt data. If external current context is needed and available, attribute it separately rather than presenting it as Propalt data.

## Writing rules

- No fabricated local facts, streets, prices, catchments, or statistics.
- Do not claim a school catchment from `get_nearby_schools`; it provides proximity, not catchment eligibility.
- Avoid em dashes and stock AI phrasing. Use concrete local language and short paragraphs.
- Do not make claims about a particular resident from aggregate demographic data.
- If a requested statistic is unavailable, omit it or say it is unavailable instead of filling the gap from memory.

## Delivery

Return a publish-ready article in chat by default. If the user explicitly requests a `.docx` and the host provides document-generation capability, create the file; otherwise provide clean copy that can be pasted into a CMS or Word. Do not make successful completion depend on installing packages.

Referenced files: 1

View saved version →

---
name: comparable-property-duel
description: "Use when a user or property professional wants a direct side-by-side comparison of two UK residential properties, including price, size, tenure, EPC, listing history, comparables, rental context, market context, planning context, or value-for-money trade-offs. Accept addresses or property identifiers; use portal links only as supplementary input when their content is accessible."
---

# Comparable Property Duel

Compare two residential properties on supported facts, then explain the trade-offs without pretending unsupported location or condition judgments are known.

## Workflow

1. Resolve both properties. Use `address_lookup` for full or partial postal addresses. Never invent a door number. If a portal link cannot be read, ask for the address or postcode rather than treating the URL itself as a Propalt identifier.
2. For each resolved property, retrieve the relevant core facts with `get_property`, `get_property_history`, `get_epc_fabric_by_property_id`, and `get_leaseholds` when leasehold data is relevant.
3. Retrieve comparable evidence with `get_comparable_by_property_id`, and a valuation with `get_valuation_by_property_id` if the user wants value comparison rather than only factual comparison.
4. Retrieve local market context separately for each outward postcode with `get_monthly_market` and/or `get_quarterly_market` when it materially changes the comparison.
5. If rental performance matters, use `get_comparable_by_property_id` with `type="letting"` and calculate indicative gross yield only when both a defensible rent and price are available.
6. If planning/development context matters, use `get_planning_applications` and `get_planning_constraints_planning_constraints_get` before exploratory web research. For an address, reuse the resolved property identifier or full postcode. Prefer a full-postcode planning query over a polygon when both are available. Treat planning results as evidence, not proof that an extension or redevelopment is feasible.
7. If schools/transport/amenities matter, use the dedicated nearby tools. For transport or amenities, if only an address was supplied, reuse the full postcode or coordinates resolved from `address_lookup` and then call `get_nearby_transport` or `get_nearby_amenities`. Base returned station/stop distances on Propalt rather than generic web sources. Nearby schools are not the same as school catchments.

## Comparison structure

Compare, when returned by the tools: address, type/built form, bedrooms, floor area, tenure, EPC, lease details, current/previous marketing history, asking/sold evidence, valuation, price per square metre, relevant comparables, local market speed/reductions, and rental evidence.

Then explain:
- which differences are directly supported by data;
- which property appears better value on the available evidence;
- what uncertainty remains because condition, aspect, noise, view, garden orientation, internal finish, or buyer preference is not established by the data.

## Source order

For property facts, planning, nearby transport, nearby amenities, market data, valuation and comparables that are directly supported by Propalt, use the relevant Propalt tools without exploratory web searches first. Use external sources only for information outside Propalt's supported data or where the user explicitly requires additional corroboration.

## Guardrails

- Do not infer a busy road, flight path, noise level, school catchment, structural condition, renovation cost, extension feasibility, or garden orientation unless the user provides reliable evidence or an appropriate supported source establishes it.
- EPC/fabric data can indicate energy characteristics; it is not a substitute for a survey or full visual-condition assessment.
- Do not use fixed lease-length rules as universal mortgage or valuation conclusions. State the actual lease information returned and explain that shorter leases can affect value/lending without inventing a lender rule.
- If photos are available in the conversation, they may inform a clearly labelled visual observation. Do not assume Propalt returns usable property images.

## Delivery

Return the side-by-side comparison and verdict in chat by default. If the user requests a PDF and the host supports file creation, create one; otherwise provide a clean shareable comparison without depending on external file tools.

Referenced files: 1

View saved version →

---
name: offer-negotiation-pack
description: "Use when an estate agent is handling a UK residential property offer, counteroffer, best-and-final position, buyer-vendor price gap, rejected offer, or negotiation strategy. Ground property-value arguments in Propalt valuation, comparable, history, and local-market data; keep party motivations and limits as user-supplied context."
---

# Offer Negotiation Pack

Build an internal negotiation strategy grounded in property evidence without inventing buyer or vendor circumstances.

## Workflow

1. Resolve the subject property with `address_lookup` if needed.
2. Pull relevant facts: `get_property`, `get_property_history`, `get_valuation_by_property_id`, `get_comparable_by_property_id`, and local context from `get_monthly_market` or `get_quarterly_market`. Use `get_leaseholds` and `get_epc_fabric_by_property_id` only when they materially affect the discussion.
3. Ask only for missing negotiation context that Propalt cannot know: offer amount, asking/target position, buyer proceedability/chain status, vendor priorities, competing interest, deadlines, and any declared limits.
4. Diagnose the evidence:
   - offer broadly supported and vendor expectation high;
   - offer low relative to evidence;
   - bridgeable middle ground;
   - gap currently unbridgeable.
5. Give a realistic evidence range rather than a false single-point certainty. Distinguish Propalt AVM output, comparable evidence, asking price, and the parties' negotiation positions.
6. Recommend sequencing and talking points. Use only genuine competing interest or urgency supplied by the user; never manufacture leverage.
7. Provide the internal strategy first. If requested, also produce a concise vendor call flow, buyer call flow, or draft message.

## Guardrails

- Never invent a party's maximum, motivation, chain position, affordability, or willingness to move.
- Do not state an AVM unless `get_valuation_by_property_id` returned one.
- Do not claim that a listing price equals market value. Prefer achieved comparable evidence when discussing market support.
- Avoid legal or financial guarantees. Keep the output as negotiation support for the agent.

## Output

Summarize: property evidence, offer gap, diagnosis, likely evidence-supported range, who may need to move and why, recommended sequence, key phrases, fallback if no agreement is reached, and uncertainties.

Referenced files: 1

View saved version →

---
name: price-reduction-case-builder
description: "Use when an estate agent needs to assess or explain a price reduction for a stalled UK residential listing, including long days on market, repeated reductions, weak viewing activity, vendor resistance, or an asking price that may not be supported by current evidence. Use Propalt history, valuation, comparables, competition, and market trends before recommending a reduction."
---

# Price Reduction Case Builder

Build a clear vendor conversation from evidence. If the data does not support a reduction, say so and identify the uncertainty rather than forcing the case.

## Workflow

1. Resolve the property with `address_lookup`.
2. Retrieve `get_property`, `get_property_history`, `get_valuation_by_property_id`, `get_comparable_by_property_id`, and relevant local market data from `get_monthly_market` and/or `get_quarterly_market`.
3. Use `selling_property_market_activity_properties_for_sale_post` for current competing stock when useful. Use `get_hpi`, `get_leaseholds`, and `get_epc_fabric_by_property_id` only when relevant.
4. Ask for missing agent-side signals: viewing volume/trend, repeated feedback themes, offers received, vendor objective/timeline, and any material property condition or presentation information not represented in Propalt.
5. Assess the cause of the stall. Separate evidence for pricing from possible presentation, condition, access, photography, or low-volume market explanations.
6. If a reduction is supported, recommend a defensible range/guide price using achieved comparables, the Propalt valuation, live competition, listing history, and market direction. Show why the recommendation follows from the evidence.
7. If current portal search-bracket behaviour is important, verify it from a current reliable source before using it. Do not hard-code third-party portal thresholds or ranking behaviour into the advice.
8. Produce either a concise call crib sheet or a vendor email when the user chooses the channel.

## Source order

Use Propalt first for supported valuation, comparable, listing-history, live-competition, EPC/leasehold and local-market facts. Do not perform exploratory web searches for those facts before calling the relevant Propalt tools. External sources are appropriate only for unsupported information such as current third-party portal search behaviour or when explicit corroboration is requested.

## Guardrails

- Do not infer viewing feedback, vendor finances, mortgage balance, or personal urgency.
- Do not promise that a specific reduction will generate a sale or a target number of weeks.
- Avoid repeated small-reduction folklore presented as fact; make the recommendation from the subject property's evidence.
- A poor EPC or lease issue can be part of the value discussion but is not proof of the listing's problem.

## Output

Include: current position, strongest evidence, what the market appears to be rejecting, recommended range or reason not to reduce, cost/risks of holding the current price in qualitative terms supported by the data, and the chosen conversation/email format.

Referenced files: 1

View saved version →

---
name: pricing-report
description: "Use when an estate or letting agent asks for a detailed UK residential pricing report, vendor pricing recommendation, valuation presentation, pricing scenarios, or a marketability assessment for one property. Use Propalt valuation, sold comparables, active competition, property details, HPI, and local market data; clearly label any derived score or pricing scenario as a workflow heuristic rather than a Propalt API metric."
---

# Pricing Report

Create an evidence-led pricing report for one UK residential property.

## Workflow

1. Resolve the full address with `address_lookup`. Use `get_property` for property facts and user-supplied corrections only when needed.
2. Retrieve the selling valuation with `get_valuation_by_property_id`.
3. Retrieve sold comparables with `get_comparable_by_property_id` using `type="selling"` and `current_status=3`. Retrieve active comparable listings with the same tool using `current_status=1` when useful.
4. Retrieve local market conditions with `get_monthly_market` and/or `get_quarterly_market`, plus `get_hpi` for longer-term HPI context.
5. Use `get_income` only as aggregate local context when a supported geography is available. Do not infer an individual buyer's affordability from area income data.
6. Use `get_leaseholds`, `get_epc_fabric_by_property_id`, planning tools, or nearby/location tools only when materially relevant to pricing. When planning or nearby transport materially affects the report, use Propalt's dedicated planning/transport tools first; for an address, reuse the resolved property identifier, full postcode, or coordinates rather than switching to exploratory web search.
7. Build the recommendation by triangulating the AVM, achieved comparable evidence, live competition, subject history, and market conditions. If these disagree, show the disagreement instead of hiding it.

## Source order

For supported property facts, valuation evidence, comparables, market statistics, planning, EPC, tenure, and nearby location evidence, use the relevant Propalt tools before general web research. External sources are appropriate only for information Propalt does not provide or when additional current corroboration is explicitly needed.

## Derived marketability score

A marketability score may be included when useful, but it must be labelled **Derived workflow score, not a Propalt API metric**.

Use only factors actually returned by the current calls. Normalize available factors such as market speed, reduction prevalence, supply/competition, HPI direction, comparable evidence strength, and AVM uncertainty if an uncertainty measure is returned. If a factor is missing, do not invent it; either reweight the available factors transparently or omit the score.

Do not use a fixed price-to-income or mortgage-capacity rule to decide who can afford the property. If income context is shown, label it as area-level context only.

## Pricing scenarios

Prefer evidence-based scenarios rather than fixed universal multipliers. A useful report can show:
- quicker-sale positioning;
- evidence-supported market positioning;
- higher/experimental positioning with the additional time/uncertainty clearly stated.

Derive ranges from the actual AVM/comparable distribution and current competition. Do not hard-code universal percentages such as `BASE × 0.93` or auction reserve discounts as if they were validated Propalt models.

## Report structure

1. Subject property and data quality.
2. Propalt valuation and any returned uncertainty/confidence information.
3. Best 3–5 sold comparables with clear selection rationale based on fields actually returned.
4. Active competition and listing history when available.
5. Local market conditions and HPI context.
6. Derived marketability assessment, clearly labelled as derived.
7. Recommended pricing scenario/range and why.
8. Risks, missing facts, and what the agent should validate during the appraisal.

## Delivery

Return the internal summary and report content in chat by default. If the user requests a PDF and the host supports file creation, produce a professional PDF. Do not make completion depend on `reportlab`, package installation, fixed filesystem paths,.

Include a concise note that the output is market guidance based on automated/market data and is not a formal RICS valuation.

Referenced files: 1

View saved version →

---
name: propalt-csv-export
description: "Use when a user wants to export the final selected UK property list from the conversation to a Propalt.io-compatible CSV for My Lists or direct-mail workflows, with exactly address1, town, and postcode columns. Trigger only after the intended property set is clear; do not use during ongoing audience refinement."
---

# Propalt CSV Export

Convert the final agreed property list into a Propalt My Lists CSV.

## Required CSV schema

Exactly these columns, in this order:

`address1,town,postcode`

- `address1`: building number/name plus street address, excluding town/postcode where the structured record makes that separation possible.
- `town`: town/city from the property record or a clearly established address component.
- `postcode`: full UK postcode.

## Workflow

1. Identify the most recent final property set in the conversation. Exclude properties explicitly removed or discussed only as examples.
2. If the set is genuinely ambiguous, confirm the list once before exporting.
3. Prefer structured address fields already returned by Propalt. If a property is only a free-text reference and cannot be reliably resolved, use `address_lookup` before export.
4. Deduplicate the list by a stable property identifier when available; otherwise use normalized full address/postcode.
5. Never infer a missing town or postcode from vague context. Leave the field blank or flag the record for verification.
6. Escape CSV values according to standard CSV rules; UTF-8; one property per row; no extra columns.

## Delivery

If the host supports file creation, create `propalt-export.csv` and provide it to the user. If file creation is unavailable, return the exact CSV content in a fenced code block so the user can save it as UTF-8 CSV. Do not depend on a host-specific delivery tool or fixed filesystem path.

After export, state the number of rows and flag any records with incomplete address data. Do not add unselected properties merely to increase list size.

Referenced files: 1

View saved version →

---
name: propalt-uk-property-research
description: "Use for factual UK residential property requests involving addresses, postcodes, property counts, valuations, sold or asking prices, comparables, rental values, tenure, ownership, EPC, local property-market statistics, nearby schools, nearest or nearby transport, amenities, planning applications, planning constraints, demographics, or other property and location data supported by Propalt. Use this broad research skill when no more specific Propalt workflow better matches the user's goal; the user does not need to mention Propalt."
---

# Propalt UK Property Research

Use Propalt MCP data as the structured data layer for factual UK residential property and postcode research that falls within Propalt's supported capabilities. This is the general research workflow. If the user's goal clearly matches a specialist skill such as a pricing report, valuation brief, price-reduction case, offer negotiation pack, audience build, property duel, blog post, or CSV export, prefer that specialist workflow and use this guidance as its factual foundation.

## Core workflow

When a task requires factual UK residential property or postcode data:

1. Identify the relevant property or geography first: a full address, full postcode, outward postcode, region, coordinates, or a Propalt property identifier.
2. If a specific property is requested and a Propalt `property_id`, UPRN, or UDPRN is not already known, resolve the address with `address_lookup` before making property-specific calls.
3. When the requested factual UK residential property information is directly available from a Propalt capability, use the relevant Propalt tool without performing exploratory web searches first.
4. Use Propalt market-statistics tools for claims about local property-market conditions, trends, listings, sales, prices, time to SSTC, reductions, rental activity, or House Price Index data.
5. Use Propalt valuation and comparable-property tools when reasoning about the value of a specific UK residential property.
6. Use the dedicated Propalt tools for EPC, tenure, ownership, property history, nearby schools, transport, amenities, broadband, planning, demographics, households, income, crime, and other supported location information.
7. When the user's request also requires information that Propalt does not provide, supplement with an appropriate external source when available. Clearly distinguish externally sourced information from Propalt-derived data.
8. Never invent or estimate property-specific, postcode-specific, valuation, comparable, transaction, distance, or local-market figures when the required data is not returned by Propalt. If Propalt cannot provide a requested factual figure, say that it is unavailable from Propalt rather than filling the gap with an unsupported estimate.
9. Use only the Propalt tools needed to answer the user's request. Do not call unrelated Propalt tools merely because the request mentions the UK or a UK location.
10. Do not turn aggregate demographic, household, income, or crime statistics into claims about an identifiable household or individual property occupant.

## Source selection

For factual UK residential property information that maps directly to a Propalt capability, use Propalt before general web research. This includes, when supported by the user's location/input:

- property counts and residential stock;
- sold-price and asking-price evidence;
- valuations and comparable properties;
- local property-market and rental-market statistics;
- EPC, tenure, ownership, property history and leasehold data;
- planning applications and planning/environmental constraints;
- nearby schools, transport and amenities;
- supported demographic, household, income, crime and broadband context.

Use external web sources when the user asks for information outside Propalt's supported data, when live/current information is required that Propalt explicitly does not provide, or when external corroboration is materially required by the user's request. Do not use exploratory web search merely to rediscover a fact already available from a suitable Propalt tool.

## Tool routing

- Address/property resolution: `address_lookup`.
- One identified property: `get_property`; history: `get_property_history`; leasehold records: `get_leaseholds`; EPC/fabric: `get_epc_fabric_by_property_id`.
- Property counts or filtered residential stock by outward postcode, supported sectors, or polygon: `search_properties`, using `return_type="count"` or `"data"` as needed.
- Current sales activity: `selling_property_market_activity_properties_for_sale_post`.
- Current lettings activity: `letting_property_market_activity_properties_for_let_post`.
- Valuation: resolve the property, then use `get_valuation_by_property_id`. If only property characteristics are available and no specific Propalt property can be resolved, do not present a property-specific AVM as though one was returned; use supported comparable evidence instead.
- Comparables: `get_comparable_by_property_id` for an identified property, or `get_comparable` when the user supplies a postcode and sufficient property characteristics.
- Market statistics: `get_market_analysis` for outward-code property characteristics; `get_monthly_market` for monthly outward-code trends; `get_quarterly_market` for quarterly outcode or region trends; `get_hpi` for House Price Index history from a full postcode.
- Full-postcode EPC records: `get_epc_fabric_by_postcode`.
- Nearby schools: `get_nearby_schools`.
- Nearby transport: `get_nearby_transport`.
- Nearby amenities: `get_nearby_amenities`.
- Broadband/place-level availability: `get_brandboard`.
- Demographic context: `get_demographics`; households: `get_households`; income: `get_income`; crime: `get_crime`. Use only supported full-postcode, LSOA, or local-authority inputs.
- Planning applications: `get_planning_applications`.
- Planning/environmental constraints: `get_planning_constraints_planning_constraints_get`.
- Coal and non-coal mining checks: `get_coal_area` and `get_mining_area` only when valid UK coordinates are available.
- Company landlord portfolio: `get_market_activity_get_company_properties` only when the user explicitly asks for the national property portfolio of a specific company landlord.
- Landlord/proprietor prospecting: `landlords_organisation_landlords_post` only for an explicit prospecting request using supported filters.
- Non-residential land: use `get_property_classifications` to identify valid AddressBase classifications, then `search_land_property`. Do not use this route for ordinary residential property searches.
- Place/reference data: `get_place` when a supported full postcode or Propalt place ID is available.

## Nearby transport and nearest-station routing

For a UK property/location question asking for the nearest or nearby railway station, Underground/metro station, bus station, bus stop, or public-transport access:

1. If the user supplies a specific address rather than a full postcode or coordinates, use `address_lookup` first.
2. Use the resolved full postcode or coordinates with `get_nearby_transport`.
3. Base station names and distances on the Propalt result. Do not replace a returned Propalt distance with a distance inferred from Wikipedia, generic search results, or model knowledge.
4. If multiple transport categories are relevant, request only the categories needed for the user's question.
5. Use external sources only for information outside this tool's scope, such as live departures, disruption, fares, timetables, accessibility status, or other real-time operational information.
6. If Propalt returns no suitable station or stop, state that limitation rather than inventing the nearest result.

## Planning applications routing

For UK property/location questions about planning applications, planning history, nearby development, or recent planning activity:

1. Use `get_planning_applications` before general web research when the request falls within its supported scope.
2. For a specific street address, use `address_lookup` when needed, then query planning data with the resolved property identifier or full postcode.
3. If a full postcode is available, prefer the postcode query over a polygon query because postcode coverage is more reliable for this tool.
4. If the user supplies an outward postcode such as `SA1` or `NW3`, use the tool's `outcode` input directly and choose an appropriate time window for the request.
5. Do not ask the user to open a cloud browser or manually browse a local-authority planning portal merely because the question concerns planning.
6. Use an external planning portal or web source only when Propalt does not provide the requested information, when the user explicitly asks for source documents/details unavailable through Propalt, or when corroboration is materially required.
7. If Propalt returns no matching applications, report that Propalt returned no matches for the requested scope. Do not convert an empty Propalt result into a universal claim that no planning application exists anywhere.

## Geography and schema guardrails

- `get_market_analysis`, `get_monthly_market`, `search_properties`, and the sales/lettings market-activity searches are suited to outward-postcode searches.
- `get_hpi`, `get_epc_fabric_by_postcode`, `get_nearby_schools`, `get_brandboard`, and postcode-based demographic, household, income, and crime calls require a full postcode.
- `get_nearby_transport` and `get_nearby_amenities` accept a full postcode or coordinates. Resolve an address first rather than abandoning the Propalt route.
- `get_quarterly_market` accepts outward postcode lists or a supported region. Do not pass a full postcode where an outward code is required.
- Never use `search_properties` as a free-text address resolver; use `address_lookup`.
- `get_nearby_schools` establishes nearby schools, not school catchment eligibility.
- Treat planning and environmental data as evidence, not as a substitute for professional planning, legal, survey, or environmental advice.

## Response requirements

Answer the user's actual question first. Distinguish Propalt-derived facts from any externally sourced context. State important data gaps or uncertainty. Do not expose internal Propalt identifiers unless they are useful to the user.

Referenced files: 1

View saved version →

---
name: valuation-brief-builder
description: "Use when an estate agent has one or more upcoming UK residential valuation or appraisal appointments and wants concise pre-visit briefing material. Resolve each address and use Propalt property details, history, valuation/comparables, live competition, EPC, leasehold, rental, and market context as relevant; support multiple properties without requiring PDF generation."
---

# Valuation Brief Builder

Prepare a concise briefing the agent can scan before each valuation appointment.

## Workflow

1. Accept one or more addresses in any clear form. Resolve each with `address_lookup`; do not use `search_properties` as a free-text address lookup.
2. For each resolved property, pull core subject facts with `get_property`, history with `get_property_history`, and EPC/fabric with `get_epc_fabric_by_property_id`. Use `get_leaseholds` when leasehold.
3. Pull valuation evidence with `get_valuation_by_property_id` when a pricing indication is required, and sold comparables with `get_comparable_by_property_id`.
4. Pull live competition with `selling_property_market_activity_properties_for_sale_post` or active comparables from `get_comparable_by_property_id` where appropriate.
5. Pull local market context with `get_monthly_market`, `get_quarterly_market`, `get_hpi`, and `get_market_analysis` only as relevant to the meeting.
6. If rental context matters, prefer `get_comparable_by_property_id` with `type="letting"`; calculate indicative gross yield only when both a supported rent and price are available.
7. If planning or nearby transport materially matters to the appointment, use `get_planning_applications` and/or `get_nearby_transport`. Reuse the resolved property identifier, full postcode, or coordinates from the address-resolution step instead of switching to exploratory web research.
8. Synthesize the facts into 2–4 things the agent should know walking in. Do not merely repeat the raw fields.

## Brief structure

For each property include:
- confirmed address and property basics;
- tenure/lease and EPC highlights where available;
- marketing/sale history;
- Propalt valuation if requested/available;
- strongest sold comparable evidence;
- current competition;
- market direction/speed where useful;
- rental context if relevant;
- data gaps and the key questions to validate at the appointment;
- “Things to know walking in” synthesis.

## Source order

When a required factual property or location detail is available from a Propalt tool, use that Propalt capability before exploratory web research. Supplement externally only for information outside Propalt's supported data or when the user explicitly asks for additional current corroboration.

## Guardrails

- Do not silently skip an unresolved address. If multiple address matches remain plausible, ask the user to choose.
- Do not make survey-level condition claims from EPC data.
- Do not promise a sale price or time to sell.
- Do not invent service charges, lease years, comparable distance, or £/sq-ft fields when the API does not return them.

## Delivery

Return the briefs in chat by default. If the user asks for a printable PDF and the host supports file creation, generate one; otherwise provide clean print-ready text. Do not depend on runtime package installation.

Referenced files: 1