climaybe 1.7.3 → 1.8.1

package/src/cursor/rules/tailwindcss-rules.mdc

@@ -0,0 +1,410 @@
+---
+description: Tailwind CSS and theme token standards for Liquid and theme styles. Static classes only, semantic tokens from _styles/02_base/02.02_colors.css, content sources in _styles/main.css.
+globs:
+  - "**/*.liquid"
+  - "_styles/**/*.css"
+  - "assets/*.css"
+alwaysApply: false
+---
+# Tailwind CSS Development Rules
+
+Apply when editing Liquid templates or theme CSS that use Tailwind classes or theme tokens. Use semantic tokens (surface, subtle, emphasis, accent, text-primary, border-secondary) from this project's `@theme`; see `_styles/02_base/02.02_colors.css`.
+
+## Core Principles
+
+### 1. Static Class Generation
+**CRITICAL**: Never combine Tailwind classes with Liquid variables or dynamic values.
+
+**Why this matters:**
+- Tailwind CSS scans unparsed files during build time to generate CSS
+- Liquid parsing happens on Shopify servers, not during local builds
+- Tailwind cannot see the final rendered HTML with dynamic values
+- This means dynamic classes like `duration-{{ animation_duration }}` will NOT work
+
+**❌ Bad Examples:**
+```liquid
+<!-- These will NOT work - Tailwind can't see the dynamic values -->
+<div class="duration-{{ animation_duration }}">
+<div class="w-{{ width }}">
+<div class="text-{{ color }}">
+<div class="bg-{{ background_color }}">
+```
+
+**✅ Good Examples:**
+```liquid
+<!-- Use static Tailwind classes -->
+<div class="duration-300">
+<div class="w-full">
+<div class="text-blue-600">
+<div class="bg-gray-100">
+
+<!-- Or use conditional classes -->
+<div class="{% if show_animation %}duration-300{% else %}duration-0{% endif %}">
+<div class="{% if size == 'sm' %}w-1/2{% else %}w-full{% endif %}">
+```
+
+### 2. Conditional Class Application
+Use conditional statements to apply different static classes:
+
+```liquid
+<!-- ✅ Good: Conditional static classes -->
+<div class="{% if expanded %}bg-blue-100{% else %}bg-gray-50{% endif %}">
+<div class="{% if size == 'sm' %}text-sm{% else %}text-base{% endif %}">
+<div class="{% if show_animation %}transition-all duration-300{% else %}transition-none{% endif %}">
+```
+
+### 3. Custom CSS for Dynamic Values
+For truly dynamic values, use custom CSS classes:
+
+```liquid
+<!-- ✅ Good: Custom CSS for dynamic values -->
+<style>
+  .duration-custom { transition-duration: var(--custom-duration); }
+  .width-custom { width: var(--custom-width); }
+</style>
+
+<div class="duration-custom" style="--custom-duration: {{ animation_duration }}ms">
+<div class="width-custom" style="--custom-width: {{ width }}%">
+```
+
+## Class Organization
+
+### 1. Logical Grouping
+Group related classes together in a logical order:
+
+```liquid
+<!-- ✅ Good: Logical grouping -->
+<div class="
+  flex items-center justify-between
+  p-4 m-2
+  bg-white border border-gray-200 rounded-lg
+  hover:bg-gray-50 focus:ring-2 focus:ring-blue-500
+  transition-colors duration-200
+">
+```
+
+### 2. Responsive Design
+Use responsive prefixes consistently:
+
+```liquid
+<!-- ✅ Good: Responsive design -->
+<div class="
+  w-full md:w-1/2 lg:w-1/3
+  text-sm md:text-base lg:text-lg
+  p-2 md:p-4 lg:p-6
+">
+```
+
+### 3. State Classes
+Group state-based classes together:
+
+```liquid
+<!-- ✅ Good: State classes grouped -->
+<button class="
+  px-4 py-2 rounded
+  bg-blue-600 text-white
+  hover:bg-blue-700 focus:bg-blue-700
+  focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2
+  disabled:opacity-50 disabled:cursor-not-allowed
+  transition-colors duration-200
+">
+```
+
+## Performance Best Practices
+
+### 1. Content Source Configuration
+Tailwind v4 content sources are in `_styles/main.css`. All template and asset paths are scanned for class names:
+
+```css
+/* _styles/main.css */
+@import "tailwindcss" source(none);
+@plugin "@tailwindcss/typography";
+@source "../assets/*.js";
+@source "../assets/!(style).css";
+@source "../layout/*.liquid";
+@source "../blocks/*.liquid";
+@source "../sections/*.liquid";
+@source "../snippets/*.liquid";
+@source "../templates/*.liquid";
+```
+
+Token imports: `01_theme/01_primitives.css`, `02_base/02.01_sizes.css`, `02_base/02.02_colors.css`, `02_base/02.03_typography.css`. Any file that uses Tailwind classes must be covered by these `@source` paths so classes are not purged.
+
+### 2. Avoid Arbitrary Values
+Prefer predefined Tailwind classes over arbitrary values:
+
+```liquid
+<!-- ❌ Bad: Arbitrary values -->
+<div class="w-[123px] h-[456px]">
+
+<!-- ✅ Good: Predefined classes -->
+<div class="w-32 h-40">
+```
+
+### 3. Use CSS Custom Properties
+For dynamic values, use CSS custom properties defined in `_styles/main.css` and imported token files (`01_primitives.css`, `02.02_colors.css`, etc.).
+
+## Color System (Theme Tokens)
+
+### 1. Primitives and semantic tokens
+- **Primitives**: `_styles/01_theme/01_primitives.css` — raw colors (e.g. `--color-dune-50`, `--color-abbey-950`).
+- **Semantic tokens**: `_styles/02_base/02.02_colors.css` — background, text, border tokens used by Tailwind utilities.
+
+### 2. Semantic token names (this project)
+Background: `--background-color-surface`, `--background-color-subtle`, `--background-color-emphasis`, `--background-color-accent`.  
+Text: `--text-color-primary`, `--text-color-secondary`, `--text-color-on-accent`, `--text-color-on-accent-sec`.  
+Border: `--border-color-primary`, `--border-color-secondary`, `--border-color-on-accent`, `--border-color-on-accent-sec`.
+
+Tailwind generates classes from these (e.g. `bg-surface`, `bg-subtle`, `text-primary`, `text-on-accent`, `border-primary`, `border-secondary`). Gradients: `--background-image-gradient-surface`, `-subtle`, `-emphasis`, `-contrast`.
+
+### 3. Using theme colors in Liquid
+Prefer semantic utility classes; use arbitrary values only when no token exists:
+
+```liquid
+<!-- Prefer: semantic classes from @theme -->
+<div class="bg-surface text-primary border border-secondary">
+<div class="bg-subtle text-secondary">
+<div class="bg-accent text-on-accent">
+<div class="border-primary">
+
+<!-- Optional: arbitrary value from a token -->
+<div class="bg-[hsl(var(--background-color-emphasis))]">
+```
+
+### 4. Color schemas (@utility)
+Sections can switch palette via `@utility` classes: `color-schema-primary`, `color-schema-secondary`, `color-schema-muted`, `color-schema-accent-1`, `color-schema-accent-2`, `color-schema-accent-3`, `color-schema-contrast`. Apply to a wrapper (e.g. section root) so children inherit semantic tokens. See `_styles/02_base/02.02_colors.css`.
+
+## Design-Focused Accessibility
+
+### 1. Contextual Focus States
+Use design-appropriate focus indicators instead of generic rings:
+
+```liquid
+<!-- ✅ Good: Input with border focus -->
+<input class="
+  border border-secondary
+  focus:border-primary focus:outline-none
+  transition-colors duration-200
+">
+
+<!-- ✅ Good: Summary with background focus -->
+<summary class="
+  bg-white hover:bg-emphasis
+  focus:bg-emphasis focus:outline-none
+  transition-colors duration-200
+">
+
+<!-- ✅ Good: Button with ring focus (appropriate for buttons) -->
+<button class="
+  bg-subtle text-on-accent
+  hover:bg-subtle/90
+  focus:outline-none focus:ring-2 focus:ring-primary focus:ring-offset-2
+  transition-colors duration-200
+">
+```
+
+### 2. Focus State Guidelines
+Choose focus indicators based on component context:
+
+- **Inputs/Form Fields**: Use `focus:border-primary` when parent has `border-secondary`
+- **Summary Elements**: Use `focus:bg-emphasis` for subtle background change
+- **Buttons**: Use `focus:ring-2 focus:ring-primary` for clear button focus
+- **Links**: Use `focus:underline` or `focus:text-primary` for text-based focus
+- **Cards/Containers**: Use `focus:border-primary` or `focus:shadow-lg`
+
+### 3. Reduced Motion
+Respect user preferences using the theme's custom properties:
+
+```css
+/* _styles/main.css */
+@media (prefers-reduced-motion: reduce) {
+  .transition-all {
+    transition: none !important;
+  }
+}
+```
+
+### 4. High Contrast
+Support high contrast mode:
+
+```css
+/* _styles/main.css */
+@media (prefers-contrast: high) {
+  .border-gray-200 {
+    border-color: #000000 !important;
+  }
+}
+```
+
+## Component Patterns
+
+### 1. Atomic Components
+Use consistent patterns for atomic components:
+
+```liquid
+<!-- Button component pattern -->
+<button class="
+  inline-flex items-center justify-center
+  px-4 py-2 rounded-md
+  text-sm font-medium
+  bg-subtle text-on-accent
+  hover:bg-subtle/90 focus:bg-subtle/90
+  focus:outline-none focus:ring-2 focus:ring-primary focus:ring-offset-2
+  disabled:opacity-50 disabled:cursor-not-allowed
+  transition-colors duration-200
+  {{ class }}
+">
+  {{ content }}
+</button>
+```
+
+### 2. Layout Components
+Use consistent spacing and layout patterns:
+
+```liquid
+<!-- Container pattern -->
+<div class="
+  max-w-7xl mx-auto px-4 sm:px-6 lg:px-8
+  {{ class }}
+">
+  {{ content }}
+</div>
+```
+
+### 3. Form Components
+Use consistent form styling:
+
+```liquid
+<!-- Input pattern -->
+<input class="
+  block w-full rounded-md
+  border border-secondary
+  focus:border-primary focus:outline-none
+  disabled:bg-emphasis disabled:cursor-not-allowed
+  transition-colors duration-200
+  {{ class }}
+">
+```
+
+## Common Patterns
+
+### 1. Card Components
+```liquid
+<div class="
+  bg-subtle border border-secondary rounded-lg shadow-sm
+  hover:shadow-md transition-shadow duration-200
+  {{ class }}
+">
+  {{ content }}
+</div>
+```
+
+### 2. Navigation Items
+```liquid
+<a class="
+  block px-3 py-2 rounded-md text-sm font-medium
+  text-secondary hover:text-primary hover:bg-emphasis
+  focus:outline-none focus:bg-emphasis
+  transition-colors duration-200
+  {{ class }}
+">
+  {{ content }}
+</a>
+```
+
+### 3. Status Indicators
+```liquid
+<span class="
+  inline-flex items-center px-2.5 py-0.5 rounded-full text-xs font-medium
+  {{ status == 'success' ? 'bg-green-100 text-green-800' : '' }}
+  {{ status == 'error' ? 'bg-red-100 text-red-800' : '' }}
+  {{ status == 'warning' ? 'bg-yellow-100 text-yellow-800' : '' }}
+  {{ status == 'info' ? 'bg-blue-100 text-blue-800' : '' }}
+">
+  {{ content }}
+</span>
+```
+
+## Debugging Tips
+
+### 1. Class Verification
+Use browser dev tools to verify classes are applied correctly:
+
+```javascript
+// Check if classes are present
+console.log(element.className);
+```
+
+### 2. Purge Verification
+Ensure classes aren't being purged by checking the content sources in `_styles/main.css`:
+
+```bash
+# Check what classes are being purged
+npx tailwindcss --content ./**/*.liquid --output ./temp.css
+```
+
+### 3. Dynamic Class Debugging
+For conditional classes, add debugging:
+
+```liquid
+<!-- Debug conditional classes -->
+<div class="
+  {% if debug %}border-2 border-red-500{% endif %}
+  {{ conditional_classes }}
+">
+  <!-- Add debug output -->
+  {% if debug %}
+    <div class="text-xs text-gray-500">
+      Applied classes: {{ conditional_classes }}
+    </div>
+  {% endif %}
+</div>
+```
+
+## Theme Integration
+
+### 1. Tokens and custom properties
+Use semantic classes (e.g. `bg-surface`, `text-primary`) so styles stay within the token system. For one-off values, use theme variables from `_styles/01_theme/01_primitives.css` and `_styles/02_base/02.02_colors.css`. Typography and sizes: `_styles/02_base/02.01_sizes.css`, `02.03_typography.css`.
+
+### 2. Responsive breakpoints
+Use Tailwind breakpoints (e.g. `md:`, `lg:`) consistently; theme may define `--breakpoint-*` in `@theme`.
+
+### 3. Custom utilities
+Add custom utilities in `_styles/` (e.g. in a layer file imported by `main.css`):
+
+```css
+/* _styles/main.css */
+@layer utilities {
+  .text-balance {
+    text-wrap: balance;
+  }
+  
+  .hide-scroll-bar {
+    -ms-overflow-style: none;
+    scrollbar-width: none;
+  }
+  
+  .hide-scroll-bar::-webkit-scrollbar {
+    display: none;
+  }
+}
+```
+
+## Compliance Checklist
+
+Before committing any Tailwind CSS changes, ensure:
+
+- [ ] No dynamic Tailwind classes with Liquid variables
+- [ ] All conditional classes use static Tailwind values
+- [ ] Contextual focus states used (not generic rings everywhere)
+- [ ] Responsive design implemented correctly
+- [ ] Performance optimizations applied
+- [ ] Design-appropriate accessibility considerations addressed
+- [ ] Classes are logically grouped and organized
+- [ ] Custom CSS used for truly dynamic values
+- [ ] Content sources in `_styles/main.css` include all template files
+- [ ] No arbitrary values unless absolutely necessary
+- [ ] Theme custom properties used when appropriate
+- [ ] Custom utilities added to `_styles/main.css` when needed
+- [ ] Semantic tokens used (surface, subtle, emphasis, accent, text-primary, border-secondary) from `_styles/02_base/02.02_colors.css`
+- [ ] Focus states match component context and design

package/src/cursor/skills/accessibility-pass/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: accessibility-pass
+description: Runs an accessibility audit on a section, snippet, or component. Use when the user says "accessibility pass", "a11y audit", "check accessibility", "WCAG check", or "audit this section/snippet". Follows project accessibility rules.
+---
+
+# Accessibility Pass
+
+Runs a structured a11y audit on specified file(s) and reports findings with fix suggestions.
+
+## Rules to Apply
+
+Before auditing, read and apply:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/accessibility-rules.mdc` — WCAG 2.1 AA, semantic HTML, ARIA, keyboard, focus, screen readers
+
+## Workflow
+
+1. **Identify scope** — User specifies file(s) or "current file". If unspecified, ask or assume the file they have open.
+2. **Load rules** — Read `accessibility-rules.mdc` and use it as the checklist basis.
+3. **Audit** — Go through the file(s) and check:
+   - Semantic structure (headings, landmarks, lists)
+   - ARIA (only when needed; state sync with JS if applicable)
+   - Keyboard (focusable elements, tab order, visible focus, Escape/Enter/Space)
+   - Images (alt text; decorative with empty alt or aria-hidden)
+   - Forms (labels, errors, required)
+   - Links/buttons (descriptive text, no "click here")
+   - Dynamic content (live regions if content updates)
+4. **Report** — For each finding:
+   - Location (element or line)
+   - Issue (what’s wrong)
+   - WCAG criterion if relevant
+   - Suggested fix (concrete code or change)
+5. **Severity** — Label as Critical (blocks access), Suggestion (improvement), or Nice-to-have.
+
+## Output Format
+
+```markdown
+## Accessibility audit: [file path]
+
+### Critical
+- **[Element/location]** — [issue]. [Fix].
+
+### Suggestions
+- ...
+
+### Nice-to-have
+- ...
+```
+
+## Example Trigger
+
+User: "Run an accessibility pass on this section" (with `sections/product--main.liquid` open).  
+→ Audit that file against accessibility-rules.mdc and output the structured report.

package/src/cursor/skills/changelog-release/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: changelog-release
+description: Generates changelog or release notes from git history using project commit conventions. Use when the user says "changelog", "release notes", "what changed since last tag", or "list commits for release". Follows commit-rules types (feat, fix, refactor, etc.).
+---
+
+# Changelog / Release Notes
+
+Builds a changelog or release notes from commits since a ref (e.g. last tag), grouped by project commit types.
+
+## Rules to Apply
+
+When grouping and labeling commits, read and apply:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/commit-rules.mdc` — commit types (🔨 fix, 🚀 feat, ♻️ refactor, 🎨 style, etc.) and format
+
+Use the same type labels and emoji for changelog sections so the output matches how the team writes commits.
+
+## Workflow
+
+1. **Determine range** — Since last tag (e.g. `git describe --tags --abbrev=0` then `git log TAG..HEAD`), or since a branch/commit the user specifies. If unclear, default to "since last tag".
+2. **Get commits** — Run `git log --oneline [range]` (or with `--pretty=format:...` for message + body). Parse commit messages.
+3. **Group by type** — Map each commit to a type from commit-rules.mdc (fix, feat, refactor, style, remove, wip, docs, ai, chore, upgrade). Ignore merge commits. Put "unknown" or "other" for non-matching messages.
+4. **Format** — Output markdown:
+   - Optional title (e.g. "Changelog since v1.2.0")
+   - Sections by type (e.g. "## 🚀 Features", "## 🔨 Fixes")
+   - Under each section: list of commit descriptions (one line each, link to commit if desired). Strip emoji+type prefix for readability if you want, or keep for consistency.
+5. **Optional** — Add "Breaking changes" subsection if any commit message indicates breaking change (e.g. `!` or "BREAKING CHANGE").
+
+## Output Format
+
+```markdown
+# Changelog (since [ref])
+
+## 🚀 Features
+- add product quick view modal
+- implement infinite scroll for collections
+
+## 🔨 Fixes
+- resolve cart total calculation error
+- modal close button not working
+
+## ♻️ Refactor
+- optimize product card rendering
+```
+
+## Example Trigger
+
+User: "Generate changelog since last tag."  
+→ Resolve last tag, get `git log` since then, group by commit-rules types, output structured changelog.

package/src/cursor/skills/commit/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: commit
+description: Groups working-tree changes into logical commits and commits them using conventional commit rules (type, optional scope, subject; commitlint). Use when the user asks to commit, group commits, stage and commit, or write conventional commits.
+---
+
+# Commit (group + conventional)
+
+Group changes by purpose, then commit each group. A conventional message is optional; when the user provides or wants one, use the format below so commitlint and semantic-release stay happy.
+
+## Workflow
+
+1. **Inspect** — Get full picture of changes (git status, git diff).
+2. **Group** — Partition by type: feat, fix, docs, style, refactor, perf, test, build, ci, chore.
+3. **Commit each group** — If the user wants a message: type(scope): subject, imperative, lowercase, no period, ≤100 chars. If they don't, commit without message or with a minimal one (e.g. chore: wip).
+4. **Validate** — commit-msg hook may reject invalid messages when a message is used.
+
+## Message rules (commitlint, when a message is used)
+
+- **Types:** feat, fix, docs, style, refactor, perf, test, build, ci, chore.
+- **Header:** type(scope): subject — subject optional; max 100 chars when present. Body lines max 200.
+- **Imperative, present tense:** "add feature" not "added feature".
+
+## Examples
+
+feat(init): add store alias prompt
+fix(sync): prevent overwrite of unchanged files
+docs: add conventional commit section to CONTRIBUTING

package/src/cursor/skills/commit-in-groups/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: commit-in-groups
+description: Groups current working tree changes into logical commits and suggests commit messages per project convention. Use when the user says "/commit-in-groups", "commit in groups", "group my commits", "suggest separate commits", or "split my changes into commits". Follows commit-rules.mdc (emoji + type + description).
+---
+
+# Commit in Groups
+
+Analyzes uncommitted changes, groups them into logical commits, and suggests one message per group using the project's commit format.
+
+**Preference:** Prefer multiple commits unless changes are closely related. When in doubt, split into separate commits (e.g. tooling vs theme code, different features or areas). Only group into one commit when the changes clearly belong together (e.g. one feature and its snippet, or a single refactor touching several files for the same purpose).
+
+## Rules to Apply
+
+Before suggesting any commit messages, read and apply:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/commit-rules.mdc` — commit format (emoji + type + description), types (fix, feat, refactor, style, etc.), imperative mood, optional scope
+
+Use the exact format and types from commit-rules; no period at end; lowercase description.
+
+## Workflow
+
+1. **Get change summary** — Run `git status` and `git diff` (and `git diff --staged` if anything is staged). Identify all modified, added, and deleted files.
+2. **Group logically** — Prefer more, smaller commits when changes are unrelated. Cluster only when clearly the same intent:
+   - Unrelated areas (e.g. tooling/skills vs theme snippet, cart fix vs collection style) → separate commits
+   - One feature (e.g. new section + its snippet) → one commit
+   - Refactor in one area, fix in another → separate commits
+   - Locale/schema/docs can be separate if they form a clear unit
+   - When in doubt, split rather than combine
+3. **Assign type** — For each group, pick the best type from commit-rules (🔨 fix, 🚀 feat, ♻️ refactor, 🎨 style, 🗑️ remove, 📝 docs, 🔧 chore, etc.) and optional scope (e.g. `sections`, `cart`, `locales`).
+4. **Write messages** — One line per commit: `<emoji> <type>(scope): <description>`. Imperative, lowercase, no period. Multi-line body only if the change is complex and warrants bullets.
+5. **Output and execute** — List the suggested commits (message + files per commit), then **run the commits yourself**: for each group, run `git add` on the listed files and `git commit -m "..."` with the exact message. Do not only suggest commands; execute them so the working tree is left with the changes committed. Summarize what was committed at the end.
+
+## Output Format
+
+Show the plan briefly, then run it:
+
+```markdown
+## Suggested commits
+
+**Commit 1:** `🚀 feat(sections): add featured collection section`
+- `sections/s--featured-collection.liquid`
+- `snippets/m--product-card.liquid`
+
+**Commit 2:** `🎨 style(cart): adjust drawer spacing`
+- `sections/cart--drawer.liquid`
+- `assets/style.css`
+```
+
+Then execute: `git add` + `git commit` for each group in order. After running, confirm: "Done. Created N commits: …"
+
+## Example Trigger
+
+User: "/commit-in-groups" or "group my changes into separate commits."  
+→ Run git status/diff, group changes, list commits with messages and file lists, then **run** `git add` and `git commit` for each group (do not only suggest commands).

package/src/cursor/skills/linear-create-task/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: linear-create-task
+description: Creates Linear issues in the Voldt Redesign project with PRD-style descriptions. Use when the user says "create Linear task", "add Linear issue", "create task in Linear", "/linear-task", or describes a feature/fix and asks to put it in Linear. Assigns to Berk (coding) or Taha (design). Supports attaching images/videos to the issue and using them to enrich the PRD. Uses user-Linear MCP.
+---
+
+# Linear Create Task
+
+Creates a Linear issue in the **Voldt Redesign** project with a PRD-style description, sensible defaults for milestone and labels, and assignee by task type. Uploads user-provided images/videos as attachments and uses them to enhance the description.
+
+## Rules to Apply
+
+Before creating a task, read `.cursor/rules/00-rule-index.mdc`. No other rule file is required; mention commit-rules only if the user wants a branch name convention.
+
+## Linear Context
+
+- **Project:** `Voldt Redesign — [12.07]` or `voldt redesign`
+- **Team:** `Electric Maybe` (required for `save_issue`)
+
+**Milestones (use exact name):**
+
+| Name | Description |
+|------|-------------|
+| Core Commerce Design | Product, cart, header, footer templates |
+| Merch Design | Home, collection, search templates |
+| Content Design | The rest of the templates |
+| Core Commerce Dev | Product, cart, header, footer |
+| Merch Dev | Home, collection, search |
+| Content Dev | The rest |
+
+**Labels (team Electric Maybe) — use as needed:**
+
+- **Type:** `🚀 feat`, `🔨 fix`, `🔁 change`, `🔥 remove`, `🤖 chore`, `✅ QA`, `📣 marketing`, `💫 revision`, `🧱 section`, `📄 template`
+- **Origin:** `project-requirement`, `client-request`, `qa-found`, `bug-discovered`, `internal-decision`
+- **Team:** `dev`, `design`
+- **Risk:** `!`, `!!`, `!!!`
+- **Scope:** `collection template`, `product template`, `cart template`, or section/snippet names (e.g. `s--featured-collection`, `m--filters`)
+
+If in doubt, call MCP `user-Linear` **list_milestones** with `project: "Voldt Redesign — [12.07]"` or **list_issue_labels** with `team: "Electric Maybe"` to refresh.
+
+## PRD Description Structure
+
+- **Title:** Short, clear (e.g. problem + solution in a few words).
+- **Description (Markdown):**
+  - Problem/context (1–2 sentences or bullets).
+  - `### Requirements` or `### Structure` — e.g. metaobject fields, API, data model.
+  - `### Proposed solution` — numbered steps (1. … 2. …).
+  - `### Related files` — bullet list of paths (`snippets/…`, `sections/…`).
+  - If user attached media: add `### Screenshots / reference` and describe what they show (do not invent; only what can be inferred).
+
+Optional on the issue: **estimate** (points), **dueDate** (ISO), **parentId** (sub-task), **links** `[{url, title}]`, **state** (from **list_issue_statuses** for team).
+
+## Workflow
+
+1. **Gather input** — Title (required; from user or derived). Description/PRD: freeform; if minimal, expand into PRD structure above. Type: coding vs design (for assignee and labels). Milestone: from user or default `Merch Dev`. Labels: from user or defaults. Optional: estimate, due date, parent issue, state, links.
+2. **Enhance PRD from media** — If the user attached images or videos, describe what they show and add a `### Screenshots / reference` section to the description. Do not invent details.
+3. **Resolve project and team** — Use project `Voldt Redesign — [12.07]` and team `Electric Maybe`.
+4. **Create issue** — Call MCP **user-Linear** tool **save_issue** with: `title`, `description` (Markdown), `team`, `project`, `milestone`, `labels`, `assignee` (Berk or Taha per rule below); optional `estimate`, `dueDate`, `state`, `parentId`, `links`. Capture the returned issue identifier (e.g. EM-xxxx).
+5. **Attach media** — For each user-provided image/video: if you have file content or path, encode to base64 and call **user-Linear** **create_attachment** with the new issue identifier, `base64Content`, `filename`, `contentType` (e.g. `image/png`, `video/mp4`), and optional `title`.
+6. **Confirm** — Reply with issue identifier (e.g. EM-xxxx), Linear URL, and what was set (title, assignee, milestone, labels, attachments). If assignee by name fails, use **list_users** to resolve by name and retry with the returned user id/email.
+
+## Assignee Rule
+
+- **Coding task** (implementation, fix, refactor, backend, Liquid/JS/CSS, “dev”): assignee **Berk** (e.g. `assignee: "Berk"` or email if needed).
+- **Design task** (Figma, UI/UX, visual, layout, “design”): assignee **Taha** (e.g. `assignee: "Taha"` or email if needed).
+- If unclear, ask or default to Berk. Resolve via **list_users** if name resolution fails.
+
+## Defaults (when user does not specify)
+
+- **Milestone:** `Merch Dev`
+- **Labels:** at least `project-requirement` + `dev` (coding) or `design` (design) + one type label: `🚀 feat`, `🔨 fix`, or `🤖 chore` as appropriate
+- **State:** leave unset (Linear default) unless the user specifies one; optionally call **list_issue_statuses** with `team: "Electric Maybe"` and pick Backlog/Todo if you want to set state explicitly.
+
+## MCP Tools (user-Linear)
+
+- **save_issue** — Create the issue (required: `title`, `team`; use `project`, `milestone`, `labels`, `assignee`, `description`; optional: `estimate`, `dueDate`, `state`, `parentId`, `links`).
+- **create_attachment** — After issue is created: `issue` (identifier from save_issue response), `base64Content`, `filename`, `contentType`, optional `title`, `subtitle`.
+- **list_milestones** — Optional: `project: "Voldt Redesign — [12.07]"` to refresh milestone list.
+- **list_issue_labels** — Optional: `team: "Electric Maybe"` to refresh labels.
+- **list_issue_statuses** — Optional: `team: "Electric Maybe"` to set state.
+- **list_users** — If assignee by name fails, resolve Berk/Taha and retry with id or email.
+- **get_issue** — Optional: confirm issue after creation.