diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index f92f93c..11f14e3 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -10,7 +10,7 @@ { "name": "ship", "description": "Health-check 30+ CLIs/tokens before you deploy, then run the full GTM pipeline: validate → strategy → awareness → launch → measure.", - "version": "0.2.0", + "version": "0.3.0", "author": { "name": "maxtechera", "url": "https://github.com/maxtechera" diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 071ecc8..64d45f4 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ship", - "version": "0.2.0", + "version": "0.3.0", "description": "Credentials preflight + GTM pipeline. Health-check 30+ CLIs/tokens, then execute idea → validate → market → sell → measure.", "author": { "name": "maxtechera", @@ -10,6 +10,6 @@ "repository": "https://github.com/maxtechera/ship", "license": "MIT", "keywords": ["credentials", "preflight", "gtm", "ship", "launch", "deploy", "health-check", "pipeline"], - "skills": ["credentials/SKILL.md", "ship-engine/SKILL.md", "supervisors/engine/SKILL.md"], + "skills": "./skills/", "hooks": {} } diff --git a/README.md b/README.md index a166983..34e02cb 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,8 @@ Claude Code: ``` -/plugin marketplace add maxtechera/ship +claude plugin marketplace add maxtechera/ship +claude plugin install ship@ship ``` OpenClaw: @@ -40,14 +41,23 @@ A 9-agent GTM team boots on first run. The coordinator reads your Linear tickets ### Claude Code ``` -/plugin marketplace add maxtechera/ship +claude plugin marketplace add maxtechera/ship +claude plugin install ship@ship ``` +This adds the `maxtechera/ship` marketplace, then installs the `ship` plugin from it. + ### Update ``` claude plugin update ship@ship ``` +### Verify +```bash +/credentials +/ship +``` + ### OpenClaw ```bash clawhub install ship diff --git a/artifacts/MAX-520/HANDOFF.md b/artifacts/MAX-520/HANDOFF.md new file mode 100644 index 0000000..78fb097 --- /dev/null +++ b/artifacts/MAX-520/HANDOFF.md @@ -0,0 +1,294 @@ +# MAX-520 — Workshop curriculum delta from objections + proof + +## Qué se entrega + +Paquete de handoff para la próxima iteración del workshop, traduciendo objeciones ya detectadas en cambios concretos de currículo, oferta y entrega. + +## Artefactos fuente usados + +- `artifacts/MAX-477/02-objection-library.md` +- `artifacts/MAX-477/01-proof-bank.md` +- `artifacts/MAX-485/FINAL-DELIVERY.md` +- `artifacts/MAX-469/03-faq-objection-handling.md` +- `artifacts/MAX-469/02-offer-stack-revision.md` +- `artifacts/MAX-513/MAX-513-klaviyo-editorial-spine.md` + +## Cómo leer este handoff + +- **Diagnóstico:** resume las 5 fricciones principales que hoy frenan compra, show-up o cierre. +- **Cambios concretos:** baja cada fricción a decisiones de currículo, oferta y entrega. +- **Priorización:** separa qué conviene mover ya en la próxima cohorte versus qué dejar como capa 2. +- **Business delta:** deja explícito el impacto esperado si se ejecuta el Tier 1. + +## Diagnóstico — 5 objeciones o fricciones principales + +### 1) "No sé si esto es para mi nivel" +**Señal detectada:** aparece repetido en FAQ y objection handling como duda de experiencia mínima, stack y si hace falta saber mucho. + +**Qué está frenando:** +- Baja registro de gente calificada porque no entiende si aplica. +- También deja entrar gente no ideal, lo que baja show-up y satisfacción. + +**Lectura operativa:** hoy el workshop comunica valor, pero no filtra ni califica con suficiente precisión antes de la compra o reserva. + +### 2) "No tengo tiempo para aprovecharlo" +**Señal detectada:** aparece la objeción de carga horaria y miedo a comprar otro curso que queda a medias. + +**Qué está frenando:** +- Reduce compra en perfiles con trabajo full-time. +- Baja asistencia en vivo si el compromiso semanal parece ambiguo o pesado. + +**Lectura operativa:** la promesa de transformación existe, pero el costo de implementación semanal no está empaquetado como algo liviano y controlable. + +### 3) "Ya probé cursos / prompts / IA y no me cambió nada" +**Señal detectada:** la librería insiste con el contraste entre teoría vs código real, curso grabado vs workshop práctico. + +**Qué está frenando:** +- Escepticismo alto. +- La propuesta puede sonar a “otro curso de IA” si no se demuestra diferencia estructural. + +**Lectura operativa:** falta mostrar con más fuerza el mecanismo único del workshop, no solo sus temas. + +### 4) "No sé si vale el precio" +**Señal detectada:** objection handling y offer revision intentan justificar ROI, ahorro de tiempo y valor de bonus. + +**Qué está frenando:** +- El precio compite contra recursos gratis y cursos baratos. +- Si el outcome no se ve concreto, el ticket parece riesgo, no inversión. + +**Lectura operativa:** el valor está narrado, pero todavía no está suficientemente anclado a resultados concretos de semana 1 y quick wins visibles. + +### 5) "¿Qué pasa después del workshop?" +**Señal detectada:** aparece explícito en objections y follow-up, junto con preguntas sobre soporte, grabaciones y continuidad. + +**Qué está frenando:** +- Miedo a quedarse solo después de las clases. +- Baja cierre si parece una experiencia intensa pero sin implementación acompañada. + +**Lectura operativa:** el workshop necesita vender mejor la continuidad y la transferencia al trabajo real, no solo el evento en vivo. + +## Propuesta de cambios concretos + +## A. Cambios de currículo + +### 1) Abrir con un módulo 0 de calificación + setup +**Cambio:** agregar una sesión o prework corto llamado `Antes de entrar: stack, nivel y objetivo`. + +**Incluye:** +- checklist de nivel mínimo +- stacks donde aplica y donde no +- definición de objetivo operativo para cada alumno +- setup técnico previo para llegar listo + +**Objeciones que resuelve:** nivel, fit, confusión inicial. + +**Impacto esperado:** mejor show-up y mejor calidad de cohorte porque reduce incertidumbre antes del día 1. + +### 2) Reestructurar semana 1 alrededor de un quick win publicable +**Cambio:** que la primera semana termine con un output visible, útil y compartible, no solo aprendizaje conceptual. + +**Incluye:** +- workflow base usable en proyecto real +- mini entrega publicada o integrada +- checklist de “ya lo tengo andando” + +**Objeciones que resuelve:** escepticismo, precio, “ya probé cosas”. + +**Impacto esperado:** acelera percepción de valor y reduce abandono temprano. + +### 3) Convertir el temario en `bloques por problema real`, no por herramienta +**Cambio:** presentar el workshop como resolución de problemas operativos. + +**Ejemplo de bloques:** +- shippear más rápido sin romper producción +- revisar código con IA sin perder criterio +- pasar de prompt suelto a workflow repetible +- integrar IA al proyecto real, no al sandbox + +**Objeciones que resuelve:** diferenciación, relevancia, valor percibido. + +**Impacto esperado:** más claridad de compra y mejor retención de atención. + +### 4) Incluir oficina de implementación obligatoria o muy visible +**Cambio:** atar explícitamente una instancia de office hours a cada fase crítica. + +**Incluye:** +- 1 sesión semanal de implementación +- revisión de bloqueos reales +- espacio para adaptar el material al caso del alumno + +**Objeciones que resuelve:** continuidad, soporte, miedo a quedarse solo. + +**Impacto esperado:** mejora completion y satisfacción, y sube la tasa de resultados reportables. + +### 5) Cerrar cada semana con una `prueba de avance` +**Cambio:** cada módulo termina con evidencia concreta de implementación. + +**Ejemplos:** +- PR revisado con nuevo workflow +- feature shippeada con apoyo de IA +- checklist de proceso instalado +- before/after de tiempo ahorrado + +**Objeciones que resuelve:** precio, credibilidad, “quiero resultados reales”. + +**Impacto esperado:** crea proof nuevo mientras el workshop corre. + +## B. Cambios de oferta + +### 6) Reescribir la promesa principal como resultado de 30 días +**Cambio:** pasar de una promesa genérica de aprender IA a una promesa concreta de sistema de shipping. + +**Propuesta:** +> Salís con un workflow propio para shippear con IA todas las semanas, con criterio técnico y sin depender de prompts sueltos. + +**Objeciones que resuelve:** valor, claridad, diferenciación. + +### 7) Hacer visible el perfil no apto +**Cambio:** agregar una sección fuerte de `esto NO es para vos si...`. + +**Incluye:** +- cero experiencia programando +- buscás teoría pasiva +- no tenés proyecto o contexto donde aplicar +- querés delegar criterio técnico por completo a la IA + +**Objeciones que resuelve:** fit, expectativas, refund risk. + +### 8) Empaquetar ROI con una métrica simple +**Cambio:** usar una lógica concreta de recuperación de inversión. + +**Ejemplo:** +- si recuperás 2 a 4 horas por semana en shipping y review, el workshop se paga solo rápido +- si salís con un workflow repetible, evitás meses de prueba y error + +**Objeciones que resuelve:** precio. + +### 9) Vender continuidad como parte del offer stack +**Cambio:** mostrar que no es solo workshop en vivo. + +**Offer stack sugerido:** +- sesiones live +- grabaciones +- office hours +- plantillas / workflows +- canal o grupo de soporte acotado por tiempo +- framework de implementación post-workshop + +**Objeciones que resuelve:** soporte, post-workshop, valor percibido. + +## C. Cambios de entrega + +### 10) Email / mensaje pre-workshop con plan de uso del tiempo +**Cambio:** enviar una pieza clara de onboarding operativo. + +**Incluye:** +- cuánto tiempo real lleva por semana +- qué hacer si no podés asistir live +- cómo aprovechar grabaciones +- qué preparar antes de empezar + +**Objeciones que resuelve:** tiempo, fricción de show-up. + +### 11) Scorecard de progreso por alumno +**Cambio:** entregar una hoja simple donde cada persona marque avances semanales. + +**Campos:** +- workflow instalado +- caso real aplicado +- tiempo ahorrado estimado +- bloqueo principal +- próxima mejora + +**Objeciones que resuelve:** percepción de avance, continuidad, prueba de valor. + +### 12) Captura sistemática de proof dentro del workshop +**Cambio:** pedir micro-evidencias al cierre de cada semana. + +**Ejemplos:** +- “qué implementaste esta semana” +- “qué tarea hacés distinto ahora” +- screenshot / commit / before-after + +**Objeciones que resuelve:** credibilidad para la siguiente cohorte. + +## Priorización para próxima iteración + +## Tier 1 — Alto impacto, baja fricción + +### Prioridad 1: módulo 0 de fit + setup +**Por qué primero:** reduce objeción de nivel antes de que contamine registro, show-up y satisfacción. + +### Prioridad 2: quick win obligatorio en semana 1 +**Por qué primero:** combate escepticismo y acelera percepción de ROI. + +### Prioridad 3: onboarding pre-workshop con carga horaria real +**Por qué primero:** baja ansiedad por tiempo y mejora asistencia. + +### Prioridad 4: sección visible de `esto no es para vos` +**Por qué primero:** mejora calificación y hace más fuerte la confianza del buyer correcto. + +## Tier 2 — Alto impacto, fricción media + +### Prioridad 5: office hours integradas al core del programa +### Prioridad 6: scorecard semanal de implementación +### Prioridad 7: reframe del temario por problemas reales + +## Tier 3 — Valor acumulativo + +### Prioridad 8: sistema interno de captura de proof semanal +### Prioridad 9: reempaque del ROI en horas recuperadas / errores evitados +### Prioridad 10: framework post-workshop de continuidad + +## Currículo sugerido, versión próxima iteración + +### Antes de empezar +- filtro de fit +- setup técnico +- objetivo individual + +### Semana 1 +- workflow base +- caso real simple +- quick win visible + +### Semana 2 +- integración al proyecto real +- guardrails y review +- office hours + +### Semana 3 +- sistema repetible de shipping +- plantillas y checkpoints +- evidencia de implementación + +### Semana 4 +- optimización del loop +- plan post-workshop +- captura final de casos y testimonios + +## Business delta esperado + +Si se implementan al menos las 4 prioridades de Tier 1, el impacto esperado es: + +- **Show-up rate más alto** por menor incertidumbre pre-evento y mejor onboarding +- **Mejor conversión a compra** por claridad de fit y ROI más concreto +- **Menor abandono temprano** por quick win en semana 1 +- **Más proof real por cohorte** para fortalecer la próxima landing, emails y objection handling +- **Mayor satisfacción del alumno correcto** al alinear expectativas con entrega real + +## Recomendación ejecutiva + +No rehacer todo el workshop. La jugada correcta es: + +1. aclarar fit antes de entrar +2. entregar valor visible en la primera semana +3. bajar la ansiedad de tiempo con onboarding explícito +4. vender continuidad como parte del sistema, no como bonus difuso +5. instrumentar captura de proof durante la experiencia + +Eso ataca las objeciones ya detectadas sin agregar demasiada fricción operativa. + +--- + +**Artifact path:** `artifacts/MAX-520/HANDOFF.md` diff --git a/artifacts/MAX-520/linear-comment.md b/artifacts/MAX-520/linear-comment.md new file mode 100644 index 0000000..27898fb --- /dev/null +++ b/artifacts/MAX-520/linear-comment.md @@ -0,0 +1,16 @@ +Shipped the MAX-520 workshop curriculum handoff in PR #11: https://github.com/maxtechera/ship/pull/11 + +What changed: +- added the full curriculum/offer/delivery handoff under `artifacts/MAX-520/HANDOFF.md` +- added a packaged summary version in `artifacts/MAX-520/package.md` +- added rendered HTML plus visual proof files for attachment in Linear + +Business delta: +- turns the top objections into concrete curriculum, offer, and delivery changes for the next workshop cohort +- prioritizes the highest-leverage changes first, especially module 0, output-based weeks, and office-hours-led implementation +- gives a repo-backed artifact the team can reuse in review, planning, and proof capture + +Proof files: +- `artifacts/MAX-520/rendered-github-markdown.html` +- `artifacts/MAX-520/rendered-github-markdown-screenshot.png` +- `artifacts/MAX-520/rendered-github-markdown-screenshot.svg` diff --git a/artifacts/MAX-520/package.md b/artifacts/MAX-520/package.md new file mode 100644 index 0000000..be9838c --- /dev/null +++ b/artifacts/MAX-520/package.md @@ -0,0 +1,189 @@ +# MAX-520 — Workshop curriculum delta from objections + proof +**Type:** handoff package +**Delivery surface:** workspace artifact +**Built:** 2026-04-15 UTC + +## Executive summary +El workshop ya tiene una buena base de oferta, proof y objection handling, pero hoy la mayor fricción no parece ser falta de interés. Parece ser una mezcla de: +1. riesgo percibido antes de entrar, +2. miedo a no llegar con el nivel correcto, +3. duda sobre si el formato va a traducirse a resultados concretos, +4. ansiedad por tiempo/implementación, +5. falta de “receipts” operativos durante la experiencia. + +La próxima iteración no necesita rehacer el workshop entero. Necesita **hacer más explícito el camino de resultado**, reducir incertidumbre en la entrada y meter más proof accionable dentro de la entrega. + +## Inputs used +- `artifacts/MAX-477/01-proof-bank.md` +- `artifacts/MAX-477/02-objection-library.md` +- `artifacts/MAX-469/03-faq-objection-handling.md` +- `artifacts/MAX-500/MAX-500-klaviyo-office-hours-funnel.md` +- `artifacts/MAX-521/MAX-521-klaviyo-social-proof-capture-loop.md` + +--- + +## 1) Diagnóstico — 5 objeciones o fricciones principales + +### Fricción 1. “No sé si esto es para mí” +**Señal:** fit ambiguity. El material actual aclara bastante bien quién sí y quién no, pero esa claridad todavía vive demasiado en objeciones/FAQ y no tanto en la arquitectura del workshop. +**Riesgo:** leads buenos dudan, leads malos entran con expectativa incorrecta. +**Impacto:** baja conversión a workshop, más fricción al inicio, peor show-up y menor satisfacción. + +### Fricción 2. “No sé si me va a dar el nivel” +**Señal:** miedo a quedar atrás o en ridículo. Aparece en la objeción de dificultad y en el need for damaging admission. +**Riesgo:** gente apta no entra o entra con ansiedad alta. +**Impacto:** menor asistencia en vivo, menor participación, menor completion. + +### Fricción 3. “No tengo tiempo para hacerlo bien” +**Señal:** la promesa de 4-6 horas/semana existe, pero falta traducirla en un plan visible de carga, ritmo y mínimos viables por semana. +**Riesgo:** el workshop se percibe como otra obligación más. +**Impacto:** menor show-up, menor entrega de ejercicios, más consumo pasivo. + +### Fricción 4. “No quiero teoría, quiero ver que esto baja a shipping real” +**Señal:** el proof bank y el positioning empujan fuerte a producción real, pero el currículo todavía necesita demostrar más explícitamente cómo se convierte una clase en un output shipped. +**Riesgo:** el workshop se percibe interesante pero no decisivo. +**Impacto:** baja de cierre, menor urgencia, menos referrals. + +### Fricción 5. “No tengo suficiente evidencia de que gente como yo obtuvo resultado” +**Señal:** el proof bank tiene buena autoridad de Max, pero también marca gaps críticos en testimonios de alumnos, cohort stats y outcomes concretos. +**Riesgo:** demasiada carga de credibilidad recae en Max y no en los alumnos. +**Impacto:** más sensibilidad a precio, menor confianza pre-compra, menor convicción durante el workshop. + +--- + +## 2) Propuesta de cambios de currículo / oferta / entrega + +## Cambio A. Abrir con una sesión 0 de calibración y setup +**Resuelve:** fit + dificultad + tiempo +**Qué cambiar:** +- Agregar una **pre-work session** corta o módulo 0 grabado. +- Incluir: quién debería seguir, quién no, setup exacto, expectativas de carga, primer quick win de 20-30 min. +- Cerrar con checklist: `listo para entrar / necesito resolver X antes`. + +**Por qué mueve negocio:** reduce no-show, baja ansiedad de entrada y mejora la calidad del alumno que arranca. + +## Cambio B. Reestructurar cada semana alrededor de un output visible +**Resuelve:** ROI + shipping real + claridad +**Qué cambiar:** +- Cada semana debe tener este formato fijo: + 1. decisión / skill principal, + 2. demo real, + 3. template o framework reusable, + 4. entrega mínima obligatoria, + 5. ejemplo de “qué se considera suficientemente bueno”. +- Nombrar outputs semanales, por ejemplo: + - Semana 1: setup y spec usable + - Semana 2: feature o micro-app IA-assisted + - Semana 3: review + integración sin romper todo + - Semana 4: shipping loop reusable + +**Por qué mueve negocio:** hace tangible el progreso, mejora completion y vuelve más fácil vender con promesa concreta. + +## Cambio C. Meter proof en el contenido, no solo en la venta +**Resuelve:** credibilidad + precio + confianza +**Qué cambiar:** +- Cada módulo arranca con un mini “receipt block”: + - caso de Max, + - caso alumno, + - error común, + - resultado esperado. +- Crear una slide recurrente: `Antes / Error / Después / Tiempo ganado`. +- Usar office hours y proof loop para capturar nuevos ejemplos por cohorte. + +**Por qué mueve negocio:** aumenta convicción durante la experiencia y alimenta ventas futuras sin depender de claims abstractos. + +## Cambio D. Instalar una ruta dual: core path + stretched path +**Resuelve:** dificultad + tiempo + heterogeneidad del grupo +**Qué cambiar:** +- Cada semana ofrece dos niveles: + - **Core path:** mínimo viable para todos. + - **Stretched path:** para los que ya vienen más avanzados. +- Explicar explícitamente que completar core ya cuenta como éxito. + +**Por qué mueve negocio:** reduce overwhelm, mejora retención y evita que el alumno sienta que “se quedó atrás” por no hacer todo. + +## Cambio E. Convertir office hours en mecanismo central del currículo +**Resuelve:** implementación + show-up + objeciones vivas +**Qué cambiar:** +- No tratarlas como bonus periférico. +- Posicionarlas como el lugar donde se destraban: + - specs flojas, + - código IA que no integra, + - dudas de scope, + - decisiones de review. +- Pedir pre-submit de bloqueos antes de cada office hour. + +**Por qué mueve negocio:** sube attendance, genera feedback loop real y convierte objeciones en assets de venta y mejora continua. + +## Cambio F. Reempaquetar la oferta con una garantía de progreso observable +**Resuelve:** precio + ROI + miedo a no completar +**Qué cambiar:** +- Mantener garantía financiera si ya existe. +- Sumar una promesa operativa más concreta, por ejemplo: + - salir con 1 spec usable, + - 1 pieza shipped o demo funcional, + - 1 workflow reusable de shipping con IA. +- Esta promesa debe estar reflejada en el currículo, no solo en la landing. + +**Por qué mueve negocio:** transforma una compra abstracta en una apuesta concreta y medible. + +--- + +## 3) Prioridad de implementación, alto impacto / baja fricción + +### P1. Inmediato +1. Agregar módulo 0 de calibración + setup. +2. Renombrar semanas por output concreto. +3. Definir core path vs stretched path en cada semana. + +### P2. Próxima iteración +4. Insertar receipt blocks en cada módulo. +5. Estandarizar intake de office hours con formulario de bloqueos. +6. Explicitar garantía de progreso observable en sales + onboarding. + +### P3. Acumulativo +7. Capturar y reciclar prueba semanal de alumnos. +8. Construir stats de cohorte, completion y wins reutilizables para futuras ventas. + +--- + +## 4) Suggested curriculum skeleton for the next iteration + +## Module 0 — Calibración +- quién es / quién no es para este workshop +- setup exacto +- expectativas de tiempo +- primer quick win + +## Week 1 — De idea a spec usable +- cómo bajar una idea a una spec que AI pueda ejecutar bien +- output: spec real + prompt/context pack inicial + +## Week 2 — De spec a primer build shipped +- cómo usar AI para producir sin perder control +- output: micro-feature o micro-app funcional + +## Week 3 — Review, integración y criterio técnico +- cómo revisar, corregir y mergear sin fe ciega +- output: PR/revisión documentada + integración estable + +## Week 4 — Shipping loop reusable +- cómo repetir el proceso sin volver al caos +- output: workflow personal reutilizable + plan de siguientes 30 días + +## Weekly office hours +- intake previo +- teardown de bloqueos reales +- proof capture al cierre + +--- + +## 5) Business delta +- **Más show-up rate:** módulo 0, expectations setting y office-hours con intake reducen ansiedad y fricción logística. +- **Más claridad de valor:** outputs semanales concretos hacen que la promesa sea fácil de entender y vender. +- **Mejor cierre:** más proof dentro del currículo y una garantía de progreso observable reducen objeción de precio/ROI. +- **Mejor retención y completion:** dual path evita overwhelm y baja la sensación de “me quedé atrás”. +- **Más assets para futuras ventas:** cada cohorte genera prueba reusable para landing, emails y stories. + +## Artifact link +`/data/workspace/artifacts/MAX-520/MAX-520-workshop-curriculum-delta-package.md` diff --git a/artifacts/MAX-520/render-markdown.js b/artifacts/MAX-520/render-markdown.js new file mode 100644 index 0000000..3c6115c --- /dev/null +++ b/artifacts/MAX-520/render-markdown.js @@ -0,0 +1,22 @@ +const fs = require('fs'); +const { marked } = require('marked'); +const md = fs.readFileSync('artifacts/MAX-520/HANDOFF.md', 'utf8'); +const body = marked.parse(md); +const html = ` + + + + MAX-520 handoff render + + + + +
+${body} +
+ + +`; +fs.writeFileSync('artifacts/MAX-520/rendered-github-markdown.html', html); diff --git a/artifacts/MAX-520/rendered-github-markdown-screenshot.png b/artifacts/MAX-520/rendered-github-markdown-screenshot.png new file mode 100644 index 0000000..c9c94b5 Binary files /dev/null and b/artifacts/MAX-520/rendered-github-markdown-screenshot.png differ diff --git a/artifacts/MAX-520/rendered-github-markdown-screenshot.svg b/artifacts/MAX-520/rendered-github-markdown-screenshot.svg new file mode 100644 index 0000000..f57cbad --- /dev/null +++ b/artifacts/MAX-520/rendered-github-markdown-screenshot.svg @@ -0,0 +1,124 @@ + + + +# MAX-520 — Workshop curriculum delta from objections + proof + +## Qué se entrega + +Paquete de handoff para la próxima iteración del workshop, traduciendo objeciones ya detectadas en cambios concretos de currículo, oferta y entrega. + +## Artefactos fuente usados + +- `artifacts/MAX-477/02-objection-library.md` +- `artifacts/MAX-477/01-proof-bank.md` +- `artifacts/MAX-485/FINAL-DELIVERY.md` +- `artifacts/MAX-469/03-faq-objection-handling.md` +- `artifacts/MAX-469/02-offer-stack-revision.md` +- `artifacts/MAX-513/MAX-513-klaviyo-editorial-spine.md` + +## Cómo leer este handoff + +- **Diagnóstico:** resume las 5 fricciones principales que hoy frenan compra, show-up o cierre. +- **Cambios concretos:** baja cada fricción a decisiones de currículo, oferta y entrega. +- **Priorización:** separa qué conviene mover ya en la próxima cohorte versus qué dejar como capa 2. +- **Business delta:** deja explícito el impacto esperado si se ejecuta el Tier 1. + +## Diagnóstico — 5 objeciones o fricciones principales + +### 1) "No sé si esto es para mi nivel" +**Señal detectada:** aparece repetido en FAQ y objection handling como duda de experiencia mínima, stack y si hace falta saber mucho. + +**Qué está frenando:** +- Baja registro de gente calificada porque no entiende si aplica. +- También deja entrar gente no ideal, lo que baja show-up y satisfacción. + +**Lectura operativa:** hoy el workshop comunica valor, pero no filtra ni califica con suficiente precisión antes de la compra o reserva. + +### 2) "No tengo tiempo para aprovecharlo" +**Señal detectada:** aparece la objeción de carga horaria y miedo a comprar otro curso que queda a medias. + +**Qué está frenando:** +- Reduce compra en perfiles con trabajo full-time. +- Baja asistencia en vivo si el compromiso semanal parece ambiguo o pesado. + +**Lectura operativa:** la promesa de transformación existe, pero el costo de implementación semanal no está empaquetado como algo liviano y controlable. + +### 3) "Ya probé cursos / prompts / IA y no me cambió nada" +**Señal detectada:** la librería insiste con el contraste entre teoría vs código real, curso grabado vs workshop práctico. + +**Qué está frenando:** +- Escepticismo alto. +- La propuesta puede sonar a “otro curso de IA” si no se demuestra diferencia estructural. + +**Lectura operativa:** falta mostrar con más fuerza el mecanismo único del workshop, no solo sus temas. + +### 4) "No sé si vale el precio" +**Señal detectada:** objection handling y offer revision intentan justificar ROI, ahorro de tiempo y valor de bonus. + +**Qué está frenando:** +- El precio compite contra recursos gratis y cursos baratos. +- Si el outcome no se ve concreto, el ticket parece riesgo, no inversión. + +**Lectura operativa:** el valor está narrado, pero todavía no está suficientemente anclado a resultados concretos de semana 1 y quick wins visibles. + +### 5) "¿Qué pasa después del workshop?" +**Señal detectada:** aparece explícito en objections y follow-up, junto con preguntas sobre soporte, grabaciones y continuidad. + +**Qué está frenando:** +- Miedo a quedarse solo después de las clases. +- Baja cierre si parece una experiencia intensa pero sin implementación acompañada. + +**Lectura operativa:** el workshop necesita vender mejor la continuidad y la transferencia al trabajo real, no solo el evento en vivo. + +## Propuesta de cambios concretos + +## A. Cambios de currículo + +### 1) Abrir con un módulo 0 de calificación + setup +**Cambio:** agregar una sesión o prework corto llamado `Antes de entrar: stack, nivel y objetivo`. + +**Incluye:** +- checklist de nivel mínimo +- stacks donde aplica y donde no +- definición de objetivo operativo para cada alumno +- setup técnico previo para llegar listo + +**Objeciones que resuelve:** nivel, fit, confusión inicial. + +**Impacto esperado:** mejor show-up y mejor calidad de cohorte porque reduce incertidumbre antes del día 1. + +### 2) Reestructurar semana 1 alrededor de un quick win publicable +**Cambio:** que la primera semana termine con un output visible, útil y compartible, no solo aprendizaje conceptual. + +**Incluye:** +- workflow base usable en proyecto real +- mini entrega publicada o integrada +- checklist de “ya lo tengo andando” + +**Objeciones que resuelve:** escepticismo, precio, “ya probé cosas”. + +**Impacto esperado:** acelera percepción de valor y reduce abandono temprano. + +### 3) Convertir el temario en `bloques por problema real`, no por herramienta +**Cambio:** presentar el workshop como resolución de problemas operativos. + +**Ejemplo de bloques:** +- shippear más rápido sin romper producción +- revisar código con IA sin perder criterio +- pasar de prompt suelto a workflow repetible +- integrar IA al proyecto real, no al sandbox + +**Objeciones que resuelve:** diferenciación, relevancia, valor percibido. + +**Impacto esperado:** más claridad de compra y mejor retención de atención. + +### 4) Incluir oficina de implementación obligatoria o muy visible +**Cambio:** atar explícitamente una instancia de office hours a cada fase crítica. + +**Incluye:** +- 1 sesión semanal de implementación +- revisión de bloqueos reales +- espacio para adaptar el material al caso del alumno + +**Objeciones que resuelve:** continuidad, soporte, miedo a quedarse solo. + \ No newline at end of file diff --git a/artifacts/MAX-520/rendered-github-markdown.html b/artifacts/MAX-520/rendered-github-markdown.html new file mode 100644 index 0000000..d4c3ddc --- /dev/null +++ b/artifacts/MAX-520/rendered-github-markdown.html @@ -0,0 +1,270 @@ + + + + + MAX-520 handoff render + + + + +
+

MAX-520 — Workshop curriculum delta from objections + proof

+

Qué se entrega

+

Paquete de handoff para la próxima iteración del workshop, traduciendo objeciones ya detectadas en cambios concretos de currículo, oferta y entrega.

+

Artefactos fuente usados

+ +

Cómo leer este handoff

+ +

Diagnóstico — 5 objeciones o fricciones principales

+

1) "No sé si esto es para mi nivel"

+

Señal detectada: aparece repetido en FAQ y objection handling como duda de experiencia mínima, stack y si hace falta saber mucho.

+

Qué está frenando:

+ +

Lectura operativa: hoy el workshop comunica valor, pero no filtra ni califica con suficiente precisión antes de la compra o reserva.

+

2) "No tengo tiempo para aprovecharlo"

+

Señal detectada: aparece la objeción de carga horaria y miedo a comprar otro curso que queda a medias.

+

Qué está frenando:

+ +

Lectura operativa: la promesa de transformación existe, pero el costo de implementación semanal no está empaquetado como algo liviano y controlable.

+

3) "Ya probé cursos / prompts / IA y no me cambió nada"

+

Señal detectada: la librería insiste con el contraste entre teoría vs código real, curso grabado vs workshop práctico.

+

Qué está frenando:

+ +

Lectura operativa: falta mostrar con más fuerza el mecanismo único del workshop, no solo sus temas.

+

4) "No sé si vale el precio"

+

Señal detectada: objection handling y offer revision intentan justificar ROI, ahorro de tiempo y valor de bonus.

+

Qué está frenando:

+ +

Lectura operativa: el valor está narrado, pero todavía no está suficientemente anclado a resultados concretos de semana 1 y quick wins visibles.

+

5) "¿Qué pasa después del workshop?"

+

Señal detectada: aparece explícito en objections y follow-up, junto con preguntas sobre soporte, grabaciones y continuidad.

+

Qué está frenando:

+ +

Lectura operativa: el workshop necesita vender mejor la continuidad y la transferencia al trabajo real, no solo el evento en vivo.

+

Propuesta de cambios concretos

+

A. Cambios de currículo

+

1) Abrir con un módulo 0 de calificación + setup

+

Cambio: agregar una sesión o prework corto llamado Antes de entrar: stack, nivel y objetivo.

+

Incluye:

+ +

Objeciones que resuelve: nivel, fit, confusión inicial.

+

Impacto esperado: mejor show-up y mejor calidad de cohorte porque reduce incertidumbre antes del día 1.

+

2) Reestructurar semana 1 alrededor de un quick win publicable

+

Cambio: que la primera semana termine con un output visible, útil y compartible, no solo aprendizaje conceptual.

+

Incluye:

+ +

Objeciones que resuelve: escepticismo, precio, “ya probé cosas”.

+

Impacto esperado: acelera percepción de valor y reduce abandono temprano.

+

3) Convertir el temario en bloques por problema real, no por herramienta

+

Cambio: presentar el workshop como resolución de problemas operativos.

+

Ejemplo de bloques:

+ +

Objeciones que resuelve: diferenciación, relevancia, valor percibido.

+

Impacto esperado: más claridad de compra y mejor retención de atención.

+

4) Incluir oficina de implementación obligatoria o muy visible

+

Cambio: atar explícitamente una instancia de office hours a cada fase crítica.

+

Incluye:

+ +

Objeciones que resuelve: continuidad, soporte, miedo a quedarse solo.

+

Impacto esperado: mejora completion y satisfacción, y sube la tasa de resultados reportables.

+

5) Cerrar cada semana con una prueba de avance

+

Cambio: cada módulo termina con evidencia concreta de implementación.

+

Ejemplos:

+ +

Objeciones que resuelve: precio, credibilidad, “quiero resultados reales”.

+

Impacto esperado: crea proof nuevo mientras el workshop corre.

+

B. Cambios de oferta

+

6) Reescribir la promesa principal como resultado de 30 días

+

Cambio: pasar de una promesa genérica de aprender IA a una promesa concreta de sistema de shipping.

+

Propuesta:

+
+

Salís con un workflow propio para shippear con IA todas las semanas, con criterio técnico y sin depender de prompts sueltos.

+
+

Objeciones que resuelve: valor, claridad, diferenciación.

+

7) Hacer visible el perfil no apto

+

Cambio: agregar una sección fuerte de esto NO es para vos si....

+

Incluye:

+ +

Objeciones que resuelve: fit, expectativas, refund risk.

+

8) Empaquetar ROI con una métrica simple

+

Cambio: usar una lógica concreta de recuperación de inversión.

+

Ejemplo:

+ +

Objeciones que resuelve: precio.

+

9) Vender continuidad como parte del offer stack

+

Cambio: mostrar que no es solo workshop en vivo.

+

Offer stack sugerido:

+ +

Objeciones que resuelve: soporte, post-workshop, valor percibido.

+

C. Cambios de entrega

+

10) Email / mensaje pre-workshop con plan de uso del tiempo

+

Cambio: enviar una pieza clara de onboarding operativo.

+

Incluye:

+ +

Objeciones que resuelve: tiempo, fricción de show-up.

+

11) Scorecard de progreso por alumno

+

Cambio: entregar una hoja simple donde cada persona marque avances semanales.

+

Campos:

+ +

Objeciones que resuelve: percepción de avance, continuidad, prueba de valor.

+

12) Captura sistemática de proof dentro del workshop

+

Cambio: pedir micro-evidencias al cierre de cada semana.

+

Ejemplos:

+ +

Objeciones que resuelve: credibilidad para la siguiente cohorte.

+

Priorización para próxima iteración

+

Tier 1 — Alto impacto, baja fricción

+

Prioridad 1: módulo 0 de fit + setup

+

Por qué primero: reduce objeción de nivel antes de que contamine registro, show-up y satisfacción.

+

Prioridad 2: quick win obligatorio en semana 1

+

Por qué primero: combate escepticismo y acelera percepción de ROI.

+

Prioridad 3: onboarding pre-workshop con carga horaria real

+

Por qué primero: baja ansiedad por tiempo y mejora asistencia.

+

Prioridad 4: sección visible de esto no es para vos

+

Por qué primero: mejora calificación y hace más fuerte la confianza del buyer correcto.

+

Tier 2 — Alto impacto, fricción media

+

Prioridad 5: office hours integradas al core del programa

+

Prioridad 6: scorecard semanal de implementación

+

Prioridad 7: reframe del temario por problemas reales

+

Tier 3 — Valor acumulativo

+

Prioridad 8: sistema interno de captura de proof semanal

+

Prioridad 9: reempaque del ROI en horas recuperadas / errores evitados

+

Prioridad 10: framework post-workshop de continuidad

+

Currículo sugerido, versión próxima iteración

+

Antes de empezar

+ +

Semana 1

+ +

Semana 2

+ +

Semana 3

+ +

Semana 4

+ +

Business delta esperado

+

Si se implementan al menos las 4 prioridades de Tier 1, el impacto esperado es:

+ +

Recomendación ejecutiva

+

No rehacer todo el workshop. La jugada correcta es:

+
    +
  1. aclarar fit antes de entrar
    2. +
  2. entregar valor visible en la primera semana
    3. +
  3. bajar la ansiedad de tiempo con onboarding explícito
    4. +
  4. vender continuidad como parte del sistema, no como bonus difuso
    5. +
  5. instrumentar captura de proof durante la experiencia
    6. +
+

Eso ataca las objeciones ya detectadas sin agregar demasiada fricción operativa.

+
+

Artifact path: artifacts/MAX-520/HANDOFF.md

+ +
+ + diff --git a/skills/credentials/SKILL.md b/skills/credentials/SKILL.md new file mode 100644 index 0000000..d4e54fd --- /dev/null +++ b/skills/credentials/SKILL.md @@ -0,0 +1,49 @@ +--- +name: credentials +version: "0.3.0" +description: "Health-check 30+ CLIs and API tokens before you deploy. Agent-executed preflight using the ship credentials registry." +argument-hint: '' +allowed-tools: Bash, Read +homepage: https://github.com/maxtechera/ship +repository: https://github.com/maxtechera/ship +author: maxtechera +license: MIT +user-invocable: true +triggers: + - credentials + - credentials check + - check credentials + - check tokens +--- + +# credentials + +Health-check the CLI tools and API tokens your agents depend on. Run before every deploy, before team creation, and before any pipeline stage that needs external access. + +## How to run + +```bash +python3 credentials/scripts/check_local.py +``` + +Useful variants: + +```bash +python3 credentials/scripts/check_local.py --quiet +python3 credentials/scripts/check_local.py --fix +python3 credentials/scripts/check_local.py --only "github,railway,vercel,openai,anthropic" +``` + +## Required references + +Before acting, read these repo files as needed: + +- `credentials/SKILL.md` +- `credentials/registry/core.yml` +- `credentials/scripts/check_local.py` + +## Output expectations + +- Report missing tools or tokens clearly. +- Prefer actionable fix commands. +- Block deploy work when required credentials are missing. diff --git a/skills/ship/SKILL.md b/skills/ship/SKILL.md new file mode 100644 index 0000000..d2909e0 --- /dev/null +++ b/skills/ship/SKILL.md @@ -0,0 +1,48 @@ +--- +name: ship +version: "0.3.0" +description: "GTM pipeline with team mode. /ship spawns coordinator + executor + critic team, renders a live dashboard, and routes active runs by stage." +argument-hint: 'ship (dashboard + team), ship create "", ship status [RUN-ID], ship run ' +allowed-tools: Bash, Read, Write +homepage: https://github.com/maxtechera/ship +repository: https://github.com/maxtechera/ship +author: maxtechera +license: MIT +user-invocable: true +triggers: + - ship + - ship create + - ship status + - ship run +--- + +# ship + +Run `/ship` once. A coordinator team spawns, the dashboard renders, and work starts moving. + +Use this skill when the user wants to create, resume, or inspect a GTM run. + +## Commands + +| Command | Description | +|---------|-------------| +| `/ship` | Spawn the coordinator team and render the live dashboard | +| `/ship create ""` | Create a new run ticket, preflight credentials, and hand off to the engine | +| `/ship status [RUN-ID]` | Read the active run, stage, last update, and blockers | +| `/ship run ` | Resume an existing run | + +## Required references + +Before acting, read these repo files as needed: + +- `SKILL.md` +- `engine/WORKFLOW.md` +- `credentials/registry/core.yml` +- `supervisors/engine/SKILL.md` +- `content/engine/SKILL.md` + +## Notes + +- Run credential preflight before deploy actions. +- Use orchestrator-style verification before advancing stages. +- Keep the dashboard and run state aligned with the active Linear ticket.