theus-cli-linux-arm64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/skills/desarrollo-por-intencion/SKILL.md

@@ -1,369 +0,0 @@
----
-name: desarrollo-por-intencion
-description: Convierte cambios de producto e ingeniería ambiguos o de alto impacto en criterios de aceptación acotados y verificables antes de la implementación o en paralelo a ella. Úsala cuando un usuario pida clarificar una funcionalidad, definir criterios de aceptación, mitigar el riesgo de un cambio de seguridad/datos/migración/integración, preparar requisitos de implementación para otro agente, o hacer testeable una petición compleja. No la actives para ediciones triviales, arreglos directos, depuración activa, revisión de código, ni peticiones de implementación cuyas condiciones de aceptación ya están claras, salvo que el usuario invoque esta skill explícitamente.
----
-
-# Desarrollo por Intención
-
-Produce criterios de aceptación útiles sin convertir la especificación en ceremonia. Inspecciona
-primero el contexto disponible, expone la ambigüedad genuina y elige métodos de verificación
-que se ajusten al trabajo y a su riesgo.
-
-## Cuándo activarla
-
-- El usuario pide clarificar una funcionalidad, definir criterios de aceptación o mitigar el riesgo de un cambio antes de implementarlo
-- La petición toca seguridad, autenticación, datos persistentes, migraciones, APIs externas o cumplimiento normativo
-- El usuario quiere preparar un artefacto de traspaso (handoff) para otro agente o equipo
-- La petición es lo bastante ambigua como para que el resultado esperado aún no sea observable ni testeable
-- El usuario invoca explícitamente esta skill con `/desarrollo-por-intencion`
-
-No la actives para ediciones triviales, arreglos directos de una línea, sesiones de depuración activa,
-peticiones de revisión de código, ni peticiones de implementación cuyas condiciones de aceptación ya están claras.
-
-## Cómo funciona
-
-1. **Inspecciona el contexto primero** — lee el repositorio, la documentación, los esquemas y la infraestructura de tests en busca de hechos técnicos antes de hacer cualquier pregunta, tratando las restricciones de producto/negocio como algo que solo el usuario o un artefacto de producto puede suministrar
-2. **Elige la profundidad** — selecciona Captura Rápida (3-7 criterios, riesgo bajo/moderado) o Informe de Aceptación Completo (cambios de seguridad, datos, migración, entre sistemas) según el perfil de riesgo
-3. **Pregunta lo mínimo** — solo hace preguntas cuyas respuestas no pueden inferirse y que cambian materialmente el alcance o el comportamiento
-4. **Escribe criterios observables** — cada AC-NNN describe una condición inicial, un disparador, el resultado esperado, un efecto secundario prohibido, un método de verificación y una prioridad; sin palabras vagas como "correctamente" o "de forma segura" sin evidencia
-5. **Continúa o traspasa** — para peticiones claras sin riesgos bloqueantes, registra los criterios y continúa; para cambios riesgosos, presenta los bloqueantes y espera confirmación
-6. **Gestiona la revisión** — si un AC falla a mitad de implementación por restricciones arquitectónicas, lo marca `[revisado]`, actualiza el alcance o el método de verificación, incrementa el número de revisión y vuelve a presentar solo los criterios modificados
-
-## Ejemplos
-
-**Captura Rápida — "Añade exportación CSV al dashboard"**
-
-```
-Objetivo: los usuarios autenticados pueden descargar los datos del dashboard como archivo CSV.
-En alcance: exportación de las filas actualmente filtradas; el nombre del archivo incluye la fecha.
-Fuera de alcance: exportaciones programadas, envío por correo, formato Excel.
-Supuestos: el conteo máximo de filas es inferior a 10k; sin PII en los campos exportados.
-
-AC-001: La exportación genera un archivo con los encabezados correctos
-- Escenario: usuario autenticado, con al menos una fila de datos visible
-- Acción: hacer clic en "Exportar CSV"
-- Esperado: el navegador descarga un archivo con las columnas [id, name, created_at]
-- No debe: exponer campos internos ni filas pertenecientes a otros usuarios
-- Verificación: test de integración automatizado + revisión manual puntual del esquema
-- Prioridad: Requerido
-```
-
-**Disparador de Informe de Aceptación Completo — "Migra la autenticación de usuarios a OAuth"**
-
-Cambio de autenticación + dependencia externa + datos de sesión existentes → Informe Completo con tabla de Revisión de Riesgos,
-decisiones bloqueantes sobre la estrategia de invalidación de sesiones y un AC explícito de reversión.
-
-**Revisión de una especificación existente — el usuario pega un PRD**
-
-La skill lo revisa en busca de límites de alcance faltantes, requisitos no verificables ("el sistema debe ser rápido")
-y supuestos silenciosos, y luego devuelve criterios corregidos o complementarios sin reiniciar el descubrimiento.
-
-## Reglas de operación
-
-1. Inspecciona el contexto disponible de repositorio, documentación, issues, diseño y tests antes
-   de preguntar por hechos técnicos que pueden descubrirse localmente.
-2. No infieras restricciones de producto o negocio a partir del código. Las reglas de negocio, las
-   obligaciones regulatorias y de cumplimiento, los SLA contractuales, los precios, la política de
-   retención de datos, la priorización y los usuarios objetivo no pueden leerse de un repositorio.
-   Trátalos como desconocidos hasta que el usuario los suministre o un artefacto de producto
-   autoritativo (PRD, contrato, documento de política) los declare. Regístralos como supuestos
-   marcados para confirmación, nunca como hechos descubiertos. El repositorio te dice cómo se
-   comporta el sistema hoy, no lo que el negocio requiere que haga.
-3. Haz solo preguntas cuyas respuestas sean necesarias y no puedan inferirse con seguridad. Agrupa
-   preguntas cortas relacionadas cuando eso ahorre turnos innecesarios.
-4. No bloquees la implementación por defecto. Cuando el usuario ha pedido implementar un cambio
-   suficientemente claro, registra brevemente los supuestos clave y los criterios de aceptación, y
-   luego continúa o entrégalos al flujo de implementación.
-5. Exige confirmación explícita del usuario antes de continuar solo cuando una decisión no resuelta
-   pueda crear exposición de seguridad material, pérdida de datos, una migración irreversible,
-   rotura contractual/de API, un costo significativo o una acción externa destructiva.
-6. No escribas un documento de aceptación en un repositorio, ni alteres archivos del proyecto, crees
-   una rama, hagas commit o invoques otra skill, salvo que el usuario lo pida o el flujo de trabajo
-   activo del repositorio lo requiera explícitamente.
-7. Trata los tests automatizados como evidencia, no como verdad. Prefiere la automatización cuando
-   sea confiable y proporcionada; admite verificación manual de UX, accesibilidad, seguridad, legal
-   u operativa donde la automatización no pueda establecer el resultado.
-8. Nunca incluyas secretos reales, credenciales, tokens, claves privadas, datos personales ni
-   payloads sensibles de producción en criterios de aceptación, fixtures, ejemplos o artefactos
-   guardados. Usa valores redactados o sintéticos.
-9. No ejecutes tests destructivos, migraciones, sondas de seguridad, tests de carga, llamadas
-   externas de pago ni operaciones contra producción/datos reales sin autorización explícita y un
-   entorno seguro identificado.
-10. Cuando un criterio de aceptación no pueda satisfacerse por una restricción arquitectónica, de
-   plataforma o externa descubierta durante la implementación, no lo descartes ni lo esquives en
-   silencio. Actualiza el criterio afectado (márcalo `[revisado]`, declara la restricción y ajusta
-   el alcance o el método de verificación), incrementa el número de revisión y vuelve a presentar
-   solo los criterios modificados al usuario antes de continuar. Exige confirmación explícita solo
-   si la revisión cambia una decisión bloqueante o reduce materialmente las garantías de seguridad
-   o corrección.
-
-## Elige la profundidad
-
-Usa la salida útil más pequeña.
-
-### Captura Rápida
-
-Úsala para un cambio claro pero no trivial con riesgo bajo o moderado. Produce:
-
-- Objetivo
-- En alcance / fuera de alcance
-- Supuestos
-- 3-7 criterios de aceptación con métodos de verificación
-- Preguntas bloqueantes, si las hay
-
-No retrases la implementación esperando aprobación salvo que exista un riesgo bloqueante según
-las reglas de operación o el usuario haya pedido específicamente una especificación primero.
-
-### Informe de Aceptación Completo
-
-Úsalo para cambios ambiguos, entre sistemas, sensibles a la seguridad, que modifican datos, de
-migración, de cumplimiento o de alto costo, o cuando el usuario pida un artefacto de traspaso.
-Produce la plantilla completa de abajo y solicita confirmación para las decisiones bloqueantes
-no resueltas antes de una implementación riesgosa.
-
-### Revisión de una especificación existente
-
-Cuando el usuario ya suministró un PRD, un issue, un plan o criterios de aceptación:
-
-1. Revísalos en lugar de reiniciar el descubrimiento.
-2. Identifica límites de alcance faltantes, supuestos inseguros, contradicciones y requisitos
-   no verificables.
-3. Devuelve criterios corregidos o complementarios.
-
-## Flujo de trabajo
-
-### 1. Establece el objetivo y el riesgo
-
-Extrae o pregunta:
-
-- El resultado observable para el usuario o el sistema.
-- Los actores afectados.
-- La consecuencia principal en caso de fallo.
-- Las dimensiones de riesgo que realmente aplican: seguridad/privacidad, datos persistentes,
-  compatibilidad/API, migración, dependencias externas, costo, concurrencia, rendimiento,
-  usabilidad/accesibilidad.
-
-Evita hacer preguntas genéricas sobre riesgos irrelevantes.
-
-### 2. Descubre el contexto
-
-Cuando haya artefactos locales o conectados disponibles, inspecciona solo lo necesario:
-
-- Comportamiento existente y archivos o interfaces directamente relacionados.
-- Convenciones del repositorio, documentación de producto, contratos de API, esquemas de datos
-  o historial de migraciones.
-- Infraestructura de verificación existente y comandos realistas.
-- Dependencias externas y si son testeables de forma aislada.
-
-Registra los hechos descubiertos por separado de los supuestos proporcionados por el usuario. Si
-el contexto no puede inspeccionarse, di qué se desconoce y haz preguntas enfocadas.
-
-El repositorio revela hechos técnicos — cómo se comporta el sistema hoy, sus convenciones y sus
-contratos. No revela restricciones de producto o negocio: reglas de negocio, obligaciones
-regulatorias y de cumplimiento, SLA contractuales, precios, política de retención de datos,
-priorización y usuarios objetivo. Nunca los reconstruyas a partir del código o de los nombres.
-Captúralos solo del usuario o de un artefacto de producto autoritativo, y lístalos como supuestos
-a confirmar hasta entonces.
-
-### 3. Define el alcance
-
-Declara:
-
-- Objetivo: una oración que describa el resultado previsto.
-- En alcance: el comportamiento que este cambio debe entregar.
-- Fuera de alcance: el trabajo adyacente tentador que queda explícitamente excluido.
-- Supuestos: afirmaciones aún no comprobadas.
-- Decisiones bloqueantes: elecciones no resueltas que afectan materialmente la seguridad o el comportamiento.
-
-### 4. Escribe los criterios de aceptación
-
-Usa `AC-001`, `AC-002`, y así sucesivamente. Cada criterio debe describir un comportamiento
-observable y un método de verificación apropiado; no se exige que criterios y tests se
-correspondan uno a uno.
-
-Para cada criterio aplicable incluye:
-
-- Escenario o condición inicial.
-- Acción o disparador.
-- Comportamiento observable esperado.
-- Efecto secundario prohibido cuando sea significativo.
-- Método de verificación: test automatizado, comprobación de integración, revisión manual de UX,
-  comprobación de accesibilidad, revisión de seguridad, comprobación operativa o aceptación de
-  las partes interesadas.
-- Restricción de entorno/seguridad cuando la verificación pueda afectar datos, servicios, costos o secretos.
-- Prioridad: requerido, importante u opcional.
-
-No uses palabras como "correctamente", "de forma segura", "rápido", "intuitivo" o "robusto" sin
-definir evidencia observable o registrarlas como un juicio de revisión humana.
-
-### 5. Cubre solo los límites relevantes
-
-Considera estas categorías, pero incluye solo las que apliquen:
-
-| Categoría | Incluir cuando | Evidencia típica |
-| --- | --- | --- |
-| Camino feliz | Comportamiento visible al usuario nuevo o modificado | Flujo de trabajo o transición de estado exitosos |
-| Validación | El cambio acepta entradas | Valor malformado o de frontera rechazado sin mutación |
-| Autorización/privacidad | Los datos o acciones tienen límites de acceso | Acceso denegado y sin divulgación sensible |
-| Persistencia/migración | Cambian datos almacenados o esquemas | Lectura hacia atrás, migración, comportamiento de reversión o respaldo |
-| Compatibilidad | APIs públicas, archivos, eventos o clientes pueden romperse | El contrato o fixture existente sigue siendo válido |
-| Recuperación ante fallos | Existe fallo de red, de servicio o asíncrono | Sin estado parcial o comportamiento claro de reintento/degradado |
-| Idempotencia/concurrencia | Repeticiones o escrituras simultáneas son plausibles | Sin efecto secundario duplicado ni estado final inválido |
-| Rendimiento | Importa un umbral de usuario o servicio | Condiciones de medición y umbral definidos |
-| UX/accesibilidad | Una persona interactúa con el resultado | Teclado, retroalimentación, recuperación de errores, revisión visual/manual |
-
-### 6. Presenta y continúa
-
-- Para una petición de clarificación/especificación, presenta el informe y pide decisiones solo
-  sobre los bloqueantes listados.
-- Para una petición de implementación sin bloqueantes, presenta un resumen compacto de criterios
-  como parte del trabajo y continúa con la implementación.
-- Para un traspaso a otro agente o equipo, incluye suficiente contexto y detalle de verificación
-  para que puedan actuar sin inventar requisitos.
-- Guarda el informe en un archivo solo cuando se solicite. Usa una ruta aprobada por el
-  repositorio cuando exista una; de lo contrario, pregunta o declara el destino elegido antes de escribir.
-
-## Plantilla de salida
-
-Usa esta plantilla para un Informe de Aceptación Completo. Omite las secciones irrelevantes en la Captura Rápida.
-
-```markdown
-# Informe de aceptación: <nombre del cambio>
-
-**Estado:** Borrador | Aprobado | Implementado | Verificado
-**Revisión:** <número>
-**Preparado para:** <usuario/equipo/agente, cuando se conozca>
-**Aprobación requerida antes de trabajo riesgoso:** Sí | No - <motivo>
-
-## Registro de revisiones
-
-| Rev | Fecha | Criterios modificados | Motivo |
-| --- | --- | --- | --- |
-| 1 | <fecha> | — | Borrador inicial |
-
-## Objetivo
-
-<Una oración de resultado observable.>
-
-## Alcance
-
-**En alcance**
-- <comportamiento incluido>
-
-**Fuera de alcance**
-- <trabajo adyacente excluido>
-
-## Contexto
-
-**Hechos descubiertos** (técnicos, verificados desde el repositorio o un artefacto)
-- <cómo se comporta el sistema hoy, convenciones, contratos>
-
-**Restricciones de producto/negocio** (suministradas por el usuario o un artefacto de producto, nunca inferidas del código)
-- <regla de negocio, obligación de cumplimiento/SLA, política de retención, prioridad, usuario objetivo — o "ninguna suministrada aún">
-
-**Supuestos**
-- <afirmación no verificada a confirmar o validar>
-
-**Dependencias y restricciones**
-- <servicio externo, convención local, obligación de compatibilidad, límite de entorno>
-
-## Revisión de riesgos
-
-| Área de riesgo | ¿Aplica? | Manejo requerido |
-| --- | --- | --- |
-| Seguridad/privacidad | Sí/No | <redacción, autorización, revisión, etc.> |
-| Datos persistentes/migración | Sí/No | <compatibilidad, respaldo, reversión, etc.> |
-| Efectos externos/costo | Sí/No | <sandbox/entorno de prueba/autorización> |
-| Compatibilidad/API | Sí/No | <contrato a preservar o versionar> |
-| UX/accesibilidad | Sí/No | <evidencia manual o automatizada> |
-
-## Criterios de aceptación
-
-### AC-001: <comportamiento observable>
-- **Escenario:** <condición inicial>
-- **Acción:** <disparador único>
-- **Esperado:** <resultado observable>
-- **No debe:** <efecto secundario prohibido, si aplica>
-- **Verificación:** <método y evidencia prevista>
-- **Entorno/seguridad:** <restricciones, si aplican>
-- **Prioridad:** Requerido | Importante | Opcional
-
-## Decisiones bloqueantes
-
-- [ ] <solo decisiones que impiden avanzar de forma segura o correcta>
-
-## Plan de verificación
-
-| Criterio | Evidencia de verificación | Estado |
-| --- | --- | --- |
-| AC-001 | <comando de test/comprobación/revisión o tipo de evidencia> | Pendiente |
-```
-
-## Ejemplos de aprobado/reprobado
-
-Úsalos para juzgar si la skill realmente produjo un informe verificable y no prosa de planificación.
-
-**Un criterio de aceptación que reprueba**
-
-```
-AC-001: La exportación funciona correctamente y es segura.
-```
-
-Reprueba — "funciona correctamente" y "segura" no son observables; no hay escenario, disparador,
-resultado esperado ni método de verificación, y nada declara lo que no debe pasar. Un lector no
-puede saber si la implementación lo satisfizo.
-
-**Un criterio de aceptación que aprueba**
-
-```
-AC-001: La exportación genera un archivo con los encabezados correctos
-- Escenario: usuario autenticado, con al menos una fila de datos visible
-- Acción: hacer clic en "Exportar CSV"
-- Esperado: el navegador descarga un archivo con las columnas [id, name, created_at]
-- No debe: exponer campos internos ni filas pertenecientes a otros usuarios
-- Verificación: test de integración automatizado + revisión manual puntual del esquema
-- Prioridad: Requerido
-```
-
-Aprueba — un resultado observable concreto, un efecto secundario prohibido y un método de
-verificación nombrado. Dos personas coincidirían en si se cumplió.
-
-**Una entrada de contexto que reprueba**
-
-```
-Hechos descubiertos: los usuarios del plan gratuito están limitados a 100 exportaciones al mes.
-```
-
-Reprueba — un límite por plan es una regla de negocio. No debe aparecer bajo hechos descubiertos
-inferidos del código; pertenece a las restricciones de producto/negocio, suministradas por el
-usuario, o debe listarse como un supuesto a confirmar.
-
-### Rúbrica de aprobado/reprobado
-
-Un informe aprueba solo si todas las respuestas son "sí". Cualquier "no" implica revisar antes de devolverlo.
-
-- [ ] ¿Cada criterio requerido tiene un escenario, un resultado esperado observable y un método de verificación nombrado?
-- [ ] ¿Todos los términos vagos ("correctamente", "seguro", "rápido", "robusto") fueron reemplazados por evidencia observable o marcados como juicio humano?
-- [ ] ¿Las restricciones de producto/negocio están listadas como suministradas/supuestas, sin ninguna inferida silenciosamente del código?
-- [ ] ¿El alcance es explícito, con los elementos fuera de alcance nombrados?
-- [ ] ¿Las decisiones bloqueantes se limitan a elecciones que realmente afectan la seguridad o la corrección, no a preferencias?
-
-## Verificación de calidad
-
-Antes de devolver el informe, comprueba:
-
-- El objetivo describe un resultado y no una elección de implementación.
-- Los límites de alcance y los supuestos son explícitos.
-- Cada criterio requerido es observable o está claramente marcado para juicio humano.
-- Los riesgos de seguridad, privacidad, datos, compatibilidad, efectos externos y UX se
-  consideraron solo donde eran relevantes y no se ignoraron en silencio.
-- Los métodos de verificación identifican entornos seguros para operaciones riesgosas.
-- No se copió información secreta ni sensible de producción en la salida.
-- No se impone ninguna mutación del repositorio ni bloqueo de implementación sin justificación o petición.
-
-## Traspaso
-
-Cuando haya disponible otro flujo de planificación o implementación, pásale el informe de
-aceptación o los IDs de los criterios. Cuando no exista un flujo dedicado, entrega el informe
-directamente como referencia de implementación. No asumas que alguna skill o herramienta con
-nombre está instalada.

package/vendor/theus-arsenal/skills/descubrimiento-marca/SKILL.md

@@ -1,149 +0,0 @@
----
-name: descubrimiento-marca
-description: >-
-  Úsala cuando una marca necesite descubrir o articular su identidad mediante
-  entrevistas estructuradas en varias sesiones. Cubre propósito, posicionamiento,
-  audiencia, personalidad, voz, narrativa y la tensión fundador-marca en 8 módulos,
-  usando laddering, los 5 porqués y técnicas proyectivas. Produce una sesión
-  reanudable con estado persistido en disco y un brandbook maestro (90_SINTESIS.md).
----
-
-# Descubrimiento de marca
-
-Usa esta skill para conducir una entrevista de identidad de marca estructurada y adaptativa.
-El objetivo es un `90_SINTESIS.md` completo — un brandbook maestro que la
-organización pueda usar para dar el brief a diseñadores, redactores y
-colaboradores externos.
-
-La entrevista se desarrolla a lo largo de varias sesiones. Registra las respuestas
-en disco a medida que avanzas, para que ningún conocimiento elicitado se pierda al
-terminar una conversación y para que una sesión posterior pueda retomar donde se
-detuvo la anterior.
-
-## Cuándo activarla
-
-- Se está creando o reposicionando una marca, o necesita una referencia de identidad escrita para dar briefs a colaboradores.
-- Se esperan varias sesiones — la conversación abarcará días o semanas.
-- Varios fundadores o stakeholders necesitan entrevistas individuales antes de una pasada de reconciliación.
-- El usuario quiere un método estructurado y repetible, no una charla improvisada.
-- La documentación de marca existente está dispersa, es implícita o depende del fundador, y hay que hacerla explícita.
-
-## Protocolo de inicio de sesión
-
-En cada activación, realiza estos pasos **antes** de hacer cualquier pregunta de
-entrevista:
-
-1. **Comprueba el progreso previo.** Busca un conjunto existente de archivos de
-   módulo y un checkpoint `state.json` en el directorio de identidad de marca del
-   proyecto. Si no existe ninguno, es un inicio desde cero — confirma el nombre de
-   la marca, los participantes y dónde guardar los archivos de identidad de marca,
-   y comienza por el primer módulo.
-2. **Lee el archivo del módulo en curso**, si hay uno, y revisa su sección Raw en
-   busca de respuestas capturadas previamente.
-3. **Informa al usuario** en dos o tres frases: en qué módulo estamos, su estado y
-   qué falta. Después pregunta: "¿Continuamos aquí o cambiamos de módulo?"
-
-## Disciplina de entrevista
-
-Aplica estas reglas en todos los módulos:
-
-1. **Una pregunta a la vez.** Nunca presentes una lista de preguntas.
-2. **Después de cada respuesta:** paráfrasis breve → una pregunta de profundización
-   O cierra el hilo si el tema está saturado. Nunca avances en silencio.
-3. **Laddering:** ante cada respuesta de "qué", sigue con "¿Por qué te importa
-   eso?" hasta que aflore un valor central (normalmente dos a cuatro iteraciones).
-4. **5 porqués:** para creencias o afirmaciones de posicionamiento — insiste hasta
-   que la razón de fondo, no la declaración superficial, esté sobre la mesa.
-5. **Detecta respuestas delgadas:** si son genéricas, cargadas de jerga o vagas,
-   pide un ejemplo concreto, una historia de cliente o una cifra.
-6. **Técnicas proyectivas** (usa una por módulo para romper un estancamiento):
-   - "Si la marca fuera una persona, ¿cómo entraría en una sala?"
-   - Obituario de marca: "Si la organización cerrara en cinco años, ¿qué
-     extrañarían los clientes? ¿Qué te arrepentirías de no haber dicho?"
-   - Contraste competitivo: "Nombra un par que admires pero en el que nunca
-     querrías convertirte. ¿Qué lo hace exactamente el modelo equivocado?"
-7. **Señal de saturación:** cuando dos preguntas de profundización consecutivas no
-   produzcan información nueva, resume y cierra el módulo.
-8. **Fin de módulo:** escribe un archivo de módulo estructurado con dos secciones:
-   - `## Raw` — citas textuales y ejemplos.
-   - `## Síntesis` — tu interpretación, tres formulaciones candidatas, preguntas
-     abiertas, contradicciones entre participantes.
-   Después actualiza el checkpoint `state.json` (ver el protocolo de estado abajo).
-
-## Secuencia de módulos
-
-| Archivo | Etiqueta | Marcos usados |
-|---------|----------|---------------|
-| `10_proposito-porque.md` | Propósito / Porqué | Círculo dorado de Sinek, Lencioni |
-| `20_posicionamiento.md` | Posicionamiento | Dunford "Obviously Awesome", plantilla de Moore |
-| `30_audiencia-nicho.md` | Audiencia y nicho | Baker "Business of Expertise", ICP |
-| `40_personalidad-arquetipo.md` | Personalidad y arquetipo | 12 arquetipos de Mark y Pearson, 5 dimensiones de J. Aaker |
-| `50_voz-tono.md` | Voz y tono | Guías de voz de marca |
-| `60_narrativa-historia.md` | Narrativa / Historia | Trueline de Neumeier, arco de historia de marca |
-| `70_tension-fundador.md` | Marca del fundador vs. marca de la organización | Enns "Win Without Pitching" |
-| `90_SINTESIS.md` | Brandbook maestro | Prisma de Kapferer, sistema de marca de Aaker |
-
-Completa los módulos en orden. Respeta la petición del usuario de saltar de
-módulo y anota el salto en `state.json`.
-
-Las plantillas de cada módulo viven en `references/` dentro de esta skill; úsalas
-como estructura base al crear cada archivo de módulo.
-
-## Protocolo de escritura de estado
-
-Cuando un módulo alcance la saturación o el estado "hecho", escribe dos archivos:
-
-**Archivo de módulo** en `modules/{archivoModulo}` — contenido completo de Raw y
-Síntesis.
-
-**`state.json`** — un checkpoint ligero para que una sesión posterior pueda
-reanudar. Actualiza `completedModules`, `inProgressModule`, `nextModule`,
-`lastUpdated`. Esquema:
-
-```json
-{
-  "session": "{nombre_marca}-marca-{AAAA-MM}",
-  "outputPath": "{ruta_al_directorio_de_identidad_de_marca}",
-  "completedModules": [],
-  "inProgressModule": "10_proposito-porque.md",
-  "nextModule": "20_posicionamiento.md",
-  "participants": ["fundador-a"],
-  "lastUpdated": "{ISO-8601}"
-}
-```
-
-Después de escribir, confirma: "Módulo X guardado. Estado actualizado. Siguiente: Y."
-
-**Módulo terminal (90_SINTESIS.md):** al escribir la síntesis final, pon
-`inProgressModule` en `"90_SINTESIS.md"` y `nextModule` en `null` en
-`state.json`. Tras escribirla, añade `"90_SINTESIS.md"` a `completedModules` y
-después pon `inProgressModule` en `null` — dejarlo poblado haría que una
-reanudación futura tratara el brandbook completado como si aún estuviera en
-progreso. Confirma: "Brandbook completo. Todos los módulos guardados."
-
-## Modo multi-fundador
-
-Cuando participa más de un fundador, escribe las respuestas de cada uno en
-`founders/{participante}.md` en lugar de en los archivos de módulo principales.
-Valida el nombre de `participante` antes de escribir: acepta solo caracteres
-alfanuméricos y guiones (p. ej. `fundador-a`, `anna`); rechaza nombres con
-separadores de ruta (`/`, `\`, `..`) o caracteres especiales. Valida
-`archivoModulo` contra la secuencia enumerada de módulos (solo del 10 al 90).
-Valida `outputPath` para asegurar que sea una ruta absoluta dentro del directorio
-del proyecto — rechaza rutas relativas y rutas que escapen mediante segmentos
-`..`. Cuando todos los fundadores completen un módulo, ejecuta una pasada de
-reconciliación: resume convergencias y divergencias en el archivo del módulo y
-marca las "tensiones productivas" para el taller de alineación grupal.
-
-## Antipatrones
-
-- **Empezar sin leer el estado primero.** Toda sesión debe abrir comprobando los archivos de módulo existentes y `state.json`. Saltarse esto pierde toda la continuidad de sesiones previas.
-- **Hacer varias preguntas a la vez.** Una pregunta a la vez no es opcional — las listas producen respuestas de checklist, no insight real.
-- **Pasar a la Síntesis antes de la saturación.** Si las dos últimas preguntas de profundización no produjeron información nueva, el módulo está terminado. Si la produjeron — no lo está.
-- **Saltarse la reconciliación multi-fundador.** Cuando hay varios stakeholders, las entrevistas individuales deben completarse antes de la reconciliación. Discutir la marca colectivamente primero introduce sesgo de anclaje.
-- **Tratarla como una sesión única.** Esta skill está diseñada para varias sesiones. Correr hacia `90_SINTESIS.md` en una sola conversación produce un resultado superficial.
-
-## Skills relacionadas
-
-- `analisis-plataformas-competencia` — una vez que descubrimiento-marca establece el brief de posicionamiento, úsala para delimitar y categorizar el conjunto de competidores.
-- `voz-de-marca` — si el módulo de voz y tono necesita un perfil de estilo de escritura aparte, derivado de fuentes reales.

package/vendor/theus-arsenal/skills/descubrimiento-marca/references/10_proposito-porque.md

@@ -1,42 +0,0 @@
-# Módulo 10 — Propósito / Porqué
-
-> **Marcos:** Círculo dorado de Sinek · Propósito organizacional de Lencioni
->
-> **Objetivo:** hacer aflorar la creencia central de la marca — el Porqué que
-> existe con independencia de lo que la organización vende o de cómo lo entrega.
-> Captura la convicción fundacional, no el elevator pitch.
-
----
-
-## Raw
-
-<!-- Citas textuales, historias y ejemplos capturados durante la entrevista.
-     Registra el lenguaje exacto — la paráfrasis va en la Síntesis, no aquí.
-     Incluye la atribución del hablante si la sesión es multi-fundador. -->
-
-### Creencia central (¿por qué existe esto?)
-
-### El Cómo conductual (valores en acción, no eslóganes de póster)
-
-### Lo que la marca se niega a ser o hacer
-
-### Citas del fundador con fuerza suficiente para convertirse en anclas internas
-
----
-
-## Síntesis
-
-<!-- Tu interpretación del material en bruto.
-     Escribe tres secciones: formulaciones, preguntas abiertas, contradicciones. -->
-
-### Formulaciones candidatas del Porqué (ofrece 2–3 versiones, varía registro y especificidad)
-
-1.
-2.
-3.
-
-### Preguntas abiertas / hilos a seguir en módulos posteriores
-
-### Contradicciones o tensiones entre participantes (solo multi-fundador)
-
-### ¿Cómo restringe o habilita este Porqué el posicionamiento? (puente al Módulo 20)

package/vendor/theus-arsenal/skills/descubrimiento-marca/references/20_posicionamiento.md

@@ -1,47 +0,0 @@
-# Módulo 20 — Posicionamiento
-
-> **Marcos:** Dunford *Obviously Awesome* · Plantilla crossing-the-chasm de Moore ·
-> Lente jobs-to-be-done
->
-> **Objetivo:** definir el marco competitivo de la marca — para quién es, en qué
-> categoría compite, qué hace de forma única y por qué eso le importa al cliente
-> objetivo. El resultado es la materia prima de una declaración de posicionamiento
-> sobre la que la marca pueda actuar.
-
----
-
-## Raw
-
-<!-- Citas textuales y ejemplos. Registra el lenguaje exacto. -->
-
-### ¿Quién es el cliente objetivo? (rol, tipo de empresa, situación)
-
-### ¿En qué categoría compite la marca? (cómo resuelven hoy este problema los clientes)
-
-### ¿Qué diferencia a la marca de las alternativas de esa categoría?
-
-### ¿Qué es lo que más le importa al cliente objetivo? (el valor que recibe y que otros no pueden igualar)
-
-### Alternativas competitivas nombradas por el fundador (incluye "no hacer nada" / "contratar internamente")
-
-### Frases o metáforas que el fundador usa con naturalidad para describir lo que hace
-
----
-
-## Síntesis
-
-### Borrador de declaración de posicionamiento (plantilla de Dunford)
-> Para **[cliente objetivo]** que **[situación / JTBD]**, **[nombre de la marca]** es
-> la **[categoría]** que **[valor único]**. A diferencia de **[alternativas]**,
-> nosotros **[diferenciador clave]**.
-
-### Encuadres alternativos (varía la categoría o el diferenciador)
-
-1.
-2.
-
-### Hipótesis de espacio en blanco (lo que ningún competidor reclama y esta marca podría poseer)
-
-### Preguntas abiertas / ambigüedades
-
-### Tensiones con el Porqué del Módulo 10 (marca cualquier contradicción para la reconciliación del Módulo 90)

package/vendor/theus-arsenal/skills/descubrimiento-marca/references/30_audiencia-nicho.md

@@ -1,53 +0,0 @@
-# Módulo 30 — Audiencia y nicho
-
-> **Marcos:** Baker *The Business of Expertise* · Perfil de cliente ideal (ICP) ·
-> Lente dolor / disparador / resultado deseado
->
-> **Objetivo:** hacer la audiencia objetivo lo bastante concreta como para dar el
-> brief a un copywriter o lanzar una campaña de pago — no un boceto demográfico,
-> sino un retrato psicográfico y situacional del mejor cliente del que la marca
-> quiere más.
-
----
-
-## Raw
-
-<!-- Citas textuales y ejemplos. -->
-
-### ¿Quién es el cliente ideal? (describe a una persona concreta, no un segmento)
-
-### ¿Qué situación o disparador lo lleva a buscar ayuda?
-
-### ¿Qué ha probado antes y por qué se quedó corto?
-
-### ¿Cómo se ve el éxito para esa persona? (en sus palabras, no en las de la marca)
-
-### ¿Qué teme o quiere evitar?
-
-### Clientes de peor encaje (con quiénes la marca no quiere trabajar, y por qué)
-
-### Citas o historias de clientes reales que ilustren el encaje ideal
-
----
-
-## Síntesis
-
-### Perfil de cliente ideal (ICP)
-
-| Dimensión | Descripción |
-|---|---|
-| Rol / cargo | |
-| Tipo y tamaño de organización | |
-| Situación disparadora | |
-| Dolor principal | |
-| Resultado deseado | |
-| Señal de presupuesto | |
-| Bandera roja / descalificador | |
-
-### Retrato psicográfico (2–3 frases: cómo piensa esta persona, qué valora, de qué desconfía)
-
-### Hipótesis de nicho (el mercado viable más pequeño que la marca podría poseer con credibilidad)
-
-### Segmentos de audiencia a probar (si hay ambigüedad entre ICP primario y secundario)
-
-### Preguntas abiertas / hilos para la reconciliación con el posicionamiento del Módulo 20