Claude Code + Shopify CLI: workflow real con prompts probados

Por qué este artículo no es otro tutorial de "instala el CLI"

Hay tutoriales de Shopify CLI por todos lados. Hay docs oficiales. Hay videos de YouTube de gente que lo abrió una vez y grabó el setup.

Lo que falta es la operación real: cómo pedirle cosas a Claude sin quemar tokens, cuándo la mano humana sigue siendo más rápida, qué prompts funcionan en producción. La diferencia entre reducir el tiempo de una tarea de dos horas a veinte minutos, o pasar la tarde resolviendo loops de errores.

Este artículo se enfoca en eso.

Setup

Tres comandos:

# Instalar Shopify CLI
npm install -g @shopify/cli @shopify/theme

# Login en tu store
shopify login --store mi-tienda.myshopify.com

# Pull del theme actual a tu máquina
shopify theme pull

Eso te deja con todo el theme en local. Después, en otra terminal, dentro de la carpeta del theme:

# Levantar preview local con hot reload
shopify theme dev

Abrís Claude Code en esa misma carpeta y ya podés trabajar sobre el theme.

Contexto, contexto, contexto

Es el 80% de la diferencia entre Claude eficiente y Claude que quema tokens.

Sin contexto previo: una solicitud como "agregame una sección de FAQ al theme" obliga a Claude a leer archivos al azar para entender el setup. Lee quince archivos buscando framework, naming conventions, apps que inyectan código. Quema tokens y a veces se equivoca interpretando.

Con contexto previo (prompt de onboarding): un prompt al inicio de la sesión cubre todo. Stack, apps clave, lo que no debe tocar. Claude resume lo que entendió, lo confirma, y empieza productivo desde el primer minuto.

Este es el prompt que pego al inicio de cada sesión nueva conectada a mi Shopify:

Vas a trabajar en el theme de mi tienda Shopify. Antes de tocar código, contexto:

STACK
- Theme: [nombre del theme, ej. Dawn / Impulse / custom]
- Liquid + JS vanilla / Alpine.js / [otro framework si aplica]
- Idiomas activos: [es, en, etc.]

APPS CLAVE QUE TOCAN EL THEME
- [App 1 — qué hace en el theme]
- [App 2 — qué hace]
- [App 3 — qué hace]
(Estas apps inyectan snippets propios. No los toques sin avisarme.)

CONVENCIONES DEL PROYECTO
- Componentes: snippets/ para reutilizables, sections/ para schema-driven.
- Naming: [tu convención, ej. kebab-case]
- Custom code mío vive en: [carpeta o prefijo]

LO QUE NO TOCÁS SIN AVISARME
- /checkout.liquid y cualquier cosa relacionada con checkout
- Configs de pagos (payment-method snippets)
- Scripts de tracking (GA4, Meta Pixel, TikTok Pixel)
- Cualquier snippet que empiece con "app-"

WORKFLOW
- Yo pruebo cambios en local con "shopify theme dev" antes de pushear.
- NUNCA hagas "shopify theme push" sin que te lo pida explícitamente.
- Si la tarea es ambigua, preguntá antes de asumir.

Confirmá que entendiste y resumime en 3-5 líneas lo que sabés del proyecto antes de empezar.

¿Por qué funciona? Porque le das tres cosas que Claude por sí solo no puede inferir:

1. Qué apps inyectan código (Klaviyo, reviews app, COD form, etc.) — info que vive en Shopify admin, no en los archivos.
2. Qué NO podés romper — el checkout, los pixels de tracking, los snippets de apps. Sin esto, Claude se siente libre de "limpiar" archivos críticos.
3. Tu workflow — local first, push manual. Sin esto, te ofrece pushear directo y te puede romper la tienda live.

Pego este prompt antes de cada sesión nueva. Treinta segundos de setup que ahorran horas de debugging posterior.

Workflow real: cómo itero día a día

Dos terminales abiertas. En una, shopify theme dev levantando el preview local. En otra, Claude Code dentro de la carpeta del theme.

Cuando le pido un cambio:

1. Claude lee, analiza y propone. Idealmente sin tocar archivos todavía.
2. Yo apruebo o ajusto la propuesta.
3. Claude edita.
4. Yo refresco el preview local y verifico visual.
5. Si está bien, sigo. Si no, otro round.
6. Cuando termino el batch del día, yo hago el push manual: shopify theme push --unpublished (a un theme staging primero) y reviso ahí antes de publicar.

Claude no ejecuta git push ni shopify theme push automáticamente. Esa fricción es la única protección contra incidentes en producción.

Los 7 prompts que más uso

Se pegan en una sesión de Claude Code (con el Onboarding ya cargado), se reemplazan los placeholders entre corchetes, y arrancan.

Prompt 2: Auditoría completa de theme

Útil al heredar un theme o antes de hacer cambios grandes. Devuelve un inventario del estado actual sin tocar nada.

Hacé una auditoría del theme con foco en:

1. PERFORMANCE
   - Scripts bloqueantes (defer/async ausentes)
   - Imágenes no optimizadas o sin lazy-loading
   - CSS no usado o duplicado
   - Web fonts cargados de más

2. SEO TÉCNICO
   - Meta tags presentes y correctos
   - Structured data (Product, Organization, BreadcrumbList)
   - Canonicals
   - hreflang si hay multi-idioma

3. ACCESIBILIDAD
   - Contraste de colores (AA mínimo)
   - Labels en form inputs
   - Navegación por teclado
   - Alt en imágenes

4. MOBILE
   - Viewport correcto
   - Tap targets mínimo 44px
   - Layout shift (CLS)

DEVOLVEME:
- Issues encontrados, agrupados por prioridad (crítico/alto/medio/bajo)
- Para cada uno: archivo y línea, qué pasa, impacto estimado, propuesta de fix
- NO modifiques nada todavía. Solo el reporte.

Prompt 3: Optimizar product page para conversión

El más usado. La PDP define la conversión.

Voy a darte el archivo de la product page principal (sections/main-product.liquid o equivalente).

ANALIZÁ Y PROPONÉ MEJORAS DE CONVERSIÓN:

1. Jerarquía visual de la info
   - Precio: ubicación y prominencia
   - Variantes (talla, color): UI clara o ambigua
   - CTA principal: above the fold? competing CTAs?

2. Social proof
   - Reviews visibles sin scroll?
   - Trust badges presentes?

3. Urgencia / escasez (sin manipular)
   - Stock visible cuando está bajo?
   - Tiempo estimado de envío visible?

4. Claridad de variantes
   - Indicador visual de stock por variante
   - Default selection sensible

5. Información que reduce devoluciones
   - Tabla de talles
   - FAQ inline
   - Material / cuidado del producto

PARA CADA SUGERENCIA:
- Mostrame el cambio exacto en código
- Explicá por qué (basado en best practice o data)
- Advertí si rompe lógica existente (de variantes, de tracking, etc.)

NO apliques nada. Primero el análisis con propuestas. Yo decido cuáles aplicar.

Prompt 4: Crear una sección custom desde cero

Para cuando necesitás algo que el theme no trae. Importante: pedir schema primero, código después.

Necesito una sección custom llamada [nombre-en-kebab-case]. Funcionalidad:

[Describí en lenguaje claro qué hace, ej:
"Muestra 3 USPs (icono + título + texto) en grid horizontal en desktop,
stack vertical en mobile. Cada USP configurable por separado desde el theme editor."]

REQUERIMIENTOS:
- Configurable desde theme editor (settings + blocks)
- Responsive mobile-first
- Accesible (semantic HTML, aria donde corresponda)
- Sin librerías externas si se puede evitar
- Compatible OS 2.0

ANTES DE ESCRIBIR CÓDIGO:
1. Mostrame el schema propuesto (settings y blocks).
2. Confirmá que va a funcionar en cualquier theme OS 2.0.
3. Avisame si el feature necesita assets adicionales (CSS, JS).

Después de mi OK al schema, generá el archivo completo.

Prompt 5: Debug de checkout o flujo

Cuando algo se rompe en producción y no sabés qué. Lo importante: que NO toque código hasta confirmar causa.

Estoy viendo este problema:

SÍNTOMA: [descripción exacta de qué pasa]
PASOS PARA REPRODUCIR: [si los tenés; si no, decí "intermitente"]
DESDE CUÁNDO: [hace cuánto empezó]
CAMBIOS RECIENTES: [updates de apps, theme push, etc.]

ANTES DE PROPONER FIX:

1. Hacé hipótesis de causas posibles, ordenadas por probabilidad.
2. Para cada hipótesis, decime cómo verificarla:
   - Qué logs revisar
   - Qué archivos mirar
   - Qué request inspeccionar en DevTools Network
   - Qué config de Shopify admin chequear

3. NO modifiques nada hasta que confirmemos la causa.

Si sospechás que el problema viene de una app de terceros:
- Decime cómo aislarlo (desactivar app, ver si persiste)
- Mostrame qué scripts inyecta esa app que podrían estar relacionados
- NO toques el código de la app, solo el theme nuestro

Prompt 6: Migrar de una app a otra

Para cuando reemplazás una app por otra (típico: cambio de reviews app, cambio de COD form, etc.). El riesgo es dejar código zombi de la app vieja.

Tenemos instalada [App A] que hace [función].
Vamos a migrar a [App B] porque [motivo].

NECESITO:

1. INVENTARIO de toda la lógica del theme que toca [App A]:
   - Snippets que incluyen su código
   - Sections que dependen de su API
   - Scripts que escuchan sus eventos
   - CSS que estiliza sus elementos

2. MAPPING de qué adaptar para [App B]:
   - API distinta (qué cambia en las llamadas)
   - Eventos distintos (nombres, payloads)
   - Hooks de tracking si los hay

3. PLAN DE MIGRACIÓN en pasos:
   - Cada paso con su rollback point
   - Qué probar después de cada paso
   - Cómo correr ambas apps en paralelo durante transición (si es posible)

4. CHECKLIST DE CLEANUP cuando termine:
   - Qué snippets eliminar
   - Qué assets remover
   - Qué settings desinstalar

NO empieces a migrar hasta que apruebe el plan.

Prompt 7: Performance audit con métricas reales

Cuando hay reportes de lentitud y se necesita diagnóstico con métricas, no impresiones.

Necesito entender por qué la tienda anda lenta en mobile (Lighthouse mobile score bajo, o queja real de usuarios).

PRIMERO PEDIME LOS DATOS QUE NECESITES:
- PageSpeed Insights URL del home, una PDP, el cart
- Lighthouse report local (te lo pego)
- Captura de Network tab filtrada por tipo
- Lista de apps instaladas que inyectan scripts

DESPUÉS DEL ANÁLISIS:

1. Identificá los TOP 5 bloqueantes con su métrica:
   - Script bloqueante: tiempo de ejecución, kb
   - Imagen pesada: archivo, peso, dimensiones
   - Third-party tag: dominio, peso, prioridad

2. Priorizá por relación impacto / esfuerzo de fix.

3. Para los top 3, mostrame:
   - El cambio exacto a hacer (con código si es theme)
   - El delta esperado en LCP/CLS/FID
   - Si requiere intervención en una app (no se puede tocar desde theme)

NO toques código todavía. Primero el reporte.

Prompt 8: Multi-idioma sin romper traducciones existentes

Para cuando agregás un idioma nuevo al theme. Cuidado con los strings hardcodeados.

La tienda vende en [países actuales]. Necesito agregar [idioma nuevo] al theme.

TAREA:

1. ESCANEÁ todos los archivos .liquid del theme buscando strings hardcodeados que no usen el sistema "t" filter (ej: "Add to cart" hardcodeado en vez de usar el filtro t).

2. LISTÁ los strings encontrados, agrupados por archivo. Para cada uno:
   - Archivo y línea
   - String exacto
   - Sugerencia de clave para el JSON de locales (ej. "product.add_to_cart")

3. MOVÉ los strings al JSON de locales (locales/es.default.json, locales/en.json, etc.)
   - Mantené las traducciones existentes intactas
   - Para los nuevos strings, dejá el original en es y deja vacío en otros locales

4. REEMPLAZÁ los strings hardcodeados en .liquid por la sintaxis "t" filter.

NO traduzcas. Las traducciones las cargo yo después en cada locale.json.

Confirmá la cantidad de strings que encontraste ANTES de empezar a moverlos, así apruebo el alcance.

Cuándo NO usar Claude

No es la herramienta para todo. Casos donde la mano humana sigue siendo más rápida o segura:

• Sabés el cambio exacto y es una sola línea. Cambiar un color en CSS. Editar un texto. Es más rápido vos directo en el archivo que pedirlo.
• El contexto requerido es enorme y único. Si tenés que explicar 20 minutos de contexto para un cambio chico, mejor lo hacés vos.
• Algo que toca configs sensibles de Shopify admin. Pagos, impuestos, shipping zones. Eso vive en admin, no en theme. Claude no tiene acceso. Hacelo vos.
• Debugging que requiere ver el comportamiento en producción real con tu sesión logueada. Claude no ve tu admin. Le pasás logs o capturas, pero a veces es más rápido vos directo.
• Cambios que requieren entender intent de negocio que solo vos tenés. "¿Qué precio le ponemos a este producto?" no es trabajo de Claude.

Tres hábitos que cambian la velocidad de trabajo

1. Onboarding de sesión siempre. El prompt 1 al inicio, sin excepción. Los treinta segundos invertidos se recuperan a las cinco veces que Claude no se confunde con apps que no conocía.

2. El push lo hacés vos. shopify theme push se ejecuta manual contra un theme staging primero. La fricción es la única protección contra incidentes en producción.

3. Una sesión por dominio. No conviene mezclar ajustes de PDP, debugging de checkout e integración con Klaviyo en la misma sesión. Cada uno necesita su propio contexto. Sesiones separadas mantienen el contexto limpio y el consumo de tokens controlado.

Veredicto

Preguntas frecuentes

¿Cuánto cuesta usar Claude Code para Shopify?

Claude Code requiere un plan Pro ($20/mes) o API. Para uso de operador en un Shopify, el plan Pro es más que suficiente. Comparado contra el costo de un dev freelance ($30-80/hora), paga su costo con la primera tarea que te ahorra una hora.

¿Reemplaza a un dev senior?

No, complementa. Para tareas operativas (optimización de PDP, secciones custom, debug rutinario, multi-idioma) el ahorro de tiempo es significativo. Para arquitectura compleja, decisiones de stack, o customizaciones que afectan checkout o pagos, el dev senior sigue siendo necesario.

¿Funciona con themes custom o solo con Dawn?

Funciona con cualquier theme OS 2.0. Cuanto más estándar (Dawn, Impulse, Prestige) más fácil porque Claude conoce las convenciones. Con themes custom raros, el Prompt 1 de Onboarding compensa: le explicás las convenciones específicas y se adapta.

¿Necesito saber Liquid para esto?

Ayuda bastante. No hace falta ser experto, pero entender la diferencia entre snippet, section y template, conocer el theme editor, y leer Liquid básico marca la diferencia entre pedir cosas vagas y perder tiempo, o pedir cosas precisas que avanzan rápido. Quien arranca de cero conviene que dedique dos o tres días a la documentación oficial de Liquid antes de un uso intensivo.

¿Y para Shopify Plus?

Mismo workflow, con una advertencia: en Plus existe checkout.liquid customizable (no disponible en Basic/Advanced). Eso amplía mucho lo que se puede hacer con Claude, y también el riesgo. Las restricciones del Prompt 1 deben ser más estrictas en Plus, no menos.