hermes-skills/skills/research/recurring-information-scout/SKILL.md

name, description, version, author, tags

name	description	version	author	tags
recurring-information-scout	Periodic cron-driven information scanning — search the web for new products, vehicles, competitors, or market entries, cross-reference against a known database, de-duplicate against prior scans, and produce a structured delta report. Designed for weekly/daily cron jobs that keep a reference database fresh.	1.0.0	Sho'Nuff	research cron scanning database-maintenance periodic monitoring

Recurring Information Scout

Umbrella for cron-driven periodic scanning tasks. Covers the workflow of searching the web for newly announced entities (products, vehicles, competitors, market entries), cross-referencing against a known database, checking what was reported in prior scans, and producing a clean delta report.

Triggers

• Cron job that scans for new vehicles/products/competitors and reports delta
• Periodic market scan against a reference database
• "Check if anything new appeared since last week"
• Database maintenance cron that requires web research to keep fresh

Workflow

Phase 1: Load Prior Context

Always start by checking what was found in PREVIOUS scans of this same cron job. This avoids reporting the same vehicle/product twice across runs.

Use session_search(query="<cron-job-name> or <topic>", limit=5, sort="newest") to find recent prior runs. Extract the list of previously-reported items from those sessions to build a de-duplication blocklist.

Key technique: Don't just read the summary — extract the ACTUAL count of items found in each prior run and add them to your de-duplication check.

Phase 2: Verify Current Database State

Read the live database file (JSON, CSV, whatever format) and build a full list of entities already present. This gives you the primary de-duplication set.

For JSON databases with a pattern like {Make: {Model: {Year: HP, ...}}}:

import json
v = json.load(open('/path/to/database.json'))
# Check if a specific make/model exists
exists = make in v and model in v[make]

Phase 3: Search Fresh Sources (Parallel)

Batch independent web searches for:

• General industry query: "2025 2026 new [category] [attribute] announced"
• Event-specific queries (e.g., current auto shows, trade events happening this week)
• Niche/startup queries for small-volume producers
• Expanded model-year window: Include BOTH "2025" and "2026" model years separately. A vehicle announced as a 2025 model in early 2025 won't appear in a "2026 new" search. Run queries for both current and previous model year to catch announcements that aged out of the news window.
• Manufacturer press sites (e.g., audi-mediacenter.com, lamborghini.com/news, ford.com/performance) — search directly for recent press releases from the OEM's media portal. These often contain confirmations months before automotive press picks them up.

Use web_search (up to 10 results) for each independent angle. Fire them in parallel with a single assistant turn.

MCP Exa Search: When the mcp__exa__web_search_exa tool is available (via an Exa MCP server), prefer it over web_search for this phase. Exa's semantic search catches niche and boutique manufacturers (Zenvo, McMurtry, Denza) that keyword-based search often misses — it indexes both major press and deep sources. Exa's date-sorted results also help identify which findings are genuinely new vs. old news being recirculated. When using Exa, set numResults=10 and phrase queries as natural-language descriptions of the ideal page rather than keyword lists.

Phase 4: Deep-Dive on Findings

For each candidate found in Phase 3:

1. Extract the specific page with web_extract to get confirmed specs
2. Verify against the Phase 2 database state — is it REALLY absent?
3. Check against the Phase 1 prior-report blocklist — was it already reported but not added?
4. Build a structured entry: Make, Model, Year, HP/Spec, Source URL

Phase 5: Cross-Reference Prior Reports Against Database

De-duplication is NOT a single pass. A vehicle reported in a prior run may be:

• Already added to the database — silently skip (it was caught)
• Still absent from the database — re-report it with a note that it's been pending since the earlier date

Use python to iterate the prior reports' known item list against the live database state and flag any that are still missing.

Phase 6: Compile and Deliver Report

Structure the output by:

1. New discoveries today — items found THIS run that were in neither prior reports nor the database
2. Accumulated from prior reports still missing — items flagged on earlier dates that remain absent from the database
3. Database corrections — items in the DB with wrong specs that need updating
4. Patterns / recommendations — trends noticed (e.g., boutique builders appearing, need for "custom" entry option on forms)

Use a consistent format:

| # | Make | Model | Year | HP | Notes | Source |

When the DB needs updating, include specific instructions at the bottom.

Pitfalls

• session_search de-duplication is approximate — FTS5 can miss some prior sessions. Always cross-reference at the data level (check the actual database file), not just via search results.
• Prior reports may have missed items that were already in the DB — always verify each prior-run claim against the actual file before re-reporting it as "still missing."
• Cron context means no user follow-up — everything you need must be gathered in one pass. You cannot ask "should I add this" so use judgment: report findings clearly and let the user decide.
• News is time-bound — a Goodwood FoS debuts article published July 9 is only fresh for about a week. Don't report July debuts as new discoveries in August. Use web_extract timestamps or search sort by date.
• Small/deep sources matter — the big auto news sites cover Ferraris and Porsches. Goodwood FoS entry lists, niche hypercar blogs, and Chinese auto shows catch the Zenvo/Denza/McMurtry ones. Don't rely on a single source.
• Deliver findings as the final response, not via send_message — cron jobs deliver output as the response text. Put the primary content directly in your response.
• When the user isn't present (cron context), structure the report for mobile-friendly reading — no pipe tables, ASCII-only if the delivery channel is Telegram or phone.

Linked Files

See references/exotic-vehicle-scout-workflow.md for the specific implementation of this skill for the Apex Track Experience vehicle database cron job, including the exact de-duplication and cross-referencing patterns used.

See references/apex-track-experience-vehicle-db.md for the vehicle database schema, file locations, and known corrections.