Smart Store Site Selection Engine

Problem

Store-site selection prompts often start with "I want to open a store in this district" but may lack customer-segment positioning and operating strategy. Without those constraints, coordinate picks and business-area judgments can become generic. This skill turns such requests into a repeatable workflow: validate commercial parameters first, fetch a small set of coordinates, then hand off to a Python engine for data lookup, scoring, and report rendering, reducing model hallucination of transit, competitor, or facility counts.

How It Works

• Phase A: hard parameter stop. The context must include core customer-segment positioning and store operating strategy, such as takeaway-focused kiosk versus experience-driven flagship, and target audience such as students, residents, or business professionals. If either is missing, it asks follow-up questions and ends the turn.
• Phase B: lightweight coordinate fetching. It uses AMAP POI to retrieve the Top 3 matching location names and center coordinates only, without querying office buildings, transit stops, competitor counts, or other detailed metrics.
• Phase C: business insight generation. It produces an approximately 100-word macro market tone and about 50 words of pros and cons for each of the three business areas.
• Phase D / E: handoff and delivery. Coordinates, location names, and generated text are passed to a Python engine for concurrent data collection, scoring, micro-format radar generation, and single-file HTML report layout.

Boundaries

It is suitable for moving store-location requests from vague needs to coordinate-level candidates and structured business text. It is not intended for utility or power infrastructure checks, nor for the model to directly calculate scores or query competitor details. It depends on AMAP_WEBSERVICE_KEY and AMAP POI capability, with final report format and naming constrained by the skill.