Property Listings Skill: Rental Cards in Hermes Agent

The Property Listings skill turns researched properties into browsable cards inside the Hermes desktop transcript. You supply the data, the skill supplies the presentation, and the shortlist stays comparable from one message to the next. Reach for it when you are comparing rentals or re-ranking a shortlist and want the details to read like a listing board rather than a wall of prose.

What it does

At its heart this is a presentation recipe. It is not a listing search service and it is not an investment valuation tool. You gather the property details yourself, then emit a fenced code block whose language is listing and whose body is valid JSON. Hermes renders that block as a native card in the desktop transcript.

The card carries the address, price, specs, a short note, verified facts, unresolved catches, a photo gallery, and source links. You can present a single property as one object, a shortlist as an array of objects, or a comparison as { "listings": [...] }. Because the format is consistent, a follow-up message about a property you already showed can use the same card shape and the reader can compare it against the earlier one without re-reading everything.

Outside the desktop app, the same information belongs in ordinary Markdown with source links. Other clients do not need to render listing fences, and they will not.

Before you start

You need a Hermes desktop conversation for native cards. The backend may be local or remote, so this is not a constraint on where the model runs, only on where the cards appear.

Property details must come from the user or be verified through web_search, web_extract, or the browser tools available in this session. There are no additional API keys or dependencies required for card formatting itself. The skill is optional and installed on demand, so it will not be present in a fresh install until you add it.

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. One caveat matters here: installing does not retrofit the running conversation's skill index. If you want automatic discovery, start a new conversation. If you want to use it right now, load the installed skill explicitly.

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.

Field	Shape and meaning
address	Required nonempty street address or property headline.
price	Formatted string including currency and rental period, if applicable.
beds, baths	Positive numeric counts; omit unknown values.
size	Formatted area including units.
note	Why this property is worth a look.
facts	Array of short verified specs or amenities.
catches	Array of risks or questions to verify before a tour.
images	Direct HTTPS photo URLs in listing order; the first is the hero.
links	Array of { "label": "Source", "url": "https://..." } detail-page links, not search-result URLs.

Procedure

1. Gather the address, price, specs, photos and canonical detail URL. Distinguish verified facts from unknowns; do not invent prices, amenities, or photo URLs.
2. Deduplicate portal mirrors of the same property into one card, retaining useful source links. Keep source dates and availability caveats in the surrounding prose.
3. Emit the listing fence for every property presented, including follow-ups and re-rankings. Keep facts short and put unresolved concerns in catches.
4. Check the JSON before sending. This fictional format example illustrates all fields; replace its values and example URLs with verified listing data:

{
  "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

Cards are authored from gathered data, not fetched from a listing URL or embedded portal page. The skill does not go and get the listing for you; it formats what you already have.

A sparse card needs only an address. Omit unknown fields rather than filling them with guesses. That is a deliberate design choice: a card with gaps is more honest than a card with invented amenities.

Use direct remote image URLs, not local paths, data URLs, or search-result pages. Expired or blocked images disappear from the gallery, but the text and links still matter, so a broken image is not a reason to drop the card.

Keep a fence to at most 24 properties, 40 images per property, and 12 entries in facts, catches and links. Text fields are truncated to 400 characters by the renderer, so keep them tight.

Malformed JSON or a card without identity falls back to a plain code block. That fallback is readable, but it is not a card. And a valid card is not proof that the underlying listing is current or accurate. The card is a presentation layer, not a verification layer.

Verification

Before you send, check that every presented property has an address and a verified source link, and that unknowns are explicit rather than silently omitted or guessed.

On the desktop, the card 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 use a hero-and-supporting-frames mosaic, and additional photos remain browsable there.

If the card fails to render, validate the fence language and JSON, then preserve a readable Markdown fallback with the same facts and links. The fallback keeps the information available even when the card does not appear.

When not to use it

If you are not in the desktop app, use ordinary Markdown with source links instead. Other clients need not render listing fences, and forcing the format there just produces a code block. This skill is also the wrong tool if you need a listing search service or an investment valuation. It presents researched properties; it does not find them or price them.

Limits and gotchas

The main limits are structural. The fence caps at 24 properties, 40 images per property, and 12 entries in facts, catches and links. Text fields truncate at 400 characters. Malformed JSON or a card without identity falls back to a plain code block. And a valid card is not proof that the underlying listing is current or accurate.

What pairs with it

This skill sits alongside the other optional productivity skills in the Hermes catalog. It works best when paired with the research tools you already use in the session: web_search, web_extract, and the browser tools. Those gather the data; this skill presents it. If you are building a shortlist workflow, keep the cards consistent across messages so the comparison stays honest.