City Attraction Research

---
name: city-attraction-research
description: Research, classify, evidence-check, score, and prioritize attractions and city experiences for any destination. Use when asked for a comprehensive city must-visit inventory, ranked attractions, area-based sightseeing groups, or itineraries of different durations. Treat individual dishes and restaurant-to-dish matching as the responsibility of the separate local-food-and-dining-research skill.
metadata:
  version: "2.0.0"
---

# City Attraction Research and Ranking

Create an evidence-grounded *inventory first*, then a ranked shortlist and optional itinerary. Do not confuse "worth evaluating" with "must visit." Every attraction has **one primary category written as its complete descriptive name** and optional secondary tags. Never use single-letter category codes.

## When to use

- A traveler asks what to see, visit, or experience in a city, including Samarkand.
- A user wants systematic attraction research and transparent, comparable rankings.
- A user requests an attraction checklist usable independently or alongside a separate foods-to-try checklist.

## Do not use

- For a dish-by-dish culinary inventory, nutrition analysis, or matching dishes to restaurants: use `local-food-and-dining-research` instead.
- For live reservations: obtain real-time availability separately when tooling is available; never infer a bookable slot from a published schedule.

## Inputs and assumptions

Capture, when supplied: city/country, trip dates, full days available, first-time or repeat visit, interests, trip pace, mobility/accessibility, budget, and geographic scope. If missing, proceed with an explicitly labeled *balanced first-time visitor* baseline and keep visit selection separate from evaluation. Do not invent travel dates or accessibility needs.

## Default research files

Whenever the host can create files, generate **exactly three default outputs** from the researched attraction CSV with `python scripts/generate_research.py attraction_inventory.csv OUTPUT_DIR`:

1. `attractions.json`: canonical ranked or unscored candidate records, evidence, five rating dimensions, location status, and withheld-location reasons.
2. `attractions_checklist.csv`: all candidates in score order, with blank scores for unscored entries and `undecided` review decisions.
3. `attractions_mymaps.csv`: Google My Maps coordinates for sourced, verified places only; no invented pins.

Use the existing CSV template as the generator input and see [the output contract](references/output-contract.md). Generate full output files rather than merely listing their names. If file creation is unavailable, provide the structured research in the response and name each uncreated artifact; never claim full completion. `--overwrite` is required to replace existing default files. The existing `score_and_validate.py` and `export_pins.py` commands, GeoJSON and mapping review files remain **optional** and unchanged; they are not produced by the default three-file command. Native ChatGPT maps are optional when visibly supported. The travel itinerary belongs to `city-itinerary-builder`.

## Workflow

1. **Identify the city:** Summarize five to seven dimensions of its identity, including older history and modern living culture. Establish a city/near-city/regional boundary. Separate excursions from the city inventory.
2. **Discover candidates broadly:** Search official heritage and tourism sources, local publications, museums, maps, and recent substantive visitor reports if live research is available. Seek landmark, learning, landscape, food-market, craft, residential, sacred, and modern experiences. Do not pre-cap discovery at ten famous places. Record sources and dates; flag unverified candidates rather than fabricating evidence.
3. **Define the experience unit:** Usually one site or one coherent activity. Group attractions that form one natural visitor experience (e.g. an architectural ensemble). Keep an adjoining museum and archaeological walk separate if the activities are genuinely different. Link related entries by identifiers.
4. **Classify:** Assign exactly one full-name primary category from `references/categories-and-scoring.md`, plus two to four meaningful secondary tags when warranted. Classify the *reason to visit*, not every use of the same building. Follow tie-break rules in that reference.
5. **Evaluate independently of itinerary:** Rate five dimensions on 0–5 integer scales. Apply fixed weights and compute a /100 score. A missing rating is *unscored*, not zero. Store confidence and cited sources separately from judgment. Use the full-name category in all records, examples, and output.
6. **Rank and group:** Make a transparent master ranking, with tiers Must-Visit Candidate (80–100), Highly Recommended (60–79), and Optional or Specialist Interest (below 60). Scores within five points are near ties; don't pretend a one-point gap is definitive. Inspect category coverage and avoid popularity bias.
7. **Select rather than exhaust:** Build trip-specific selections for the durations requested. Apply proximity, opening days, booking, daylight, transit, weather, walking ability, and diminishing returns. Never require someone to visit all Tier A items; reserve time for meals and breaks.
8. **Deliver and preserve:** Provide an identity profile, classified inventory, scored ranking with rationale, and verification caveats. Generate the three default files using `scripts/generate_research.py` when executable file tools are available. Keep richer GeoJSON and direct map-export commands optional.
9. **Review:** After travel, retain objective historical attributes and revisit subjective scores, actual duration, closures, and enjoyment notes. Do not overwrite the research score with a traveler's post-visit taste score.

## Geographic research and pin-map output

Produce **Google My Maps-compatible CSV** as the default portable research-map output, and a native interactive map only when the current host supports and visibly renders it. Record stable `place_id`, sourced coordinates, `location_status`, `coordinate_precision`, `location_source_url`, and `location_verified_at`; research and coordinate verification are independent. The optional Python command `python scripts/export_pins.py attraction_inventory.csv attractions.geojson` now generates `attractions_mymaps.csv` plus an unlocated/review report. It retains its original GeoJSON/legacy-unlocated arguments. Never guess pins or claim the map was shown merely because a widget was requested. If native map rendering is unsupported or invisible, supply the My Maps export and a readable location list. **Do not generate downloaded HTML maps that depend on public OpenStreetMap tile servers by default.** Read [mapping and My Maps reference](references/mapping-and-mymaps.md) before any map export or native-map request; see [the output contract](references/output-contract.md) for fields and review rules.

When a user asks to **select and schedule** from this inventory, preserve its independent scores and hand the ranked records to [City Itinerary Builder](../city-itinerary-builder/SKILL.md) if installed; it owns final daily scheduling, sourced route maps, and printable travel materials. Remain usable without that sibling skill.

## Cross-skill boundary

`Local Cuisine and Food Markets` is the **attraction** category for markets, culinary walks, unusually noteworthy restaurants as visitor experiences, and food demonstrations. The attraction skill does **not** score individual dishes or maintain dish-to-venue recommendations. The food skill owns food records, venue profiles, and food-to-venue links. Share a stable `place_id` / `venue_id` where the same location appears in both inventories. If asked for both, run each workflow separately, then offer a combined itinerary without conflating their scores.

## Evidence and quality rules

- Cite credible sources for historical claims and present-day operating facts. Confirm opening hours, ticket prices, maintenance status, addresses, and access using recent/official sources; disclose stale or unknown details.
- Never invent businesses, prices, coordinates, opening times, official ratings, or availability.
- Scoring is reproducible **editorial judgment**, not objective measurement. Show the five ratings on request, including the assumed traveler profile.
- Preserve religious etiquette and site access constraints; don't presume working places of worship are museums.
- Use full descriptive category names everywhere (including CSV). Never assign a single-letter category code.
- Mark candidates as `candidate`, `evaluated`, `needs_verification`, or `out_of_scope` as applicable.

## References

- `references/categories-and-scoring.md` — authorized full category names, tie-break rules, five scoring dimensions and formula. Read when categorizing or scoring.
- `references/output-contract.md` — deliverable structure, inventory fields and QA checks. Read when producing tabular or machine-readable deliverables.
- `assets/attraction_inventory_template.csv` — research data schema.
- `assets/samarkand_starter.csv` — example candidate entries, **not** a verified ranking.
- `references/mapping-and-mymaps.md` — required when generating or requesting a map; My Maps import, coordinate provenance, optional native maps and combined-layer caveats.
- `scripts/export_pins.py` — sourced GeoJSON + automatic `attractions_mymaps.csv` + review report.
- `scripts/combine_mymaps.py` — optional shared-place merge of independently generated attraction and dining layers.
- `scripts/score_and_validate.py` — optional standard-library CSV scorer and category validator. Execute only if Python/file tools are available.