theus-cli-linux-x64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/skills/motor-de-contenido/SKILL.md

@@ -1,136 +0,0 @@
----
-name: motor-de-contenido
-description: Crea sistemas de contenido nativos por plataforma para X, LinkedIn, TikTok, YouTube,
-  newsletters y campañas multiplataforma reutilizadas. Úsala cuando el usuario quiera publicaciones
-  sociales, hilos, guiones, calendarios de contenido o adaptar un activo fuente a varias plataformas.
----
-
-# Motor de contenido
-
-Construye contenido nativo por plataforma sin aplanar la voz real del autor en el tono genérico de cada red.
-
-## Cuándo activarla
-
-- Al escribir publicaciones o hilos para X.
-- Al redactar publicaciones de LinkedIn o anuncios de lanzamiento.
-- Al guionizar video corto o explicativos de YouTube.
-- Al reutilizar artículos, pódcast, demos, documentación o notas internas como contenido público.
-- Al construir una secuencia de lanzamiento o un sistema de contenido continuo alrededor de un producto, un hallazgo o una narrativa.
-
-## Innegociables
-
-1. Parte del material fuente, no de fórmulas genéricas de publicación.
-2. Adapta el formato a la plataforma, no la personalidad del autor.
-3. Una publicación debe sostener una sola afirmación real.
-4. La especificidad vence a los adjetivos.
-5. Nada de cebos de interacción salvo que el usuario lo pida explícitamente.
-
-## Flujo con la fuente primero
-
-Antes de redactar, identifica el conjunto de fuentes:
-
-- artículos publicados
-- notas o memos internos
-- demos de producto
-- documentación o changelogs
-- transcripciones
-- capturas de pantalla
-- publicaciones previas del mismo autor
-
-Si el usuario quiere una voz específica, construye un perfil de voz a partir de ejemplos reales antes de escribir.
-Usa `voz-de-marca` como flujo canónico cuando la consistencia de voz importe en más de una salida.
-
-## Manejo de la voz
-
-`voz-de-marca` es la capa canónica de voz.
-
-Ejecútala primero cuando:
-
-- haya múltiples salidas derivadas
-- el usuario dé importancia explícita al estilo de escritura
-- el contenido sea de lanzamiento, alcance externo o sensible para la reputación
-
-Reutiliza aquí el `PERFIL DE VOZ` resultante en lugar de reconstruir un segundo modelo de voz.
-Si el usuario pide imitar la voz de un autor concreto, trata igualmente a `voz-de-marca` como fuente de verdad y aliméntala con el mejor material real o derivado de la fuente disponible.
-
-## Prohibiciones estrictas
-
-Elimina y reescribe cualquiera de estas fórmulas:
-
-- "En el panorama actual en constante evolución"
-- "revolucionario", "disruptivo", "de vanguardia" como relleno
-- "esto es importante porque" si no va seguido de inmediato por algo concreto
-- cerrar con una pregunta estilo LinkedIn solo para cosechar respuestas
-- informalidad forzada en LinkedIn
-- relleno de interacción falsa que no estaba en el material fuente
-
-## Reglas de adaptación por plataforma
-
-### X
-
-- Abre con la afirmación, el artefacto o la tensión más fuerte.
-- Conserva la compresión si la voz de la fuente es comprimida.
-- Si escribes un hilo, cada publicación debe hacer avanzar el argumento.
-- No rellenes con contexto que la audiencia no necesita.
-
-### LinkedIn
-
-- Expande solo lo necesario para que gente fuera del nicho inmediato pueda seguir el hilo.
-- No lo conviertas en una falsa "lección aprendida" salvo que el material fuente sea realmente reflexivo.
-- Nada de cadencia inspiracional corporativa.
-- Nada de acumulación de elogios ni relleno de "mi trayectoria".
-
-### Video corto
-
-- Guioniza alrededor de la secuencia visual y las pruebas concretas.
-- Los primeros segundos deben mostrar el resultado, el problema o el golpe.
-- No escribas narración que suene mejor en papel que en pantalla.
-
-### YouTube
-
-- Muestra el resultado o la tensión temprano.
-- Organiza por argumento o progresión, no por secciones de relleno.
-- Usa capítulos solo cuando aporten claridad.
-
-### Newsletter
-
-- Abre con el punto, el conflicto o el artefacto.
-- No gastes el primer párrafo en calentar.
-- Cada sección debe aportar algo nuevo.
-
-## Flujo de reutilización
-
-1. Elige el activo ancla.
-2. Extrae de 3 a 7 afirmaciones o escenas atómicas.
-3. Ordénalas por filo, novedad y prueba.
-4. Asigna una idea fuerte por salida.
-5. Adapta la estructura a cada plataforma.
-6. Elimina el relleno con forma de plataforma.
-7. Pasa la puerta de calidad.
-
-## Entregables
-
-Cuando se pida una campaña, devuelve:
-
-- un perfil de voz breve si el ajuste de voz importa
-- el ángulo central
-- borradores nativos por plataforma
-- orden de publicación solo si ayuda a la ejecución
-- los vacíos que deben cerrarse antes de publicar
-
-## Puerta de calidad
-
-Antes de entregar:
-
-- cada borrador suena al autor previsto, no al estereotipo de la plataforma
-- cada borrador contiene una afirmación real, una prueba o una observación concreta
-- no queda lenguaje de bombo genérico
-- no quedan cebos de interacción falsos
-- no hay copia duplicada entre plataformas salvo que se pida
-- cualquier llamada a la acción está ganada y aprobada por el usuario
-
-## Skills relacionadas
-
-- `voz-de-marca` para perfiles de voz derivados de fuentes reales
-- `publicacion-cruzada` para la distribución específica por plataforma
-- `api-x` para obtener publicaciones recientes y publicar en X el contenido aprobado

package/vendor/theus-arsenal/skills/no-conformidades-calidad/SKILL.md

@@ -1,249 +0,0 @@
----
-name: no-conformidades-calidad
-description: Experiencia codificada para control de calidad, investigación de no conformidades, análisis de causa raíz, acción correctiva (CAPA), interpretación de SPC y gestión de calidad de proveedores en manufactura regulada. Úsala al investigar no conformidades, hacer análisis de causa raíz, gestionar CAPAs, interpretar datos de SPC o manejar problemas de calidad de proveedores.
----
-
-# Gestión de calidad y no conformidades
-
-## Rol y contexto
-
-Actúas como ingeniero de calidad sénior con más de 15 años en entornos de manufactura regulada: FDA 21 CFR 820 (dispositivos médicos), IATF 16949 (automotriz), AS9100 (aeroespacial) e ISO 13485 (dispositivos médicos). Gestionas el ciclo de vida completo de la no conformidad, desde la inspección de recepción hasta la disposición final. Tus sistemas incluyen QMS (plataformas eQMS como MasterControl, ETQ, Veeva), software de SPC (Minitab, InfinityQS), ERP (SAP QM, Oracle Quality), equipos de CMM y metrología, y portales de proveedores. Te sitúas en la intersección de manufactura, ingeniería, compras, regulatorio y calidad de cliente. Tus decisiones afectan directamente la seguridad del producto, el cumplimiento regulatorio, el throughput de producción y las relaciones con proveedores.
-
-## Cuándo usarla
-
-- Investigar una no conformidad (NCR) de inspección de recepción, en proceso o de prueba final.
-- Realizar análisis de causa raíz con métodos de 5 Porqués, Ishikawa o árbol de fallas.
-- Determinar la disposición de material no conforme (usar como está, retrabajar, desechar, devolver al proveedor).
-- Crear o revisar un plan CAPA (acción correctiva y preventiva).
-- Interpretar datos de SPC y señales de gráficas de control para evaluar la estabilidad de un proceso.
-- Prepararse o responder a un hallazgo de auditoría regulatoria.
-
-## Cómo funciona
-
-1. Detecta la no conformidad mediante inspección, alerta de SPC o queja de cliente.
-2. Contén el material afectado de inmediato (cuarentena, retención de producción, paro de embarque).
-3. Clasifica la severidad (crítica, mayor, menor) según impacto en seguridad y requisitos regulatorios.
-4. Investiga la causa raíz con la metodología adecuada a la complejidad.
-5. Determina la disposición según la evaluación de ingeniería, las restricciones regulatorias y la economía.
-6. Implementa la acción correctiva, verifica su eficacia y cierra la CAPA con evidencia.
-
-## Ejemplos
-
-- **Falla en inspección de recepción**: un lote de 10 000 componentes moldeados falla el muestreo AQL en Nivel II. El defecto es una desviación dimensional de +0.15 mm en una característica crítica para la función. Recorre contención, notificación al proveedor, investigación de causa raíz (desgaste de herramienta), suspensión de skip-lot y emisión de SCAR.
-- **Interpretación de señal de SPC**: una gráfica X-barra de una línea de llenado muestra 9 puntos consecutivos por encima de la línea central (Regla 2 de Western Electric). El proceso sigue dentro de los límites de especificación. Determina si detener la línea (investigación de causa asignable) o continuar la producción (y por qué "en especificación" no es lo mismo que "en control").
-- **CAPA por queja de cliente**: un cliente OEM automotriz reporta 3 fallas de campo en 500 unidades, todas con el mismo modo de falla. Construye la respuesta 8D, realiza análisis de árbol de fallas, identifica el punto de escape en la prueba final y diseña las pruebas de verificación de la acción correctiva.
-
-## Conocimiento base
-
-### Ciclo de vida de la NCR
-
-Toda no conformidad sigue un ciclo de vida controlado. Saltarse pasos genera hallazgos de auditoría y riesgo regulatorio:
-
-- **Identificación:** cualquiera puede iniciarla. Registra: quién la encontró, dónde (recepción, en proceso, final, campo), qué norma/especificación se violó, cantidad afectada, trazabilidad de lote/batch. Etiqueta o pon en cuarentena el material no conforme de inmediato, sin excepción. Segregación física con etiqueta roja o de retención en un área designada de MRB. Retención electrónica en el ERP para prevenir embarque inadvertido.
-- **Documentación:** número de NCR asignado según el esquema de numeración de tu QMS. Vincula con número de parte, revisión, PO/orden de trabajo, cláusula de especificación violada, datos de medición (reales vs. tolerancias), fotografías e ID del inspector. Para productos regulados por la FDA, los registros deben satisfacer 21 CFR 820.90; para automotriz, IATF 16949 §8.7.
-- **Investigación:** determina el alcance: ¿es una pieza aislada o un problema sistémico del lote? Revisa aguas arriba y aguas abajo: otros lotes del mismo embarque del proveedor, otras unidades de la misma corrida de producción, inventario de WIP y producto terminado del mismo periodo. Las acciones de contención deben ocurrir antes de iniciar el análisis de causa raíz.
-- **Disposición vía MRB (Comité de revisión de material):** el MRB suele incluir representantes de calidad, ingeniería y manufactura. Para aeroespacial (AS9100), el cliente puede necesitar participar. Opciones de disposición:
-  - **Usar como está:** la parte no cumple el plano pero es funcionalmente aceptable. Requiere justificación de ingeniería (concesión/desviación). En aeroespacial requiere aprobación del cliente según AS9100 §8.7.1. En automotriz, típicamente se requiere notificación al cliente. Documenta el fundamento: "porque necesitamos las partes" no es una justificación.
-  - **Retrabajo:** llevar la parte a conformidad usando un procedimiento de retrabajo aprobado. La instrucción de retrabajo debe documentarse y la parte retrabajada debe reinspeccionarse contra la especificación original. Registra los costos de retrabajo.
-  - **Reparación:** la parte no cumplirá plenamente la especificación original pero quedará funcional. Requiere disposición de ingeniería y a menudo concesión del cliente. Diferente del retrabajo: la reparación acepta una desviación permanente.
-  - **Devolución al proveedor (RTV):** emite una Solicitud de Acción Correctiva a Proveedor (SCAR) o CAR. Nota de débito o PO de reemplazo. Rastrea la respuesta del proveedor dentro de los plazos acordados. Actualiza el scorecard del proveedor.
-  - **Desecho (scrap):** documenta el desecho con cantidad, costo, trazabilidad de lote y aprobación de scrap autorizada (a menudo requiere firma de dirección por encima de un umbral monetario). Para partes serializadas o críticas de seguridad, atestigua la destrucción.
-
-### Análisis de causa raíz
-
-Detenerse en los síntomas es el modo de falla más común en investigaciones de calidad:
-
-- **5 Porqués:** simple y efectivo para fallas de proceso directas. Limitación: asume una única cadena causal lineal. Falla en problemas complejos multifactor. Cada "porqué" debe verificarse con datos, no con opinión: "¿Por qué se desvió la dimensión?" → "Porque se desgastó la herramienta" solo es válido si mediste el desgaste.
-- **Diagrama de Ishikawa (espina de pescado):** usa el marco de las 6M (Mano de obra, Máquina, Material, Método, Medición, Medio ambiente). Obliga a considerar todas las categorías de causa potencial. Su mayor utilidad es como marco de lluvia de ideas para prevenir la convergencia prematura en una sola causa. No es una herramienta de causa raíz por sí sola: genera hipótesis que requieren verificación.
-- **Análisis de árbol de fallas (FTA):** descendente, deductivo. Parte del evento de falla y descompón en causas contribuyentes usando compuertas lógicas AND/OR. Cuantitativo cuando hay datos de tasa de falla. Requerido o esperado en contextos aeroespacial (AS9100) y de dispositivos médicos (análisis de riesgo ISO 14971). El método más riguroso pero intensivo en recursos.
-- **Metodología 8D:** resolución estructurada de problemas en equipo. D0: reconocimiento del síntoma y respuesta de emergencia. D1: formación del equipo. D2: definición del problema (ES/NO ES). D3: contención interina. D4: identificación de causa raíz (usa espina de pescado + 5 Porqués dentro del 8D). D5: selección de acción correctiva. D6: implementación. D7: prevención de recurrencia. D8: reconocimiento del equipo. Los OEM automotrices (GM, Ford, Stellantis) esperan reportes 8D para problemas significativos de calidad de proveedor.
-- **Señales de alerta de que te detuviste en síntomas:** tu "causa raíz" contiene la palabra "error" (el error humano nunca es causa raíz: ¿por qué el sistema permitió el error?), tu acción correctiva es "recapacitar al operador" (la capacitación por sí sola es la acción correctiva más débil), o tu causa raíz es el enunciado del problema reformulado.
-
-### Sistema CAPA
-
-CAPA es la columna vertebral regulatoria. La FDA cita deficiencias de CAPA más que cualquier otro subsistema:
-
-- **Iniciación:** no toda NCR requiere una CAPA. Disparadores: no conformidades repetidas (mismo modo de falla 3+ veces), quejas de cliente, hallazgos de auditoría, fallas de campo, análisis de tendencias (señales de SPC), observaciones regulatorias. Sobreiniciar CAPAs diluye recursos y crea rezago de cierres. Subiniciar genera hallazgos de auditoría.
-- **Acción correctiva vs. preventiva:** la correctiva atiende una no conformidad existente y previene su recurrencia. La preventiva atiende una no conformidad potencial que aún no ocurre, típicamente identificada mediante análisis de tendencias, evaluación de riesgo o eventos de cuasi-falla. Se esperan ambas; no las confundas.
-- **Redactar CAPAs eficaces:** la acción debe ser específica, medible y atender la causa raíz verificada. Mala: "Mejorar los procedimientos de inspección." Buena: "Agregar paso de verificación de torque en la Estación 12 con torquímetro calibrado (±2 %), documentado en la lista de verificación del viajero WI-4401 Rev C, efectivo antes del 2025-04-15." Toda CAPA debe tener un responsable, una fecha objetivo y evidencia de terminación definida.
-- **Verificación vs. validación de eficacia:** la verificación confirma que la acción se implementó como se planeó (¿instalamos el dispositivo poka-yoke?). La validación confirma que la acción realmente previno la recurrencia (¿la tasa de defectos cayó a cero en 90 días de datos de producción?). Se esperan ambas. Cerrar una CAPA en la verificación sin validación es un hallazgo de auditoría común.
-- **Criterios de cierre:** evidencia objetiva de que la acción correctiva se implementó Y fue eficaz. Periodo mínimo de monitoreo de eficacia: 90 días para cambios de proceso, 3 lotes de producción para cambios de material, o el siguiente ciclo de auditoría para cambios de sistema. Documenta los datos de eficacia: gráficas, tasas de rechazo, resultados de auditoría.
-- **Expectativas regulatorias:** FDA 21 CFR 820.198 (manejo de quejas) y 820.90 (producto no conforme) alimentan 820.100 (CAPA). IATF 16949 §10.2.3-10.2.6. AS9100 §10.2. ISO 13485 §8.5.2-8.5.3. Cada norma tiene expectativas específicas de documentación y tiempos.
-
-### Control estadístico de procesos (SPC)
-
-El SPC separa la señal del ruido. Malinterpretar las gráficas causa más problemas que no graficar:
-
-- **Selección de gráfica:** X-barra/R para datos continuos con subgrupos (n=2-10). X-barra/S para subgrupos n>10. Individual/Rango móvil (I-MR) para datos continuos con subgrupo n=1 (procesos por lote, pruebas destructivas). Gráfica p para proporción de defectuosos (tamaño de muestra variable). Gráfica np para conteo de defectuosos (tamaño de muestra fijo). Gráfica c para conteo de defectos por unidad (área de oportunidad fija). Gráfica u para defectos por unidad (área de oportunidad variable).
-- **Índices de capacidad:** Cp mide la dispersión del proceso vs. el ancho de la especificación (capacidad potencial). Cpk ajusta por centrado (capacidad real). Pp/Ppk usan variación total (largo plazo) vs. Cp/Cpk que usan variación dentro del subgrupo (corto plazo). Un proceso con Cp=2.0 pero Cpk=0.8 es capaz pero no está centrado: corrige la media, no la variación. Automotriz (IATF 16949) típicamente requiere Cpk ≥ 1.33 para procesos establecidos y Ppk ≥ 1.67 para procesos nuevos.
-- **Reglas de Western Electric (señales más allá de los límites de control):** Regla 1: un punto más allá de 3σ. Regla 2: nueve puntos consecutivos de un lado de la línea central. Regla 3: seis puntos consecutivos con incremento o decremento sostenido. Regla 4: catorce puntos consecutivos alternando arriba y abajo. La Regla 1 exige acción inmediata. Las Reglas 2-4 indican causas sistemáticas que requieren investigación antes de que el proceso salga de especificación.
-- **El problema del sobreajuste:** reaccionar a la variación de causa común ajustando el proceso incrementa la variación; esto es manipular (tampering). Si la gráfica muestra un proceso estable dentro de límites de control pero los puntos individuales "se ven altos", no ajustes. Solo ajusta ante señales de causa especial confirmadas por las reglas de Western Electric.
-- **Causa común vs. especial:** la variación de causa común es inherente al proceso; reducirla requiere cambios fundamentales (mejor equipo, material distinto, controles ambientales). La variación de causa especial es asignable a un evento específico: una herramienta desgastada, un nuevo lote de materia prima, un operador sin capacitación en el segundo turno. La función primaria del SPC es detectar causas especiales con rapidez.
-
-### Inspección de recepción
-
-- **Planes de muestreo AQL (ANSI/ASQ Z1.4 / ISO 2859-1):** determina el nivel de inspección (I, II, III; el Nivel II es estándar), tamaño de lote, valor AQL y letra de código de tamaño de muestra. Inspección reforzada: cambia tras rechazar 2 de 5 lotes consecutivos. Normal: por defecto. Reducida: cambia tras 10 lotes consecutivos aceptados Y producción estable. Defectos críticos: AQL = 0 con tamaño de muestra apropiado. Defectos mayores: típicamente AQL 1.0-2.5. Defectos menores: típicamente AQL 2.5-6.5.
-- **LTPD (Porcentaje de defectuosos tolerado en el lote):** el nivel de defectos que el plan está diseñado para rechazar. El AQL protege al productor (bajo riesgo de rechazar lotes buenos). El LTPD protege al consumidor (bajo riesgo de aceptar lotes malos). Entender ambos lados es crítico para comunicar el riesgo de inspección a la dirección.
-- **Calificación de skip-lot:** después de que un proveedor demuestra calidad consistente (típicamente 10+ lotes consecutivos aceptados en inspección normal), reduce la frecuencia a inspeccionar cada 2.º, 3.º o 5.º lote. Revierte de inmediato ante cualquier rechazo. Requiere criterios de calificación formales y decisión documentada.
-- **Confianza en el Certificado de Conformidad (CoC):** cuándo confiar en los CoC del proveedor vs. hacer inspección de recepción: proveedor nuevo = siempre inspecciona; proveedor calificado con historial = CoC + verificación reducida; dimensiones críticas/de seguridad = siempre inspecciona sin importar el historial. Confiar en el CoC requiere un acuerdo documentado y verificación de auditoría periódica (audita el proceso de inspección final del proveedor, no solo el papeleo).
-
-### Gestión de calidad de proveedores
-
-- **Metodología de auditoría:** las auditorías de proceso evalúan cómo se hace el trabajo (observar, entrevistar, muestrear). Las de sistema evalúan el cumplimiento del QMS (revisión de documentos, muestreo de registros). Las de producto verifican características específicas del producto. Usa un cronograma de auditoría basado en riesgo: proveedores de alto riesgo anualmente, medio cada dos años, bajo cada 3 años más auditorías por causa. Anuncia las auditorías de sistema; usa auditorías sin previo aviso para verificación de proceso cuando existan preocupaciones de desempeño.
-- **Scorecards de proveedor:** mide PPM (partes por millón defectuosas), entregas a tiempo, tiempo de respuesta de SCAR, eficacia de SCAR (tasa de recurrencia) y tasa de aceptación de lotes. Pondera las métricas por impacto de negocio. Comparte los scorecards trimestralmente. Los puntajes guían ajustes de nivel de inspección, asignación de negocio y estatus de ASL.
-- **Solicitudes de acción correctiva (CAR/SCAR):** emítelas por cada no conformidad significativa o por no conformidades menores repetidas. Espera análisis de causa raíz 8D o equivalente. Fija plazo de respuesta (típicamente 10 días hábiles para respuesta inicial, 30 días para plan de acción correctiva completo). Da seguimiento a la verificación de eficacia.
-- **Lista de proveedores aprobados (ASL):** el ingreso requiere calificación (primer artículo, estudio de capacidad, auditoría de sistema). El mantenimiento requiere desempeño continuo dentro de los umbrales del scorecard. La remoción es una decisión de negocio significativa que requiere acuerdo de compras, ingeniería y calidad más un plan de transición. El estatus provisional (aprobado con condiciones) es útil para proveedores bajo planes de mejora.
-- **Decisiones de desarrollar vs. cambiar:** el desarrollo de proveedor (inversión en capacitación, mejora de proceso, herramentales) tiene sentido cuando: el proveedor tiene capacidad única, los costos de cambio son altos, la relación es sólida por lo demás y las brechas de calidad son atendibles. Cambiar tiene sentido cuando: el proveedor no está dispuesto a invertir, la tendencia de calidad se deteriora a pesar de las CAR, o existen fuentes calificadas alternativas con menor costo total de la calidad.
-
-### Marcos regulatorios
-
-- **FDA 21 CFR 820 (QSR):** cubre sistemas de calidad de dispositivos médicos. Secciones clave: 820.90 (producto no conforme), 820.100 (CAPA), 820.198 (manejo de quejas), 820.250 (técnicas estadísticas). Los auditores de la FDA revisan específicamente la eficacia del sistema CAPA, el análisis de tendencias de quejas y si el análisis de causa raíz es riguroso.
-- **IATF 16949 (Automotriz):** agrega requisitos específicos del cliente sobre ISO 9001. Planes de control, PPAP (Proceso de aprobación de partes de producción), MSA (Análisis de sistemas de medición), reportes 8D, gestión de características especiales. Se requiere notificación al cliente para cambios de proceso y disposición de no conformidades.
-- **AS9100 (Aeroespacial):** agrega requisitos de seguridad del producto, prevención de partes falsificadas, gestión de configuración, inspección de primer artículo (FAI según AS9102) y gestión de características clave. Se requiere aprobación del cliente para disposiciones de usar-como-está. Base de datos OASIS para gestión de proveedores.
-- **ISO 13485 (Dispositivos médicos):** armonizada con la QSR de la FDA pero con alineación regulatoria europea. Énfasis en gestión de riesgo (ISO 14971), trazabilidad y controles de diseño. Los requisitos de investigación clínica alimentan la gestión de no conformidades.
-- **Planes de control:** definen características de inspección, métodos, frecuencias, tamaños de muestra, planes de reacción y responsables para cada paso del proceso. Requeridos por IATF 16949 y buena práctica universal. Deben ser un documento vivo actualizado cuando cambian los procesos.
-
-### Costo de la calidad
-
-Construye el caso de negocio para la inversión en calidad usando el modelo de COQ de Juran:
-
-- **Costos de prevención:** capacitación, validación de procesos, revisiones de diseño, calificación de proveedores, implementación de SPC, dispositivos poka-yoke. Típicamente 5-10 % del COQ total. Cada dólar invertido aquí devuelve entre 10 y 100 dólares en costos de falla evitados.
-- **Costos de evaluación:** inspección de recepción, inspección en proceso, inspección final, pruebas, calibración, costos de auditoría. Típicamente 20-25 % del COQ total.
-- **Costos de falla interna:** scrap, retrabajo, reinspección, procesamiento de MRB, retrasos de producción por no conformidades, labor de investigación de causa raíz. Típicamente 25-40 % del COQ total.
-- **Costos de falla externa:** devoluciones de cliente, reclamos de garantía, servicio de campo, retiros del mercado, acciones regulatorias, exposición de responsabilidad, daño reputacional. Típicamente 25-40 % del COQ total pero el más volátil y de mayor costo por incidente.
-
-## Marcos de decisión
-
-### Lógica de decisión de disposición de NCR
-
-Evalúa en esta secuencia; la primera ruta que aplique gobierna la disposición:
-
-1. **Crítico de seguridad/regulatorio:** si la no conformidad afecta una característica crítica de seguridad o un requisito regulatorio → no usar como está. Retrabaja si es posible hasta conformidad total; de lo contrario, desecha. Sin excepciones sin evaluación formal de riesgo de ingeniería y, cuando aplique, notificación regulatoria.
-2. **Requisitos específicos del cliente:** si la especificación del cliente es más estricta que la de diseño y la parte cumple diseño pero no requisitos del cliente → contacta al cliente para concesión antes de disponer. Los clientes automotrices y aeroespaciales tienen procesos de concesión explícitos.
-3. **Impacto funcional:** ingeniería evalúa si la no conformidad afecta forma, ajuste o función. Si no hay impacto funcional y está dentro de la autoridad de revisión de material → usar como está con justificación de ingeniería documentada. Si hay impacto funcional → retrabajo o desecho.
-4. **Reprocesabilidad:** si la parte puede llevarse a conformidad total mediante un proceso de retrabajo aprobado → retrabajo. Verifica costo de retrabajo vs. costo de reemplazo. Si el costo de retrabajo excede el 60 % del costo de reemplazo, el desecho suele ser más económico.
-5. **Responsabilidad del proveedor:** si la no conformidad es causada por el proveedor → RTV con SCAR. Excepción: si la producción no puede esperar partes de reemplazo, puede requerirse usar como está o retrabajar con recuperación de costo del proveedor.
-
-### Selección de método de RCA
-
-- **Evento único, cadena causal simple:** 5 Porqués. Presupuesto: 1-2 horas.
-- **Evento único, múltiples categorías de causa potencial:** Ishikawa + 5 Porqués en las ramas más probables. Presupuesto: 4-8 horas.
-- **Problema recurrente, relacionado con el proceso:** 8D con equipo completo. Presupuesto: 20-40 horas a través de D0-D8.
-- **Evento crítico de seguridad o de alta severidad:** Análisis de árbol de fallas con evaluación cuantitativa de riesgo. Presupuesto: 40-80 horas. Requerido para eventos de seguridad de producto aeroespacial y análisis post-mercado de dispositivos médicos.
-- **Formato mandado por el cliente:** usa lo que el cliente requiera (la mayoría de los OEM automotrices exigen 8D).
-
-### Verificación de eficacia de CAPA
-
-Antes de cerrar cualquier CAPA, verifica:
-
-1. **Evidencia de implementación:** prueba documentada de que la acción se completó (instrucción de trabajo actualizada con revisión, dispositivo instalado con validación, plan de inspección modificado con fecha efectiva).
-2. **Datos del periodo de monitoreo:** mínimo 90 días de datos de producción, 3 lotes de producción consecutivos, o un ciclo de auditoría completo, lo que aporte la evidencia más significativa.
-3. **Verificación de recurrencia:** cero recurrencias del modo de falla específico durante el periodo de monitoreo. Si hay recurrencia, la CAPA no es eficaz: reábrela y reinvestiga. No cierres y abras una nueva CAPA para el mismo problema.
-4. **Revisión de indicadores adelantados:** más allá de la falla específica, ¿mejoraron las métricas relacionadas? (p. ej., PPM general de ese proceso, tasa de quejas de cliente para esa familia de producto).
-
-### Ajuste de nivel de inspección
-
-| Condición | Acción |
-|---|---|
-| Proveedor nuevo, primeros 5 lotes | Inspección reforzada (Nivel III o 100 %) |
-| 10+ lotes consecutivos aceptados en normal | Calificar para reducida o skip-lot |
-| 1 lote rechazado bajo inspección reducida | Revertir a normal de inmediato |
-| 2 de 5 lotes consecutivos rechazados en normal | Cambiar a reforzada |
-| 5 lotes consecutivos aceptados en reforzada | Revertir a normal |
-| 10 lotes consecutivos rechazados en reforzada | Suspender al proveedor; escalar a compras |
-| Queja de cliente rastreada a material de recepción | Revertir a reforzada sin importar el nivel actual |
-
-### Escalamiento de acción correctiva de proveedor
-
-| Etapa | Disparador | Acción | Plazo |
-|---|---|---|---|
-| Nivel 1: SCAR emitida | NC significativa única o 3+ NC menores en 90 días | SCAR formal que exige respuesta 8D | 10 días para respuesta, 30 para implementación |
-| Nivel 2: Proveedor en observación | SCAR no respondida a tiempo, o acción correctiva no eficaz | Inspección incrementada, proveedor en periodo de prueba, compras notificado | 60 días para demostrar mejora |
-| Nivel 3: Embarque controlado | Fallas de calidad continuas durante la observación | El proveedor debe enviar datos de inspección con cada embarque; o sorteo por tercero a costo del proveedor | 90 días para demostrar mejora sostenida |
-| Nivel 4: Calificación de nueva fuente | Sin mejora bajo embarque controlado | Iniciar calificación de proveedor alterno; reducir asignación de negocio | Cronograma de calificación (3-12 meses según industria) |
-| Nivel 5: Remoción de ASL | Incapacidad o falta de disposición para mejorar | Remoción formal de la Lista de proveedores aprobados; transición de todas las partes | Completar la transición antes de la PO final |
-
-## Casos límite clave
-
-Estas son situaciones donde el enfoque obvio es incorrecto. Se incluyen resúmenes breves para que los expandas en playbooks específicos del proyecto si es necesario.
-
-1. **Falla de campo reportada por el cliente sin detección interna:** tu inspección y prueba aprobaron este lote, pero los datos de campo del cliente muestran fallas. El instinto es cuestionar los datos del cliente; resístelo. Verifica si tu plan de inspección cubre el modo de falla real. A menudo las fallas de campo revelan brechas en la cobertura de prueba, no errores de ejecución.
-
-2. **Auditoría de proveedor revela Certificados de Conformidad falsificados:** el proveedor ha enviado CoC con datos de prueba fabricados. Pon en cuarentena todo el material de ese proveedor de inmediato, incluidos WIP y producto terminado. Es un evento reportable regulatoriamente en aeroespacial (prevención de falsificados según AS9100) y potencialmente en dispositivos médicos. La escala de la contención impulsa la respuesta, no la NCR individual.
-
-3. **SPC muestra proceso en control pero las quejas de cliente aumentan:** la gráfica es estable dentro de límites de control, pero el proceso de ensamble del cliente es sensible a la variación dentro de tu especificación. Tu proceso es "capaz" por los números pero no lo suficiente. Esto requiere colaboración con el cliente para entender el requisito funcional real, no solo una revisión de especificación.
-
-4. **No conformidad descubierta en producto ya embarcado:** la contención debe extenderse al inventario de recepción del cliente, su WIP y potencialmente a sus clientes. La velocidad de notificación depende del riesgo de seguridad: los problemas críticos de seguridad requieren notificación inmediata al cliente, los demás pueden seguir el proceso estándar con urgencia.
-
-5. **CAPA que atiende un síntoma, no la causa raíz:** el defecto reincide tras el cierre de la CAPA. Antes de reabrir, verifica el análisis de causa raíz original: si la causa raíz fue "error del operador" y la acción correctiva fue "recapacitar", ni la causa raíz ni la acción fueron adecuadas. Reinicia el RCA asumiendo que la primera investigación fue insuficiente.
-
-6. **Múltiples causas raíz para una sola no conformidad:** un solo defecto resulta de la interacción entre desgaste de máquina, variación de lote de material y una limitación del sistema de medición. Los 5 Porqués fuerzan una sola cadena; usa Ishikawa o FTA para capturar la interacción. Las acciones correctivas deben atender todas las causas contribuyentes; corregir solo una puede reducir la frecuencia pero no eliminará el modo de falla.
-
-7. **Defecto intermitente que no puede reproducirse a demanda:** no poder reproducir ≠ no existe. Incrementa el tamaño de muestra y la frecuencia de monitoreo. Busca correlaciones ambientales (turno, temperatura ambiente, humedad, vibración de equipo adyacente). Los estudios de componentes de variación (Gauge R&R con factores anidados) pueden revelar contribuciones intermitentes del sistema de medición.
-
-8. **No conformidad descubierta durante una auditoría regulatoria:** no intentes minimizarla ni explicarla. Reconoce el hallazgo, documéntalo en la respuesta de auditoría y trátalo como cualquier NCR: con investigación formal, análisis de causa raíz y CAPA. Los auditores prueban específicamente si tu sistema detecta lo que ellos encuentran; demostrar una respuesta robusta es más valioso que fingir que es una anomalía.
-
-## Patrones de comunicación
-
-### Calibración de tono
-
-Ajusta el tono de comunicación a la severidad de la situación y a la audiencia:
-
-- **NCR rutinaria, equipo interno:** directo y factual. "NCR-2025-0412: el lote de recepción 4471 de la parte 7832-A tiene mediciones de OD en 12.52 mm contra una especificación de 12.45±0.05 mm. 18 de 50 piezas de muestra fuera de especificación. Material en cuarentena en la jaula de MRB, Bahía 3."
-- **NCR significativa, reporte a dirección:** resume primero el impacto —impacto en producción, riesgo de cliente, exposición financiera— luego los detalles. Los directivos necesitan saber qué significa antes de saber qué pasó.
-- **Notificación a proveedor (SCAR):** profesional, específica y documentada. Enuncia la no conformidad, la especificación violada, el impacto y el formato y plazo de respuesta esperados. Nunca acusatorio; los datos hablan.
-- **Notificación a cliente (no conformidad en producto embarcado):** encabeza con lo que sabes, lo que has hecho (contención), lo que el cliente debe hacer y el plazo para la resolución total. La transparencia construye confianza; la demora la destruye.
-- **Respuesta regulatoria (hallazgo de auditoría):** factual, responsable y estructurada según la expectativa regulatoria (p. ej., formato de respuesta a FDA Form 483). Reconoce la observación, describe la investigación, enuncia la acción correctiva y aporta evidencia de implementación y eficacia.
-
-### Plantillas clave
-
-Aparecen plantillas breves. Adáptalas a tus flujos de MRB, calidad de proveedor y CAPA antes de usarlas en producción.
-
-**Notificación de NCR (interna):** Asunto: `NCR-{número}: {número_parte} — {resumen_defecto}`. Indica: qué se encontró, especificación violada, cantidad afectada, estatus de contención actual y evaluación inicial del alcance.
-
-**SCAR a proveedor:** Asunto: `SCAR-{número}: No conformidad en PO# {número_po} — Respuesta requerida antes del {fecha}`. Incluye: número de parte, lote, especificación, datos de medición, cantidad afectada, declaración de impacto, formato de respuesta esperado.
-
-**Notificación de calidad a cliente:** encabeza con: acciones de contención tomadas, trazabilidad del producto (números de lote/serie), acciones recomendadas al cliente, plazo para acción correctiva y contacto directo de ingeniería de calidad.
-
-## Protocolos de escalamiento
-
-### Disparadores de escalamiento automático
-
-| Disparador | Acción | Plazo |
-|---|---|---|
-| No conformidad crítica de seguridad | Notificar de inmediato a VP de Calidad y Regulatorio | En 1 hora |
-| Falla de campo o queja de cliente | Asignar investigador dedicado, notificar al equipo de cuenta | En 4 horas |
-| NCR repetida (mismo modo de falla, 3+ ocurrencias) | Iniciación obligatoria de CAPA, revisión de dirección | En 24 horas |
-| Documentación falsificada de proveedor | Cuarentena de todo el material del proveedor, notificar a regulatorio y legal | De inmediato |
-| No conformidad en producto embarcado | Iniciar protocolo de notificación al cliente, contención | En 4 horas |
-| Hallazgo de auditoría (externa) | Revisión de dirección, desarrollo de plan de respuesta | En 48 horas |
-| CAPA vencida > 30 días de la fecha objetivo | Escalar al Director de Calidad para asignación de recursos | En 1 semana |
-| Rezago de NCR excede 50 elementos abiertos | Revisión de proceso, asignación de recursos, informe a dirección | En 1 semana |
-
-### Cadena de escalamiento
-
-Nivel 1 (Ingeniero de Calidad) → Nivel 2 (Supervisor de Calidad, 4 horas) → Nivel 3 (Gerente de Calidad, 24 horas) → Nivel 4 (Director de Calidad, 48 horas) → Nivel 5 (VP de Calidad, 72+ horas o cualquier evento crítico de seguridad)
-
-## Indicadores de desempeño
-
-Rastrea estas métricas semanalmente y tendencia mensualmente:
-
-| Métrica | Objetivo | Señal de alerta |
-|---|---|---|
-| Tiempo de cierre de NCR (mediana) | < 15 días hábiles | > 30 días hábiles |
-| Tasa de cierre de CAPA a tiempo | > 90 % | < 75 % |
-| Tasa de eficacia de CAPA (sin recurrencia) | > 85 % | < 70 % |
-| PPM de proveedor (recepción) | < 500 PPM | > 2000 PPM |
-| Costo de la calidad (% de ingresos) | < 3 % | > 5 % |
-| Tasa de defectos interna (en proceso) | < 1000 PPM | > 5000 PPM |
-| Tasa de quejas de cliente (por 1M unidades) | < 50 | > 200 |
-| NCR envejecidas (> 30 días abiertas) | < 10 % del total | > 25 % |
-
-## Recursos adicionales
-
-- Combina esta skill con tu plantilla de NCR, matriz de autoridad de disposición y conjunto de reglas de SPC para que los investigadores usen las mismas definiciones cada vez.
-- Mantén los criterios de cierre de CAPA y los requisitos de evidencia de verificación de eficacia junto al flujo de trabajo antes de usarlo en producción.
-
-## Nota
-
-Esta skill es una guía metodológica y no sustituye la asesoría regulatoria, legal ni de ingeniería profesional. Las decisiones de disposición, notificación regulatoria y seguridad de producto deben validarse con las personas responsables y calificadas de tu organización.

package/vendor/theus-arsenal/skills/onboarding-codigo/SKILL.md

@@ -1,244 +0,0 @@
----
-name: onboarding-codigo
-description: Analiza un código desconocido y genera una guía de onboarding estructurada con mapa de arquitectura, puntos de entrada clave, convenciones y un THEUS.md inicial. Úsalo al unirte a un proyecto nuevo o al configurar Theus por primera vez en un repo.
----
-
-# Onboarding de código
-
-Analiza sistemáticamente un código desconocido y produce una guía de onboarding estructurada. Diseñado para desarrolladores que se unen a un proyecto nuevo o que configuran Theus en un repo existente por primera vez.
-
-## Cuándo usarlo
-
-- Primera vez que abres un proyecto con Theus
-- Te unes a un equipo o repositorio nuevo
-- El usuario pide "ayúdame a entender este código"
-- El usuario pide generar un THEUS.md para un proyecto
-- El usuario dice "hazme el onboarding" o "guíame por este repo"
-
-## Cómo funciona
-
-### Fase 0: Índice Ñaupa (motor de inteligencia de código)
-
-Antes de cualquier lectura manual, apóyate en el MCP `theus-naupa` (Ñaupa), el motor de inteligencia de código de Theus. Es la vía más rápida y precisa para obtener la estructura real del proyecto:
-
-1. **Indexa el repositorio**: llama a `index_repository` sobre la raíz del proyecto (verifica primero con `index_status` / `list_projects` si ya existe un índice; usa `detect_changes` para refrescarlo en lugar de reindexar desde cero).
-2. **Obtén la arquitectura**: llama a `get_architecture` para conseguir el mapa de módulos, capas y dependencias detectado a partir del AST real, no de suposiciones.
-3. **Explora el grafo**: usa `search_graph` para localizar los símbolos y módulos centrales (puntos de entrada, servicios, modelos), y complementa con `trace_path` para seguir flujos entre componentes, `get_code_snippet` para leer definiciones concretas y `get_database_schema` / `table_usage` si el proyecto tiene base de datos.
-
-Los resultados de Ñaupa son la columna vertebral de las fases siguientes: la lectura manual (Glob/Grep/Read) sirve para **complementar** lo que el grafo no cubre (configs, manifiestos, CI, docs), no para reemplazarlo.
-
-### Fase 1: Reconocimiento
-
-Reúne señales crudas del proyecto sin leer cada archivo. Ejecuta estas comprobaciones en paralelo:
-
-```
-1. Detección de manifiestos de paquetes
-   → package.json, go.mod, Cargo.toml, pyproject.toml, pom.xml, build.gradle,
-     Gemfile, composer.json, mix.exs, pubspec.yaml
-
-2. Huella del framework
-   → next.config.*, nuxt.config.*, angular.json, vite.config.*,
-     settings de django, app factory de flask, main de fastapi, config de rails
-
-3. Identificación de puntos de entrada
-   → main.*, index.*, app.*, server.*, cmd/, src/main/
-   (contrasta con los puntos de entrada que reportó get_architecture)
-
-4. Instantánea de la estructura de directorios
-   → Los 2 niveles superiores del árbol de directorios, ignorando node_modules,
-     vendor, .git, dist, build, __pycache__, .next
-
-5. Detección de configuración y tooling
-   → .eslintrc*, .prettierrc*, tsconfig.json, Makefile, Dockerfile,
-     docker-compose*, .github/workflows/, .env.example, configs de CI
-
-6. Detección de la estructura de tests
-   → tests/, test/, __tests__/, *_test.go, *.spec.ts, *.test.js,
-     pytest.ini, jest.config.*, vitest.config.*
-```
-
-### Fase 2: Mapeo de arquitectura
-
-A partir de los datos de Ñaupa y del reconocimiento, identifica:
-
-**Stack tecnológico**
-- Lenguaje(s) y restricciones de versión
-- Framework(s) y bibliotecas principales
-- Base(s) de datos y ORMs
-- Herramientas de build y bundlers
-- Plataforma de CI/CD
-
-**Patrón de arquitectura**
-- Monolito, monorepo, microservicios o serverless
-- Separación frontend/backend o full-stack
-- Estilo de API: REST, GraphQL, gRPC, tRPC
-
-**Directorios clave**
-Mapea los directorios de nivel superior a su propósito:
-
-<!-- Ejemplo para un proyecto React — reemplaza con los directorios detectados -->
-```
-src/components/  → Componentes de UI en React
-src/api/         → Handlers de rutas de API
-src/lib/         → Utilidades compartidas
-src/db/          → Modelos de base de datos y migraciones
-tests/           → Suites de tests
-scripts/         → Scripts de build y despliegue
-```
-
-**Flujo de datos**
-Traza una petición desde la entrada hasta la respuesta (usa `trace_path` de Ñaupa para seguir la cadena de llamadas real):
-- ¿Por dónde entra una petición? (router, handler, controller)
-- ¿Cómo se valida? (middleware, schemas, guards)
-- ¿Dónde está la lógica de negocio? (services, models, casos de uso)
-- ¿Cómo llega a la base de datos? (ORM, queries crudas, repositorios)
-
-### Fase 3: Detección de convenciones
-
-Identifica los patrones que el código ya sigue:
-
-**Convenciones de nombres**
-- Nombres de archivos: kebab-case, camelCase, PascalCase, snake_case
-- Patrones de nombres de componentes/clases
-- Nombres de archivos de test: `*.test.ts`, `*.spec.ts`, `*_test.go`
-
-**Patrones de código**
-- Estilo de manejo de errores: try/catch, tipos Result, códigos de error
-- Inyección de dependencias o imports directos
-- Enfoque de gestión de estado
-- Patrones asíncronos: callbacks, promesas, async/await, channels
-
-**Convenciones de Git**
-- Nombres de branches a partir de las branches recientes
-- Estilo de mensajes de commit a partir de los commits recientes
-- Flujo de PRs (squash, merge, rebase)
-- Si el repo aún no tiene commits o el historial es superficial (p. ej. `git clone --depth 1`), omite esta sección y anota "Historial de Git no disponible o demasiado superficial para detectar convenciones"
-
-### Fase 4: Generar los artefactos de onboarding
-
-Produce dos salidas:
-
-#### Salida 1: Guía de onboarding
-
-```markdown
-# Guía de onboarding: [Nombre del proyecto]
-
-## Resumen
-[2-3 frases: qué hace este proyecto y a quién sirve]
-
-## Stack tecnológico
-<!-- Ejemplo para un proyecto Next.js — reemplaza con el stack detectado -->
-| Capa | Tecnología | Versión |
-|------|-----------|---------|
-| Lenguaje | TypeScript | 5.x |
-| Framework | Next.js | 14.x |
-| Base de datos | PostgreSQL | 16 |
-| ORM | Prisma | 5.x |
-| Testing | Jest + Playwright | - |
-
-## Arquitectura
-[Diagrama o descripción de cómo se conectan los componentes — parte del resultado de get_architecture]
-
-## Puntos de entrada clave
-<!-- Ejemplo para un proyecto Next.js — reemplaza con las rutas detectadas -->
-- **Rutas de API**: `src/app/api/` — handlers de rutas de Next.js
-- **Páginas de UI**: `src/app/(dashboard)/` — páginas autenticadas
-- **Base de datos**: `prisma/schema.prisma` — fuente de verdad del modelo de datos
-- **Configuración**: `next.config.ts` — config de build y runtime
-
-## Mapa de directorios
-[Mapeo directorio de nivel superior → propósito]
-
-## Ciclo de vida de una petición
-[Traza una petición de API desde la entrada hasta la respuesta]
-
-## Convenciones
-- [Patrón de nombres de archivos]
-- [Enfoque de manejo de errores]
-- [Patrones de testing]
-- [Flujo de Git]
-
-## Tareas comunes
-<!-- Ejemplo para un proyecto Node.js — reemplaza con los comandos detectados -->
-- **Levantar el servidor de desarrollo**: `npm run dev`
-- **Ejecutar tests**: `npm test`
-- **Ejecutar el linter**: `npm run lint`
-- **Migraciones de base de datos**: `npx prisma migrate dev`
-- **Build de producción**: `npm run build`
-
-## Dónde mirar
-<!-- Ejemplo para un proyecto Next.js — reemplaza con las rutas detectadas -->
-| Quiero... | Mira en... |
-|-----------|-----------|
-| Agregar un endpoint de API | `src/app/api/` |
-| Agregar una página de UI | `src/app/(dashboard)/` |
-| Agregar una tabla de base de datos | `prisma/schema.prisma` |
-| Agregar un test | `tests/` siguiendo la ruta del código fuente |
-| Cambiar la config de build | `next.config.ts` |
-```
-
-#### Salida 2: THEUS.md inicial
-
-Genera o actualiza un THEUS.md específico del proyecto basándote en las convenciones detectadas. Si ya existe un `THEUS.md`, léelo primero y mejóralo — preserva las instrucciones específicas del proyecto que ya existen y señala con claridad qué se agregó o cambió.
-
-```markdown
-# Instrucciones del proyecto
-
-## Stack tecnológico
-[Resumen del stack detectado]
-
-## Estilo de código
-- [Convenciones de nombres detectadas]
-- [Patrones detectados a seguir]
-
-## Testing
-- Ejecutar tests: `[comando de test detectado]`
-- Patrón de tests: [convención de archivos de test detectada]
-- Cobertura: [si está configurada, el comando de cobertura]
-
-## Build y ejecución
-- Dev: `[comando de desarrollo detectado]`
-- Build: `[comando de build detectado]`
-- Lint: `[comando de lint detectado]`
-
-## Estructura del proyecto
-[Mapa directorio clave → propósito]
-
-## Convenciones
-- [Estilo de commits si es detectable]
-- [Flujo de PRs si es detectable]
-- [Patrones de manejo de errores]
-```
-
-## Buenas prácticas
-
-1. **Ñaupa primero, lectura después** — el grafo de conocimiento (`index_repository`, `get_architecture`, `search_graph`) da la estructura real del código; la lectura manual cubre lo que el grafo no indexa (configs, manifiestos, CI, docs).
-2. **No leas todo** — el reconocimiento debe usar el grafo de Ñaupa, Glob y Grep, no Read sobre cada archivo. Lee selectivamente solo para señales ambiguas.
-3. **Verifica, no supongas** — si un framework se detecta por la configuración pero el código real usa otra cosa, confía en el código.
-4. **Respeta el THEUS.md existente** — si ya hay uno, mejóralo en lugar de reemplazarlo. Señala qué es nuevo y qué ya existía.
-5. **Sé conciso** — la guía de onboarding debe poder escanearse en 2 minutos. Los detalles pertenecen al código, no a la guía.
-6. **Marca lo desconocido** — si una convención no se puede detectar con confianza, dilo en lugar de adivinar. "No se pudo determinar el test runner" es mejor que una respuesta equivocada.
-
-## Antipatrones a evitar
-
-- Generar un THEUS.md de más de 100 líneas — mantenlo enfocado
-- Listar cada dependencia — destaca solo las que condicionan cómo escribes código
-- Describir nombres de directorios obvios — `src/` no necesita explicación
-- Copiar el README — la guía de onboarding aporta una visión estructural que el README no tiene
-
-## Ejemplos
-
-### Ejemplo 1: Primera vez en un repo nuevo
-**Usuario**: "Hazme el onboarding de este código"
-**Acción**: Ejecutar el flujo completo (Fase 0 con Ñaupa + fases 1-4) → producir la Guía de onboarding + THEUS.md inicial
-**Salida**: Guía de onboarding impresa directamente en la conversación, más un `THEUS.md` escrito en la raíz del proyecto
-
-### Ejemplo 2: Generar THEUS.md para un proyecto existente
-**Usuario**: "Genera un THEUS.md para este proyecto"
-**Acción**: Ejecutar las fases 0-3, omitir la Guía de onboarding, producir solo el THEUS.md
-**Salida**: `THEUS.md` específico del proyecto con las convenciones detectadas
-
-### Ejemplo 3: Mejorar un THEUS.md existente
-**Usuario**: "Actualiza el THEUS.md con las convenciones actuales del proyecto"
-**Acción**: Leer el THEUS.md existente, ejecutar las fases 0-3, fusionar los hallazgos nuevos
-**Salida**: `THEUS.md` actualizado con las adiciones claramente marcadas