agentleFS
xiongxianfeixiongxianfei/skillsmith/skills/city-attraction-research/SKILL.md

city-attraction-research

Skill2 starsChanged 7 months agoMITView on GitHub

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.

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create an evidence-grounded *inventory first*, then a ranked shortlist and optional itinerary.

    line 10
  2. Distinctive:

    Review: After travel, retain objective historical attributes and revisit subjective scores, actual duration, closures, and enjoyment notes.

    line 47
  3. Distinctive:

    When a user asks to select and schedule from this inventory, preserve its independent scores and hand the ranked records to City Itinerary …

    line 53
  4. Distinctive:

    Never invent businesses, prices, coordinates, opening times, official ratings, or availability.

    line 62
  5. Distinctive:

    Use full descriptive category names everywhere (including CSV).

    line 65

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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. 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 before any map export or native-map request; see the output contract 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 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.