climaybe 1.7.2 → 1.8.0

package/src/cursor/skills/liquid-doc-comments/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: liquid-doc-comments
+description: Adds or updates LiquidDoc documentation blocks in Liquid snippets and blocks. Use when the user says "add LiquidDoc", "document this snippet", "add doc block", or "update snippet docs". Follows liquid-doc-rules.mdc.
+---
+
+# Liquid Doc Comments
+
+Adds or updates the `{%- doc -%}` block at the top of a snippet or block so it meets project LiquidDoc standards.
+
+## Rules to Apply
+
+Before writing or editing doc blocks, read and apply:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/liquid-doc-rules.mdc` — required structure, @param format, @example, types, placement
+
+## Workflow
+
+1. **Identify file** — Snippet in `snippets/` or block in `blocks/`. If user didn’t specify, use current file or ask.
+2. **Load rules** — Read liquid-doc-rules.mdc for exact `{%- doc -%}` format, parameter types, and example requirements.
+3. **Inspect snippet/block** — List parameters (from `render` usage or Liquid assigns). Note required vs optional. Infer types (string, number, boolean, object).
+4. **Write or replace doc block** — At top of file (after any initial comment):
+   - One-sentence description, then 2–3 sentences detail.
+   - `@param {type} name` for each parameter; `[optional_param]` for optional.
+   - At least one `@example` with realistic `{% render 'snippet', param: value %}`.
+5. **Preserve whitespace** — Use `{%- doc -%}` and `{%- enddoc -%}`. No stray newlines that would break LiquidDoc parsing.
+6. **If updating** — Merge new params into existing doc; don’t remove existing examples unless redundant.
+
+## Output
+
+- Edit the file(s) with the new or updated doc block.
+- Briefly list what was added (params, examples) so the user can verify.
+
+## Example Trigger
+
+User: "Add LiquidDoc to this snippet" (with a snippet open).  
+→ Add a full `{%- doc -%}` block at the top per liquid-doc-rules.mdc, with params and at least one example.

package/src/cursor/skills/locale-translation-prep/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: locale-translation-prep
+description: Compares locale files and lists new or changed keys that need translation. Use when the user says "translation prep", "locale diff", "what needs translating", "missing translations", or "locale sync". Uses project locales (e.g. locales/*.json).
+---
+
+# Locale / Translation Prep
+
+Compares the default locale with others and reports which keys are new or changed so translators know what to update.
+
+## Rules to Apply
+
+For context on how the project uses locales (e.g. in sections/snippets), the rule index is useful:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index (schemas.mdc prefers translation keys over schema text; locales live in `locales/`)
+
+No single "locale rules" file is required; this skill focuses on file comparison and reporting.
+
+## Workflow
+
+1. **Identify default locale** — Usually `locales/en.default.json` or `locales/en.json`. Confirm by checking `locales/` directory. List other locale files (e.g. `de.json`, `fr.json`).
+2. **Collect keys** — Parse default locale (and schema locale files if present) to get the full list of translation keys (including nested keys; use dot or path notation for nesting).
+3. **Compare** — For each other locale file:
+   - Keys in default but missing in locale → "Missing"
+   - Keys in default with different value in locale → "Changed" (default changed; translation may need update)
+   - Keys in locale but not in default → "Obsolete" (optional to report)
+4. **Report** — Output a concise list per locale:
+   - **Missing keys** — List key paths so translators can add them.
+   - **Possibly stale** — Keys where default changed (if we can detect; e.g. compare to previous default or just list "present in both" and note that defaults were updated).
+5. **Optional** — Output a minimal JSON or CSV of missing keys for import into a translation tool. Or suggest adding keys to locale files with empty or placeholder values.
+
+## Output Format
+
+```markdown
+## Translation prep (default: en.default.json)
+
+### de.json
+- **Missing:** `section.foo.title`, `snippet.bar.label`, ...
+- **Note:** Default locale has X keys; de has Y. Z keys missing.
+
+### fr.json
+- **Missing:** ...
+```
+
+If the user wants, add stub entries (e.g. empty string or key as value) for missing keys in each locale file.
+
+## Example Trigger
+
+User: "What needs translating?"  
+→ Compare `locales/en.default.json` (or project default) to other `locales/*.json`, list missing and optionally changed keys per file.

package/src/cursor/skills/schema-section-change/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: schema-section-change
+description: Adds or changes a section setting (schema) and keeps section Liquid in sync. Use when the user asks to "add a section setting", "add schema setting", "new section option", or "change section config". Follows schema and section rules.
+---
+
+# Schema / Section Change
+
+Safely adds or changes a section setting: updates both the section Liquid and the `{% schema %}` block, with defaults and locales in mind.
+
+## Rules to Apply
+
+Before making changes, read and apply:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/schemas.mdc` — minimal settings, no redundancy, translation keys, max 5 settings, "question every setting"
+3. `.cursor/rules/sections.mdc` — section structure and schema requirement
+
+## Workflow
+
+1. **Clarify** — Which section file? What setting (e.g. toggle, select, range, color)? Should it be in a block or at section level?
+2. **Validate need** — Per schemas.mdc: Is this necessary? Could it be translation/CSS/existing theme setting instead? If adding multiple settings, confirm with user.
+3. **Schema** — Add or edit the setting in `{% schema %}`:
+   - Use correct type (checkbox, select, range, color, text, etc.).
+   - Sensible default. For text, prefer translation key reference in schema (e.g. label only) and actual copy in locales.
+   - Keep max 5 settings per section; use headers to group if needed.
+4. **Section Liquid** — Use the new setting in the section (e.g. `section.settings.setting_id`). Provide defaults in Liquid if needed (e.g. `section.settings.foo | default: 'bar'`).
+5. **Locales** — If the setting exposes a label or option text that should be translatable, add or point to keys in `locales/` (e.g. `en.default.json`). Don’t duplicate long copy in schema.
+6. **Blocks** — If the setting is on a block, ensure block schema and Liquid both use it; preserve existing block structure.
+
+## Output
+
+- List exact edits (file + snippet of change).
+- Note any new locale keys to add.
+- Remind about max 5 settings and "prefer translations over schema text" if relevant.
+
+## Example Trigger
+
+User: "Add a setting to turn the heading off in the FAQ section."  
+→ Edit `sections/collection--faq.liquid` (or the correct FAQ section): add a checkbox in schema, use it in Liquid to hide the heading, add/use a translation key for the setting label if needed.

package/src/cursor/skills/section-from-spec/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: section-from-spec
+description: Creates new Shopify theme sections and snippets from a spec or description. Use when the user asks for a new section, new snippet, "section from spec", "create section", or "add a section/snippet". Follows project section, snippet, schema, and Liquid doc rules.
+---
+
+# Section / Snippet from Spec
+
+Creates a new section (and optional snippet) from a user spec, following project conventions.
+
+## Rules to Apply
+
+Before creating any section or snippet, read and apply (in order):
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/sections.mdc` — section structure, schema requirement, performance
+3. `.cursor/rules/snippets.mdc` — snippet patterns, LiquidDoc, parameter handling
+4. `.cursor/rules/schemas.mdc` — minimal settings, no redundancy, translation keys, max 5 settings
+5. `.cursor/rules/liquid.mdc` — Liquid syntax
+6. `.cursor/rules/liquid-doc-rules.mdc` — required `{% doc %}` block format for snippets
+
+## Workflow
+
+1. **Clarify scope** — Section only, or section + snippet(s)? Which template(s) will use it?
+2. **Naming** — Use project convention: `section-name--variant.liquid` or `snippets/prefix--name.liquid`. Check existing `sections/` and `snippets/` for patterns.
+3. **Schema** — Minimal settings only. Prefer translation keys over schema text inputs. Max 5 settings per section (excluding headers). No redundant toggles.
+4. **Section file** — Semantic HTML, section-scoped CSS classes, `{% schema %}` with valid JSON. Include translation keys for all user-facing text.
+5. **Snippet(s)** — If needed: LiquidDoc at top (`{%- doc -%}`), parameter defaults and validation, one clear responsibility per snippet.
+6. **Templates** — If the user specified a template (e.g. product, collection), add the section to the appropriate JSON template in `templates/` if requested.
+
+## Output
+
+- Create or edit files under `sections/` and optionally `snippets/`.
+- Summarize what was created and where (file paths, schema settings, snippet params).
+- Note any translation keys added that need entries in `locales/`.
+
+## Example Trigger
+
+User: "Add a section that shows a heading and a grid of 4 product cards, with a setting for the collection."  
+→ Create `sections/s--product-grid.liquid` with minimal schema (e.g. collection picker, heading key), optional snippet for the card if it doesn’t exist.

package/src/cursor/skills/theme-check-fix/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: theme-check-fix
+description: Runs Theme Check (or similar) and suggests fixes using project Liquid and section rules. Use when the user says "theme check", "run theme check", "fix theme errors", or "lint theme". Follows liquid and section rules.
+---
+
+# Theme Check + Fix
+
+Runs theme linting (e.g. Shopify Theme Check) and maps each finding to project rules, then suggests concrete fixes.
+
+## Rules to Apply
+
+When interpreting results and suggesting fixes, read and apply:
+
+1. `.cursor/rules/00-rule-index.mdc` — rule index
+2. `.cursor/rules/liquid.mdc` — Liquid syntax and usage
+3. `.cursor/rules/sections.mdc` — section structure and schema
+4. `.cursor/rules/snippets.mdc` — snippet patterns
+
+## Workflow
+
+1. **Run Theme Check** — Execute the project’s theme check command (e.g. `theme check`, or `shopify theme check`). If no command is known, suggest the user run it and paste the output, or run a generic check if available.
+2. **Parse output** — List each issue: file, line (if any), rule/code, message.
+3. **Map to project rules** — For each issue, determine which project rule applies (Liquid, sections, snippets) and load that rule file if not already in context.
+4. **Suggest fixes** — For each finding, provide:
+   - Short explanation (why it’s flagged)
+   - Exact edit (or step) to fix it, consistent with project rules
+   - File and location
+5. **Prioritize** — Errors first, then warnings. Security and correctness before style.
+
+## Output Format
+
+```markdown
+## Theme Check results
+
+### Errors
+- **[file:line]** [rule] — [message]. **Fix:** [concrete suggestion]
+
+### Warnings
+- ...
+```
+
+If the user wants fixes applied, make the edits; otherwise output the list and let them choose.
+
+## Example Trigger
+
+User: "Run theme check and fix what you can."  
+→ Run (or ask for) theme check output, then go through each item with rule-based fix suggestions and apply edits where appropriate.

package/src/index.js

@@ -65,8 +65,9 @@ export function createProgram(version = '0.0.0', packageDir = '') {
     .action(setupCommitlintCommand);
 
   program
-    .command('add-cursor-skill')
-    .description('Add only the Cursor commit skill to this project (.cursor/skills/commit)')
+    .command('add-cursor')
+    .alias('add-cursor-skill')
+    .description('Install Electric Maybe Cursor rules + skills (.cursor/rules, .cursor/skills)')
     .action(addCursorSkillCommand);
 
   return program;

package/src/lib/commit-tooling.js

@@ -32,35 +32,6 @@ export PATH="/usr/local/bin:/opt/homebrew/bin:$PATH"
 npx --no-install commitlint --edit "$1"
 `;
 
-const CURSOR_COMMIT_SKILL = `---
-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
-`;
-
 /**
  * Scaffold commitlint config, Husky commit-msg hook, and add deps to package.json.
  * Runs npm install so husky prepare runs and hooks are installed (unless options.skipInstall).
@@ -98,18 +69,3 @@ export function scaffoldCommitlint(cwd = process.cwd(), options = {}) {
   }
   return true;
 }
-
-/**
- * Scaffold Cursor commit skill into .cursor/skills/commit/SKILL.md.
- * @param {string} [cwd] - Working directory (default process.cwd())
- * @returns {boolean} - true if written
- */
-export function scaffoldCursorCommitSkill(cwd = process.cwd()) {
-  const skillDir = join(cwd, '.cursor', 'skills', 'commit');
-  if (!existsSync(skillDir)) {
-    mkdirSync(skillDir, { recursive: true });
-  }
-  const skillPath = join(skillDir, 'SKILL.md');
-  writeFileSync(skillPath, CURSOR_COMMIT_SKILL, 'utf-8');
-  return true;
-}

package/src/lib/config.js

@@ -106,7 +106,7 @@ export function isCommitlintEnabled(cwd = process.cwd()) {
 }
 
 /**
- * Whether Cursor commit skill was added at init.
+ * Whether bundled Cursor rules + skills were installed (init or add-cursor).
  */
 export function isCursorSkillsEnabled(cwd = process.cwd()) {
   const config = readConfig(cwd);

package/src/lib/cursor-bundle.js

@@ -0,0 +1,47 @@
+import { existsSync, mkdirSync, readdirSync, statSync, copyFileSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+
+/** Bundled Electric Maybe Cursor rules + skills (shipped under src/cursor/). */
+const BUNDLE_ROOT = join(__dirname, '..', 'cursor');
+
+const SKIP_NAMES = new Set(['.DS_Store']);
+
+/**
+ * Recursively copy directory tree; skips junk files (e.g. .DS_Store).
+ * @param {string} src
+ * @param {string} dest
+ */
+function copyTree(src, dest) {
+  if (!existsSync(src)) return;
+  mkdirSync(dest, { recursive: true });
+  for (const name of readdirSync(src)) {
+    if (SKIP_NAMES.has(name)) continue;
+    const from = join(src, name);
+    const to = join(dest, name);
+    if (statSync(from).isDirectory()) {
+      copyTree(from, to);
+    } else {
+      copyFileSync(from, to);
+    }
+  }
+}
+
+/**
+ * Install bundled `.cursor/rules` and `.cursor/skills` into the target repo.
+ * @param {string} [cwd] - Working directory (default process.cwd())
+ * @returns {boolean} - false if bundle source is missing (broken install)
+ */
+export function scaffoldCursorBundle(cwd = process.cwd()) {
+  const rulesSrc = join(BUNDLE_ROOT, 'rules');
+  const skillsSrc = join(BUNDLE_ROOT, 'skills');
+  if (!existsSync(rulesSrc) || !existsSync(skillsSrc)) {
+    return false;
+  }
+  const cursorRoot = join(cwd, '.cursor');
+  copyTree(rulesSrc, join(cursorRoot, 'rules'));
+  copyTree(skillsSrc, join(cursorRoot, 'skills'));
+  return true;
+}

package/src/lib/prompts.js

@@ -163,13 +163,14 @@ export async function promptCommitlint() {
 }
 
 /**
- * Ask whether to add Cursor commit skill to the project (.cursor/skills/commit).
+ * Ask whether to install bundled Cursor rules + skills (.cursor/rules, .cursor/skills).
  */
 export async function promptCursorSkills() {
   const { enableCursorSkills } = await prompts({
     type: 'confirm',
     name: 'enableCursorSkills',
-    message: 'Add Cursor commit skill to this project? (AI-assisted conventional commits)',
+    message:
+      'Install Electric Maybe Cursor rules + skills? (Liquid/JS/a11y conventions + AI skills in .cursor/)',
     initial: true,
   });
 

package/src/workflows/shared/version-bump.yml

@@ -133,7 +133,11 @@ jobs:
             echo "No package.json found, skipping."
           fi
 
+      # Changelog must be env, not ${{ }} inside the script: multiline markdown breaks the shell
+      # (lines starting with "-" run as commands; words like "markdown" become bogus invocations).
       - name: Commit and tag
+        env:
+          CHANGELOG: ${{ inputs.changelog }}
         run: |
           NEW_VERSION="${{ steps.bump.outputs.new_version }}"
           TAG_CREATED="false"
@@ -152,9 +156,8 @@ jobs:
           elif git rev-parse -q --verify "refs/tags/${NEW_VERSION}" >/dev/null; then
             echo "Tag ${NEW_VERSION} already exists locally, reusing."
           else
-            CHANGELOG="${{ inputs.changelog }}"
             if [ -n "$CHANGELOG" ]; then
-              git tag -a "$NEW_VERSION" -m "$CHANGELOG"
+              printf '%s\n' "$CHANGELOG" | git tag -a "$NEW_VERSION" -F -
             else
               git tag -a "$NEW_VERSION" -m "Release ${NEW_VERSION}"
             fi