{"id":25780,"plugin_id":"plugin_asdk_app_6aa8203d5a04819195420ba31e115000","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-02T00:28:39.312Z","digest":"ac21914173b579041a6fef00d969a0d42b97d8fc95c1a69e8d75183c472334e5","against":null,"payload":{"name":"rei-data-visualization","description":"Guidance for visualizing Advan REI data as charts, graphs, and maps within Reina's responses. Use this skill whenever Reina is about to produce any chart, graph, or visual representation of REI data — traffic trends, demographic breakdowns, rankings, visit patterns by hour or day, or trade area maps. Also use when the user explicitly asks to \"chart\", \"graph\", \"visualize\", \"show me a chart of\", or \"map\" any REI data. Always read this skill before writing visualization code or choosing a chart type for REI data.\n","included_files":[],"skill_md_contents":"---\nname: rei-data-visualization\ndescription: >\n  Guidance for visualizing Advan REI data as charts, graphs, and maps within\n  Reina's responses. Use this skill whenever Reina is about to produce any\n  chart, graph, or visual representation of REI data — traffic trends, demographic\n  breakdowns, rankings, visit patterns by hour or day, or trade area maps.\n  Also use when the user explicitly asks to \"chart\", \"graph\", \"visualize\",\n  \"show me a chart of\", or \"map\" any REI data. Always read this skill before\n  writing visualization code or choosing a chart type for REI data.\n---\n\n# REI Data Visualization\n\nThis skill governs how Reina visualizes data from REI queries. It covers\nwhen to visualize, what format to produce, how to style output, and which\nchart type fits each data type.\n\n---\n\n## Step 1: Read the Design System\n\nBefore writing any visualization code, read the `advan-rei-design-system`\nskill. It defines the color palette, typography, dark theme, component\npatterns, and spacing that all REI visualizations must follow. This skill\nadds chart-specific guidance on top of that foundation — it does not\nreplace it.\n\n---\n\n## Step 2: Decide Whether to Visualize\n\nNot everything warrants a chart. Use this as a guide:\n\n**Visualize when:**\n- Showing a trend over time (traffic by month, YoY comparison)\n- Comparing a property or tenant across multiple peers simultaneously\n- Displaying a distribution (demographics by income band, visits by hour)\n- The pattern or shape of the data is the point — not just a single number\n- The user explicitly asks for a chart or visualization\n\n**Use a table instead when:**\n- Exact values matter more than the pattern (a benchmarking summary, a\n  ranked list of properties with specific metrics)\n- There are fewer than four data points — a chart adds visual overhead for\n  little gain\n- The user is likely to copy figures into another document or report\n\n**Use prose instead when:**\n- The finding can be stated in one clear sentence\n- There is only one data point or metric being communicated\n- A chart would slow the user down, not help them\n\nWhen in doubt, lead with the answer in prose and offer to chart it.\n\n---\n\n## Step 3: Choose the Output Format\n\n**HTML artifact (interactive):** Use when the user is exploring data in a\nconversation, the chart benefits from hover states or tooltips showing exact\nvalues, or the output is a standalone deliverable they'll reference during\nthe session.\n\n**Static image (SVG or PNG):** Use when the user asks to export, wants to\ninclude the chart in a report or presentation, or the context is clearly\na one-time view rather than an interactive reference.\n\nWhen the request is ambiguous, default to HTML. If the user later wants to\nexport, offer the static version.\n\n---\n\n## Step 4: Chart Type by Data Type\n\n### Traffic Trend Lines\n\n**Use:** Line chart with time on the x-axis and visit count on the y-axis.\n\n- Plot monthly data points as the default granularity. Offer weekly if the\n  user wants a more granular view or is analyzing a short date range.\n- If showing YoY, use two lines (current period vs. prior period) in\n  distinct colors from the design system palette.\n- Mark notable events directly on the chart when they're known — anchor\n  closures, renovations, seasonal peaks — as labeled vertical reference lines.\n- Always show the data range in the chart subtitle, not just the title.\n- Don't start the y-axis at zero if the variation is small relative to the\n  absolute level — truncate to show the trend clearly, but label the axis\n  origin so the user knows.\n\n### Demographic Breakdowns\n\n**Use:** Horizontal bar chart for ranked categories (income bands, age\ncohorts, lifestyle segments). Donut or pie chart only for simple two- or\nthree-part compositions (e.g., a dominant segment vs. all others) — never\nfor more than five slices.\n\n- Order bars by value descending unless the categories have a natural order\n  (age cohorts, income bands) — in those cases preserve the natural order.\n- For income and age, show the full distribution rather than just the top\n  segment. The shape of the distribution matters.\n- For lifestyle/psychographic segments, label each bar with the segment name\n  and its share percentage. Don't abbreviate segment names — users need to\n  read them.\n- When comparing the subject property's demographics to a retailer footprint\n  or market benchmark, use a grouped bar chart with two bars per category\n  (subject vs. benchmark) in the design system's primary comparison colors.\n\n### Rankings and Peer Comparisons\n\n**Use:** Horizontal bar chart with properties or tenants on the y-axis and\nthe metric on the x-axis. Horizontal orientation makes property names\nreadable without rotation.\n\n- Highlight the subject property in the design system's accent color. All\n  other bars use the secondary palette.\n- Sort by metric value descending unless rank order itself is the point, in\n  which case sort by rank.\n- If showing multiple metrics for the same set of properties (visits + dwell\n  + frequency), use a small multiples layout — one chart per metric — rather\n  than trying to combine everything into one cluttered view.\n- Label the subject property bar explicitly even if it's obvious from\n  position.\n\n### Visit Patterns by Hour and Day\n\n**Use:** Heatmap as the default when showing both hour and day simultaneously.\nUse a bar chart when showing only one dimension (hour of day only, or day\nof week only).\n\n- For heatmaps: days of week on the y-axis (Monday top to Sunday bottom),\n  hours on the x-axis (midnight to midnight). Use the design system's\n  sequential color scale — light for low traffic, saturated for peak.\n- For single-dimension bar charts: show all hours or all days, don't\n  truncate to only the peak window.\n- When comparing a subject site to a retailer footprint, overlay or\n  side-by-side the two heatmaps. Label clearly which is which.\n- Always note the time zone the data reflects.\n\n### Trade Area Maps\n\nTrade area maps showing visitor origin geography are best rendered natively\nin the REI platform's map view, which has the geographic rendering\ninfrastructure Reina does not replicate. When a user asks for a trade area\nmap:\n\n1. Direct them to the trade area map view in REI for the full interactive\n   rendering.\n2. If a visual summary is needed in the conversation, produce a simplified\n   schematic — a center point with annotated concentric rings labeled with\n   the percentage of visitors captured at each radius or drive time band.\n   This is not a map, but it communicates the catchment structure clearly\n   without requiring geographic rendering.\n3. If the user explicitly wants a rendered map artifact, use a lightweight\n   mapping library (e.g., Leaflet.js via CDN) in an HTML artifact. Plot the\n   property location and shade the trade area polygon if coordinate data\n   is available. Use the design system's color palette for the shading.\n\n---\n\n## Step 5: Standardized Table Patterns\n\nREI uses three distinct table types, each with precise visual specifications. Match the table type to the data being presented.\n\n---\n\n### Data / Metrics Table\n\nUse for: foot traffic summaries, dwell time, visit frequency, retailer footprint comparisons, site selection scorecards — any tabular output where rows are metrics and columns are properties or geographies.\n\n**Structure:**\n- Header row: background `#26326E`, font-size 13px, font-weight regular (not bold), white text\n- Data rows: background `#162465`, border-bottom `1px solid #28325F`, font-size 12.5px\n- First column (metric label): `var(--gray-light)` text color, lighter font weight — this is the label column, not a data column\n- Value columns: each property's value is presented inside a colored value box (see below)\n- Corner cells: header row first cell gets border-radius top-left 7px; last cell gets top-right 7px\n\n**Value boxes:**\nWhen a table compares multiple properties, each property's values appear inside small inline colored boxes rather than as plain text. The color identifies which property:\n- P1 (cyan): background `#17AAB3`\n- P2 (violet): background `#713DC5`\n- P3 (green): background `#17B36A`\n- P4 (pink): background `#DB2988`\n\nFor single-property tables (one location, no comparison), omit value boxes — show plain white text values.\n\n**Legend bar (when comparing multiple properties):**\nBelow the table, a legend strip maps each property's color to its name. Legend label background uses the widget blue (`#162465`); each legend cell uses a muted version of the property color.\n\n**When to use:** Foot traffic summaries, dwell/frequency metrics, retailer footprint comparisons, site selection scorecards, co-tenancy health checks.\n\n---\n\n### Ranking Table\n\nUse for: benchmarking results, performer lists, any table where rows are properties and the primary data point is a rank or ranked metric.\n\n**Structure:**\n- Header row: background `#26326E`, border `1px solid #2D3A78`, row height 32px\n- Data rows: background `#162465`\n- Each row's rank badge has a left vertical color bar (3px wide): green `#76B723` for strong performers, red `#FF151F` for weak performers\n- Rank is expressed as \"X of Y\" (e.g., \"3 of 47\") — always show the total count\n- Property cell contains: logo circle icon + property name (font-weight 500, 12px) + address (gray-light, 10px) + square footage (neutral gray, 9px)\n\n**Change indicators (YoY):**\nWhen showing year-over-year change alongside rank:\n- Positive: green dot + upward arrow + percentage (e.g., `▲ +8.3%`)\n- Negative: red dot + downward arrow + percentage (e.g., `▼ −4.1%`)\n- Flat/neutral: gray dot + em dash\n\n**Rank cards (summary view):**\nWhen a single rank needs to be called out prominently rather than in a table row, use a rank card: `rgba(255,255,255,0.05)` background (glass), the rank value large, \"X of Y\" in smaller text below, a colored bar beneath the value.\n\n**When to use:** Market ranking outputs, competitor benchmarking, performer lists, any output from the `ranking` or `performers-list` endpoints.\n\n---\n\n### Demographics Table\n\nUse for: trade area demographic breakdowns across geographies (trade area, 1/3/5 mile rings, drive time bands).\n\n**Structure:**\n- Column headers: background `#26326E`, all-caps label, gray-light for the variable column header, white for geography columns\n- Category headers (grouping rows like \"Summary\", \"Household Income\", \"Age\"): background `#1A2B7B`, full-width span, white text\n- Data rows: alternate between `#131E58` and `#132C61`\n- First column (variable label): left-aligned, gray-light text\n- Primary geography column (trade area or subject): value text highlighted in property color (e.g., cyan for P1)\n- Comparison geography columns (1 mi, 3 mi, 5 mi): plain white text values\n\n**Column header order:**\nVARIABLES → TRADE AREA (or primary geography) → 1 MI → 3 MI → 5 MI (or drive time bands, following whatever geographies were selected).\n\n**When to use:** Any output from the `demography` or `demography-categories` endpoints. Demographics comparisons in the retailer footprint workflow. Trade area analysis demographic breakdowns.\n\n---\n\n### Choosing the Right Table\n\n| Data Type | Table Pattern |\n|-----------|--------------|\n| Foot traffic metrics, dwell, frequency, YoY | Data / Metrics Table |\n| Multi-property comparison (same metric) | Data / Metrics Table with value boxes |\n| Rankings, benchmarking, performer lists | Ranking Table |\n| Demographic breakdowns by geography | Demographics Table |\n| Retailer footprint comparison | Data / Metrics Table |\n| Void analysis candidate list | Data / Metrics Table (plain, no value boxes) |\n\n---\n\n## Step 6: Universal Chart Standards\n\nThese apply to every visualization regardless of type:\n\n- **Title:** Short and specific — name the property, metric, and date range.\n  \"Riverside Commons — Monthly Visits, Jan–Dec 2024\" not \"Traffic Trend.\"\n- **Subtitle or caption:** Data vintage and source. \"Advan mobile device\n  panel\" and the date range if not in the title.\n- **Axis labels:** Always labeled, never omitted. Include units (visits,\n  minutes, %).\n- **Tooltips:** In HTML artifacts, always show exact values on hover — don't\n  make the user estimate from the chart.\n- **Legend:** Only when there are two or more series. Single-series charts\n  don't need a legend.\n- **Gridlines:** Light, unobtrusive. Horizontal only unless the chart type\n  genuinely benefits from vertical gridlines.\n- **Annotations:** Use them. A well-placed label explaining a spike or drop\n  is more useful than leaving the user to wonder.\n- **No 3D effects, gradients on bars, or decorative elements** that don't\n  carry data meaning. The design system's aesthetic is clean and data-forward.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}