Initial skills documentation — 25 categories, all SKILL.md + references + scripts
This commit is contained in:
root
@@ -0,0 +1,101 @@
|
||||
---
|
||||
name: recurring-information-scout
|
||||
description: "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."
|
||||
version: 1.0.0
|
||||
author: Sho'Nuff
|
||||
tags: [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, ...}}}`:
|
||||
```python
|
||||
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.
|
||||
Reference in New Issue
Block a user