mattrguerra/meridian-skillsmainPrivate on GitHub, published here in full

SKILL.md

Language Markdown11.4 KB235 lines

skills/category-page-filter/SKILL.md

  1. ---
  2. name: category-page-filter
  3. description: >-
  4. Build interactive category page filter sidebars from a product category URL. Use this skill when
  5. asked to create, design, or document filters for an ecommerce or product category page. Triggers
  6. include: "build filters for this category", "create a filter sidebar", "what filters should this
  7. page have", or any request involving a product URL and filter/facet UI. The skill covers the full
  8. process: fetching and analyzing the URL, selecting the right 4-6 filters from a standard taxonomy,
  9. writing the filter labels with sub-labels, and rendering an interactive HTML widget with checkbox
  10. state, active tags, clear-all, and collapsible sections.
  11. license: Internal use, Meridian Display Co.
  12. ---
  13. This skill documents the end-to-end process for building interactive category page filter sidebars from a product category URL. It covers research, filter selection, label writing, and widget implementation.
  14. The user provides a category page URL (and optionally a buying guide URL or reference screenshot). The output is a fully interactive filter sidebar widget rendered inline in chat, plus a clear rationale for every filter chosen.
  15. ---
  16. ## Step 1: Fetch and Analyze the Category URL
  17. Use `web_fetch` on the provided URL. Extract:
  18. - **Product names and count:** how many SKUs are on the page?
  19. - **Key differentiating attributes:** what varies most across products? (size, material, price, features, turnaround)
  20. - **Price range:** lowest and highest prices listed
  21. - **Turnaround times:** are rush options mentioned?
  22. - **Product subcategories:** are there named sub-types or tiers?
  23. - **Technical specs:** pixel pitch, material weight, dimensions, etc.
  24. If a buying guide URL is also provided, fetch it too. Buying guides reveal the **customer's decision sequence** (which questions they ask first), and that should directly inform filter ordering and label language.
  25. **Key insight:** The category page tells you *what* exists. The buying guide tells you *how customers think about it*. Use both.
  26. ---
  27. ## Step 2: Select 4-6 Filters
  28. Target **4-6 filters per category page**, never more than 10. Use this standard taxonomy as a starting point, then adapt to the specific category:
  29. | # | Filter Type | Notes |
  30. |---|---|---|
  31. | 1 | **Size / Width / Height / Space** | Use the most relevant dimension for the category. Frame as ranges, not exact values. |
  32. | 2 | **Price range** | Always category-specific brackets. Anchor to actual product prices on the page. |
  33. | 3 | **In-hand date / Turnaround** | Standard ranges: Rush (1-4 days), 4-5 days, 6-10 days, 11+ days. Adjust rush label based on what the category actually supports. |
  34. | 4 | **Material** | Only include if it meaningfully affects the buying decision (e.g. fabric vs. vinyl, LED vs. SEG). Skip if all products use the same material. |
  35. | 5 | **Product type / Model tier** | Use when subcategories exist within the page (e.g. Premium vs. Standard, Backlit vs. Lightbox). |
  36. | 6 | **Critical feature** | One binary or multi-option feature that is category-specific and high-impact for the decision (e.g. poles visible vs. hidden, single vs. dual sided, LED backlit vs. not). |
  37. ### Filter selection rules:
  38. - **Less is more.** A 7-product page needs 4-5 filters, not 10.
  39. - **Skip filters where all products are the same.** If every product ships in 4-5 days, don't show an in-hand filter.
  40. - **Prefer outcome-framing over spec-framing.** "Clean full-graphic look" beats "poles hidden." "Photo-ready seamless" beats "9oz polyester fabric."
  41. - **Pixel pitch and other technical specs** belong on LED/video wall categories only, paired with plain-English context (viewing distance, use case).
  42. - **Never add a filter for accessories or add-ons** unless the page explicitly mixes accessories and primary products.
  43. ---
  44. ## Step 3: Write Filter Labels and Sub-labels
  45. Every filter option should have:
  46. 1. **A primary label:** short, scannable, 1-5 words
  47. 2. **A sub-label** (optional but recommended for technical or unfamiliar options): one sentence explaining what it means or when to choose it
  48. ### Label writing principles:
  49. - **Frame around the customer's question, not the spec.** A customer doesn't think "I need 3.9mm pixel pitch." They think "I need something for a large outdoor booth." Translate specs into situations.
  50. - **Use the buying guide's own language** when available. If the guide says "most popular size for photo ops," use that phrase.
  51. - **For size filters**, describe the use case alongside the measurement: `8ft-10ft wide: Most popular, ideal for photo ops and entrances`
  52. - **For material filters**, call out the practical difference: `Fabric: poles fully hidden` vs. `Vinyl: side poles visible`
  53. - **For model tier filters**, lead with the differentiating outcome: `Premium: 5-year hardware warranty, poles hidden` vs. `Standard: budget-friendly, 1-year warranty`
  54. - **For price filters**, use clean round-number brackets anchored to actual prices. Don't invent brackets that no product falls into.
  55. ### Outcome-framing examples (step and repeat backdrops):
  56. | Spec language ❌ | Outcome language ✓ |
  57. |---|---|
  58. | Poles visible | Classic step & repeat look (poles visible) |
  59. | Poles hidden | Clean full-graphic look (poles hidden) |
  60. | 9oz polyester fabric | Fabric: matte, wrinkle-resistant, seamless |
  61. | 13oz vinyl | Vinyl: vibrant color, easy-clean |
  62. | Premium model | Premium: 5-year warranty, poles fully hidden |
  63. ---
  64. ## Step 4: Determine Filter Ordering
  65. Order filters by **decision priority**: the question the customer asks first goes on top.
  66. General ordering logic:
  67. 1. **Type or size:** the first cut (what kind of product, how big)
  68. 2. **Key differentiating feature:** what makes products meaningfully different within the type
  69. 3. **Material:** if it affects look, durability, or price significantly
  70. 4. **Price range:** usually mid-priority, since customers narrow by type before price
  71. 5. **In-hand date:** usually last, since only urgent customers filter by this first
  72. **Exception:** If urgency is the primary driver (e.g. rush event products), move in-hand date to position 2 or 3.
  73. ---
  74. ## Step 5: Assign Product Counts
  75. Every filter option should show a product count badge. These serve two purposes:
  76. 1. Tell customers how many results they'll see before clicking
  77. 2. Prevent zero-result dead ends
  78. **For real implementations:** pull counts from the product catalog database filtered by that attribute value.
  79. **For prototypes/mockups:** assign plausible counts based on the number of products on the page, distributed across options. Ensure no option shows 0. If a value maps to zero products, remove it from the filter entirely.
  80. ---
  81. ## Step 6: Build the Interactive Widget
  82. Render the filter as an HTML widget using the `show_widget` tool. The widget must include:
  83. ### Required UI elements:
  84. - **Section headers** with collapse/expand chevron toggle
  85. - **Checkboxes** for each filter option with product count badge
  86. - **Active filter tags** bar above the filters, showing selected filters as removable pills
  87. - **Clear all** button that appears in the tags bar when any filter is selected
  88. - **Result count / summary** that updates to show "X filters applied" when active
  89. ### Required interactions:
  90. - Clicking a checkbox adds it to active tags and increments the selected count on the section header
  91. - Clicking × on a tag deselects the corresponding checkbox
  92. - Clear all resets all checkboxes and clears all tags
  93. - Section headers collapse/expand the option list independently
  94. ### CSS variables to use (theme-aware):
  95. ```css
  96. var(--color-text-primary) /* main labels */
  97. var(--color-text-secondary) /* sublabels, counts */
  98. var(--color-text-tertiary) /* count badges, notes */
  99. var(--color-text-info) /* selected count highlight on section header */
  100. var(--color-background-secondary) /* count badge backgrounds, notes */
  101. var(--color-border-tertiary) /* section dividers */
  102. var(--color-border-secondary) /* tag borders */
  103. var(--font-sans) /* font family */
  104. ```
  105. ### Widget code template structure:
  106. ```html
  107. <style>/* scoped styles using CSS vars */</style>
  108. <div class="sidebar">
  109. <div class="filters-label">
  110. Filters
  111. <span class="result-summary" id="result-count">Showing all products</span>
  112. </div>
  113. <div class="active-filters" id="active-tags"></div>
  114. <div id="filter-sections"></div>
  115. </div>
  116. <script>
  117. const filtersData = [
  118. {
  119. id: "unique-id",
  120. label: "Filter section label",
  121. note: "Optional helper note shown at bottom of options",
  122. options: [
  123. { value: "value-key", label: "Primary label", sublabel: "One sentence description", count: N },
  124. ]
  125. },
  126. // ... more sections
  127. ];
  128. // State management, render functions, event handlers
  129. </script>
  130. ```
  131. ### Optional enhancements:
  132. - **Visual scale bar:** for numeric ranges like pixel pitch, a gradient bar from "fine/close" to "coarse/far" helps orient customers
  133. - **Section notes:** a small italic note at the bottom of a filter section for important context (e.g. "All adjustable frames range 6-10ft; extension kit adds 2ft increments")
  134. - **Sub-labels on options:** strongly recommended for any technical spec or unfamiliar product attribute
  135. ---
  136. ## Step 7: Write the Rationale
  137. After rendering the widget, briefly explain:
  138. 1. Which filters were chosen and why (1 sentence each)
  139. 2. Which filters were deliberately skipped and why
  140. 3. Any category-specific decisions (e.g. why size is framed by use case rather than inches)
  141. This rationale helps the team validate the logic before implementation and makes the reasoning transparent for stakeholders.
  142. ---
  143. ## Full Example Walkthrough
  144. **Input:** `https://meridiandisplay.example/step-and-repeat-backdrops/` + buying guide URL
  145. **Research findings:**
  146. - 7 products (including 1 extension kit accessory)
  147. - Size range: adjustable 6-10ft wide, fixed 8x8ft and 10x10ft
  148. - Two models: Premium (fabric, poles hidden, 5-year warranty) and Standard (vinyl, poles visible, 1-year warranty)
  149. - Price range: ~$350-$1,200+
  150. - Buying guide decision sequence: event type → size → material/model → accessories
  151. **Filters selected (5):**
  152. 1. Backdrop width, framed as event use cases (small/medium/large)
  153. 2. Model tier: Premium vs. Standard vs. Fixed size vs. Extension kit
  154. 3. Graphic material: Fabric (poles hidden) vs. Vinyl (poles visible)
  155. 4. Price range: $0-600 / $600-900 / $900-1200 / $1200+
  156. 5. In-hand date: Rush / 4-5 / 6-10 / 11+ days
  157. **Filters skipped:**
  158. - Shape: all products are rectangular, so there is no variation
  159. - Single/double sided: not applicable to backdrops
  160. - Features: too few products to justify a features filter
  161. **Label decisions:**
  162. - Width options include use-case sublabels taken from the buying guide verbatim ("Most popular: photo ops, entrances, sponsor walls")
  163. - Material options describe the pole-visibility outcome, not the material weight ("poles fully hidden" vs. "side poles visible")
  164. - Model tier leads with the warranty and visual outcome, not the tier name
  165. ---
  166. ## Quick Reference Checklist
  167. Before delivering the filter widget, verify:
  168. - [ ] Fetched the category URL (and buying guide if available)
  169. - [ ] Counted the products on the page
  170. - [ ] Selected 4-6 filters from the taxonomy
  171. - [ ] Skipped filters where all products are identical
  172. - [ ] Used outcome-framing language, not spec-only labels
  173. - [ ] Added sub-labels to any technical or unfamiliar options
  174. - [ ] Ordered filters by customer decision priority
  175. - [ ] Assigned plausible product counts to every option
  176. - [ ] Built widget with: checkboxes, active tags, clear-all, collapse/expand, count badges
  177. - [ ] Wrote rationale explaining inclusions and exclusions