property-listings skill

Property Listings Skill

Present researched properties as browsable cards in the Hermes desktop transcript. This is a presentation recipe, not a listing search service or an investment valuation.

When to Use

• Presenting property or rental search results, comparing a shortlist, or re-ranking properties.
• Following up on a property already shown: keep using cards so the shortlist stays comparable.
• Outside the desktop app, use ordinary Markdown with source links instead; other clients need not render listing fences.

Prerequisites

• A Hermes desktop conversation for native cards; the backend may be local or remote.
• Property details supplied by the user or verified through websearch, webextract, or the browser tools available in this session.
• No additional API keys or dependencies are required for card formatting.

How to Run

Install this optional skill through the Skills catalog, or use terminal:

hermes skills install official/productivity/property-listings

Load it with skill_view(name="property-listings") when presenting listings. Installing does not retrofit the running conversation's skill index; start a new conversation for automatic discovery, or explicitly load the installed skill now.

Quick Reference

Emit a fenced code block whose language is listing and whose body is valid JSON. Use one object, an array of objects, or { "listings": [...] } for a comparison.

Procedure

verified facts from unknowns; do not invent prices, amenities, or photo URLs.

1. Gather the address, price, specs, photos and canonical detail URL. Distinguish

source links. Keep source dates and availability caveats in the surrounding prose.

1. Deduplicate portal mirrors of the same property into one card, retaining useful

re-rankings. Keep facts short and put unresolved concerns in catches.

1. Emit the listing fence for every property presented, including follow-ups and

replace its values and example URLs with verified listing data:

1. Check the JSON before sending. This fictional format example illustrates all fields;

{
  "address": "12 Example Lane",
  "price": "$2,400/mo",
  "beds": 3,
  "baths": 2.5,
  "size": "1,600 sqft",
  "note": "Fits the requested space and budget.",
  "facts": ["12-month lease", "Covered parking"],
  "catches": ["Verify pet policy and total move-in fees"],
  "images": ["https://example.com/property/front.jpg", "https://example.com/property/kitchen.jpg"],
  "links": [{"label": "Listing details", "url": "https://example.com/property/12"}]
}

Pitfalls

Expired or blocked images disappear from the gallery; the text and links still matter.

• Cards are authored from gathered data, not fetched from a listing URL or embedded portal page.
• A sparse card needs only an address. Omit unknown fields rather than filling them with guesses.
• Use direct remote image URLs, not local paths, data URLs, or search-result pages.

facts, catches and links. Text fields are truncated to 400 characters by the renderer.

• Keep a fence to at most 24 properties, 40 images per property, and 12 entries in

A valid card is not proof that the underlying listing is current or accurate.

• Malformed JSON or a card without identity falls back to a plain code block.

Verification

use a hero-and-supporting-frames mosaic; additional photos remain browsable there.

• Every presented property has an address and a verified source link; unknowns are explicit.
• Desktop displays the address, price, specs, facts, catches and links as a native card.
• Photos form a gallery; selecting a photo opens the lightbox. Three or more photos

readable Markdown fallback with the same facts and links.

• If the card fails to render, validate the fence language and JSON, then preserve a