cue-ai 0.3.0

package/resources/skills/skills/medusa/woocommerce-to-medusa-import/references/medusa-v2-product-import.md

@@ -0,0 +1,63 @@
+# Medusa v2 Product Import Notes
+
+Use this reference when implementing a WooCommerce to Medusa product importer.
+
+## Safe importer shape
+
+- `client.ts`: WooCommerce API pagination and auth only.
+- `mapper.ts`: pure transforms from Woo payloads to Medusa product draft inputs.
+- `import-woocommerce-products.ts`: Medusa container, existing-record lookup, workflow execution, summary output.
+
+Keep mapper tests independent from Medusa runtime.
+
+## WooCommerce fetch
+
+Use basic auth over HTTPS or query auth only if the store requires it. Do not print request URLs when keys are in query params.
+
+Pagination rules:
+
+- `per_page=100`
+- increment `page` until an empty response or fewer than `per_page`
+- respect `--limit`
+- retry 429/5xx with bounded backoff
+
+Useful endpoints:
+
+- `/wp-json/wc/v3/products`
+- `/wp-json/wc/v3/products/<id>/variations`
+- `/wp-json/wc/v3/products/categories`
+
+## Existing Medusa lookup
+
+Query existing products before writes:
+
+- fields: `id`, `handle`, `metadata`, `variants.id`, `variants.sku`, `variants.metadata`
+- match by `metadata.woo_id`
+- fallback by `handle`
+- variants match by `sku`, then `metadata.woo_variation_id`
+
+## Dry-run output
+
+Dry-run must show counts and sample identifiers without secrets:
+
+```text
+Woo products read: 100
+Medusa create: 82
+Medusa update: 12
+Skip unchanged: 6
+Variants create: 190
+Variants update: 30
+Images linked: 250
+Currency: eur
+Dry run: true
+```
+
+## Common hazards
+
+- Woo descriptions are HTML. Strip or sanitize before assigning text fields.
+- Woo variable products may require per-product variation fetches.
+- Woo attributes can be global or custom; normalize names consistently.
+- Woo prices may be strings. Parse as decimal numbers and reject invalid values.
+- Duplicate SKUs must stop the import unless user explicitly allows generated fallback SKUs.
+- Missing target currency should stop live import.
+- Do not import draft/private Woo products as published by default.

package/resources/skills/skills/meta/analyze/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: analyze
+description: "[OMX] Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed."
+---
+
+# Analyze — Read-Only Deep Analysis
+
+Use this skill to answer the user’s question through **read-only repository analysis**. The goal is to explain what the codebase most likely says about the question, not to drift into implementation, debugging theater, or generic fix planning.
+
+## Use `$analyze` when
+
+- the user wants a grounded explanation, not code changes
+- the answer requires reading multiple files or tracing behavior across boundaries
+- there are several plausible explanations and they need to be ranked
+- confidence should reflect the strength of the available evidence
+- the user wants to understand architecture, behavior, causality, impact, or tradeoffs before changing anything
+
+Examples:
+- why a workflow behaves a certain way
+- how a feature is wired across modules
+- what likely explains a failure, regression, or mismatch
+- what would be impacted by changing a dependency or contract
+- which interpretation of the current codebase is best supported
+
+## Do not use `$analyze` when
+
+- the user explicitly wants code edits, a fix, or execution — use the appropriate implementation lane instead
+- the user wants a new product plan or acceptance criteria — use `$plan` / `$ralplan`
+- the request is a simple one-file fact lookup — read the file and answer directly
+- the request is purely about running the OMX tmux team runtime — use `$team` only when OMX runtime is active
+
+## Non-negotiable contract
+
+Analyze is **read-only by contract**.
+
+- Do not edit files.
+- Do not turn the answer into an implementation plan.
+- Do not recommend fixes as the primary output.
+- Do not silently switch into execution work.
+- Do not overclaim certainty.
+- Do not invent facts that are not supported by repository evidence.
+- Do not use judgmental, normative, or speculative language that outruns the evidence.
+
+If a next step is helpful, keep it to a **discriminating read-only probe** that would reduce uncertainty.
+
+## Question-aligned synthesis
+
+Answer the user’s actual question first.
+
+- Start from the asked question, not a generic debugger template.
+- Keep the synthesis scoped to what the user needs to know.
+- Scale the depth to the request: for simple or obvious questions, reduce swarm intensity and answer directly after enough reading.
+- For broader questions, expand the search surface but keep the final answer tightly synthesized.
+
+## Evidence rules
+
+Maintain an explicit **evidence-vs-inference distinction**. Every material claim must be labeled as one of:
+
+1. **Evidence** — directly supported by concrete repository artifacts
+2. **Inference** — a reasoned conclusion drawn from evidence
+3. **Unknown** — a question the current repository evidence does not resolve
+
+Never present an inference as if it were direct evidence.
+Never present a guess as if it were an inference.
+Call out uncertainty explicitly when the codebase does not settle the question.
+
+### Acceptable evidence
+
+Prefer stronger evidence over weaker evidence:
+
+1. direct code paths, contracts, tests, generated artifacts, configs, or docs with concrete file references
+2. multiple independent files pointing to the same conclusion
+3. localized behavioral inference from well-supported code structure
+4. weaker contextual clues that remain explicitly marked as tentative
+
+Unsupported speculation is not evidence.
+
+## Parallel exploration policy
+
+Parallel exploration is allowed when it improves quality, but it must stay runtime-safe.
+
+- Default to direct read-only analysis when the answer is simple.
+- When parallelism helps, prefer **native subagents by default** or equivalent in-session parallel exploration when available.
+- Keep parallel lanes bounded: each lane should answer a concrete sub-question or inspect a specific subsystem.
+- Use **`$team` only when OMX runtime is active** and durable tmux-based coordination is actually needed.
+- Do not imply that `$team` is available in plain Codex/App sessions.
+
+A good default split for complex analysis is:
+- one lane for primary code path / contracts
+- one lane for config / orchestration / generated surfaces
+- one lane for tests / docs / secondary corroboration
+
+## Execution policy
+
+- Default to outcome-first progress and completion reporting: state the question, evidence, inference boundaries, and stop condition before adding process detail.
+- Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
+- If the user says `continue`, keep working from the current analysis state instead of restarting discovery.
+
+## Working method
+
+1. Restate the question in one sentence.
+2. Identify the smallest set of files most likely to answer it.
+3. Read for direct evidence first.
+4. If needed, open bounded parallel exploration lanes.
+5. Compare competing explanations.
+6. Rank the explanations by support.
+7. Return a synthesis that clearly separates evidence from inference.
+
+## Output contract
+
+Structure the answer so the user can see what is known, what is inferred, and how confident the synthesis is.
+
+### Question
+[Restate the user’s question briefly]
+
+### Ranked synthesis
+| Rank | Explanation | Confidence | Basis |
+|------|-------------|------------|-------|
+| 1 | ... | High / Medium / Low | strongest supporting evidence |
+| 2 | ... | High / Medium / Low | why it trails |
+| 3 | ... | High / Medium / Low | why it remains possible |
+
+### Evidence
+- `path/to/file:line-line` — what this artifact directly shows
+- `path/to/file:line-line` — corroborating evidence
+
+### Inference
+- What the evidence most strongly implies
+- Why weaker alternatives were down-ranked
+
+### Unknowns / limits
+- What the repository evidence does not establish
+- What would need to be checked next to reduce uncertainty
+
+## Quality bar
+
+A good analyze response is:
+- read-only and question-aligned
+- ranked rather than flat
+- explicit about confidence
+- concrete about file references
+- careful about evidence vs inference
+- free of unsupported speculation
+- free of normative drift or judgmental filler
+- explicit about the evidence-vs-inference distinction
+- concise for simple cases, broader only when the question truly needs it

package/resources/skills/skills/meta/ask-claude/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: ask-claude
+description: >-
+  [OMX] Use when user says "ask claude", "/ask-claude", or "second opinion from claude". Runs local `claude -p` CLI; saves to .omx/artifacts/claude-*.md.
+---
+
+# Ask Claude (Local CLI)
+
+Use the locally installed Claude CLI as a direct external advisor for focused questions, reviews, or second opinions.
+
+## Usage
+
+```bash
+/ask-claude <question or task>
+```
+
+## Routing
+
+### Preferred: Local CLI execution
+Run Claude through the canonical OMX CLI command path (no MCP routing):
+
+```bash
+omx ask claude "{{ARGUMENTS}}"
+```
+
+Exact non-interactive Claude CLI command from `claude --help`:
+
+```bash
+claude -p "{{ARGUMENTS}}"
+# equivalent: claude --print "{{ARGUMENTS}}"
+```
+
+If needed, adapt to the user's installed Claude CLI variant while keeping local execution as the default path.
+
+Legacy compatibility entrypoints (`./scripts/ask-claude.sh`, `npm run ask:claude -- ...`) are transitional wrappers.
+
+### Missing binary behavior
+If `claude` is not found, do **not** switch to MCP.
+Instead:
+1. Explain that local Claude CLI is required for this skill.
+2. Ask the user to install/configure Claude CLI.
+3. Provide a quick verification command:
+
+```bash
+claude --version
+```
+
+## Artifact requirement
+After local execution, save a markdown artifact to:
+
+```text
+.omx/artifacts/claude-<slug>-<timestamp>.md
+```
+
+Minimum artifact sections:
+1. Original user task
+2. Final prompt sent to Claude CLI
+3. Claude output (raw)
+4. Concise summary
+5. Action items / next steps
+
+Task: {{ARGUMENTS}}

package/resources/skills/skills/meta/ask-gemini/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: ask-gemini
+description: >-
+  [OMX] Use when user says "ask gemini", "/ask-gemini", or "second opinion from gemini". Runs local `gemini -p` CLI; saves to .omx/artifacts/gemini-*.md.
+---
+
+# Ask Gemini (Local CLI)
+
+Use the locally installed Gemini CLI as a direct external advisor for brainstorming, design feedback, and second opinions.
+
+## Usage
+
+```bash
+/ask-gemini <question or task>
+```
+
+## Routing
+
+### Preferred: Local CLI execution
+Run Gemini through the canonical OMX CLI command path (no MCP routing):
+
+```bash
+omx ask gemini "{{ARGUMENTS}}"
+```
+
+Exact non-interactive Gemini CLI command from `gemini --help`:
+
+```bash
+gemini -p "{{ARGUMENTS}}"
+# equivalent: gemini --prompt "{{ARGUMENTS}}"
+```
+
+If needed, adapt to the user's installed Gemini CLI variant while keeping local execution as the default path.
+
+Legacy compatibility entrypoints (`./scripts/ask-gemini.sh`, `npm run ask:gemini -- ...`) are transitional wrappers.
+
+### Missing binary behavior
+If `gemini` is not found, do **not** switch to MCP.
+Instead:
+1. Explain that local Gemini CLI is required for this skill.
+2. Ask the user to install/configure Gemini CLI.
+3. Provide a quick verification command:
+
+```bash
+gemini --version
+```
+
+## Artifact requirement
+After local execution, save a markdown artifact to:
+
+```text
+.omx/artifacts/gemini-<slug>-<timestamp>.md
+```
+
+Minimum artifact sections:
+1. Original user task
+2. Final prompt sent to Gemini CLI
+3. Gemini output (raw)
+4. Concise summary
+5. Action items / next steps
+
+Task: {{ARGUMENTS}}

package/resources/skills/skills/meta/builtin-manager/SKILL.md

@@ -0,0 +1,66 @@
+---
+description: "When a skill is used frequently across multiple profiles/sessions, suggest promoting it to built-in. Also manage built-in skills when user asks to add/remove shared skills."
+tags: [meta, builtin, optimization]
+category: meta
+version: 1.0.0
+requires_mcps: []
+---
+
+# Built-in Skill Manager
+
+## When to trigger
+
+1. **User asks** to add/remove a built-in skill ("make X available everywhere", "add X to all profiles", "remove X from built-in")
+2. **After sessions** where you notice a skill being used that isn't built-in but probably should be (used in 3+ different profiles)
+
+## Commands
+
+```bash
+cue builtin                     # list current built-in skills
+cue builtin add <skill-id>     # promote to built-in (all profiles get it)
+cue builtin remove <skill-id>  # demote from built-in
+cue skills rank                 # see most-used skills across sessions
+cue skills audit                # find unused skills
+```
+
+## When to suggest promoting a skill to built-in
+
+A skill should be built-in if ALL of these are true:
+- Used in **3+ different profiles** (not just one)
+- Referenced in **10+ sessions** (check `cue skills rank`)
+- Is **generic** (not domain-specific like medusa/ or nvidia/)
+- Is **small** (<1500 tokens — built-ins add overhead to every session)
+
+## How to promote
+
+```bash
+# Check usage first
+cue skills rank
+
+# If a skill qualifies, promote it
+cue builtin add review/code-review
+
+# Verify
+cue builtin
+```
+
+## When to suggest demoting a built-in
+
+- Skill has **0 usage** across 20+ sessions (`cue skills audit`)
+- Skill is **large** (>2000 tokens) and only relevant to specific work
+- User says "I never use X"
+
+```bash
+cue builtin remove meta/unused-skill
+```
+
+## Current built-ins
+
+Run `cue builtin` to see the list. These are in the `core` profile and inherited by every other profile.
+
+## Rules
+
+- Never remove `nvidia/skill-evolution` — it's the self-improvement engine
+- Never remove `caveman/caveman` — it's the terse mode toggle
+- Ask the user before promoting/demoting — don't auto-modify
+- After changes, remind: "Run `/cue-reload` to apply"

package/resources/skills/skills/meta/cue-usage/SKILL.md

@@ -0,0 +1,149 @@
+---
+description: "When user asks about cue profiles, skills, MCPs, marketplace, or managing their agent setup, guide them through cue CLI commands"
+tags: [meta, cue, profiles, skills, mcps]
+category: meta
+version: 1.0.0
+requires_mcps: []
+---
+
+# cue — Agent Profile Manager
+
+Use this skill when the user asks about managing profiles, skills, MCPs, or their agent configuration.
+
+## Quick Reference
+
+### Profile Management
+
+```bash
+cue list                        # list all profiles
+cue current                     # show active profile
+cue use <name>                  # activate a profile
+cue init                        # interactive setup for current directory
+cue auto-detect                 # suggest profile based on project type
+cue tree <profile>              # visualize inheritance tree
+cue diff <a> <b>                # compare two profiles
+cue cost <profile>              # estimate token budget
+```
+
+### Skills
+
+```bash
+cue skills list                 # skills in active profile
+cue skills available            # skills NOT in active profile
+cue skills search <query>       # fuzzy search all skills
+cue skills add-to-profile <id>  # add skill to active profile
+cue skills remove-from-profile <id>  # remove skill
+cue skills audit                # find unused skills
+cue skills conflicts            # detect contradicting skills
+cue skills lint <id>|--all      # quality check
+cue skills test <id>|--all      # run skill tests
+cue skills new <cat/name>       # scaffold a new skill
+cue skills pin <id>             # pin to current version
+cue skills changelog <id>       # show version history
+```
+
+### MCPs
+
+```bash
+cue mcps list                   # MCPs in active profile
+cue mcps available              # MCPs NOT in active profile
+cue mcps add <id>               # add MCP to active profile
+cue mcps remove <id>            # remove MCP
+cue mcps health                 # check MCP status
+```
+
+### Marketplace (Smithery + npx skills)
+
+```bash
+cue marketplace search <query>        # search MCPs + skills
+cue marketplace search-mcps <query>   # search MCPs only (Smithery)
+cue marketplace search-skills <query> # search skills only
+cue marketplace install-mcp <id>      # install MCP via Smithery
+cue marketplace install-skill <repo>  # install skill
+cue marketplace list-mcps             # list connected MCPs
+cue marketplace find-tools <query>    # search tools by intent
+```
+
+### Maintenance
+
+```bash
+cue doctor                      # detect drift/issues
+cue doctor --fix                # auto-repair
+cue update                      # git pull + sync
+cue update --check              # preview updates
+cue stats                       # usage analytics
+cue snapshot                    # export current state
+cue snapshot restore <file>     # restore from snapshot
+```
+
+### Profile Creation
+
+```bash
+cue skills new <category>/<name>      # scaffold a skill
+cue packs create <name> --skills a,b  # create a skill pack
+cue import <url|file|org/repo>        # import profile
+cue export <profile> --output <path>  # export profile
+cue lock <profile>                    # prevent modifications
+cue unlock <profile>                  # allow modifications
+```
+
+### Inside Claude Code (slash commands)
+
+```
+/cue-skills              # browse/search/add/remove skills
+/cue-mcps                # list/add/remove/health MCPs
+/cue-reload              # rematerialize + restart
+/cue-current             # show active profile
+/cue-switch              # switch profile
+```
+
+## Creating a New Skill
+
+1. Scaffold: `cue skills new review/my-checker`
+2. Edit `resources/skills/skills/review/my-checker/SKILL.md`:
+
+```markdown
+---
+description: "When user asks for X, do Y"
+tags: [review, backend]
+category: review
+version: 1.0.0
+requires_mcps: []
+---
+
+# My Checker
+
+## When to use
+Trigger when user asks for...
+
+## Instructions
+1. Step one
+2. Step two
+
+## Examples
+User: "check this code"
+Action: Run the review process
+```
+
+3. Add to profile: `cue skills add-to-profile review/my-checker`
+4. Reload: `/cue-reload`
+
+## Creating a Profile
+
+```bash
+cue create-profile my-project \
+  --icon "🦊" \
+  --description "My project work" \
+  --skills review/code-review,meta/analyze
+```
+
+Or interactively: `cue init`
+
+## Key Concepts
+
+- **Profiles** inherit from `core` (shared baseline)
+- **Skills** are SKILL.md files that teach the agent specific tasks
+- **MCPs** are tool servers (local or remote via Smithery)
+- **Packs** group related skills for reuse
+- `.cue-profile` file pins a profile to a directory
+- Changes require `/cue-reload` to take effect

package/resources/skills/skills/meta/cue-usage/test/case-1.md

@@ -0,0 +1,5 @@
+---
+input: "cue usage"
+expect_contains: ["cue"]
+expect_not_contains: []
+---