Habilidad de Constructor de Prompts con el Método Karpathy

--- name: kp-prompting description: Construye prompts avanzados, especificaciones de tareas, criterios de verificación y configuración de Claude Code usando el método de spec / verifier / environment de Andrej Karpathy. Usa esta habilidad siempre que necesites especificar una tarea o proyecto, ajustar o reescribir un prompt, definir criterios de verificación o éxito para la salida de un agente, o configurar/actualizar una base de conocimiento, habilidad o salvaguardas para un agente. --- Spec - qué se quiere realmente, con la precisión suficiente para que el modelo no esté adivinando Verifier - cómo sabrás tú (o el modelo) que la salida es realmente correcta Environment - el contexto persistente y las salvaguardas para que el agente no tenga que reaprender todo desde cero en cada sesión El hilo que conecta los tres: puedes delegar la ejecución, pero no la comprensión. Cada capa de abajo debe mantener a Tom en el circuito de las decisiones de criterio reales, no solo producir una salida pulida que tape vacíos sobre los que nunca se le preguntó. Dos modos - determina en cuál estás antes de hacer cualquier otra cosa Modo de coaching (predeterminado). Tom te entrega una tarea, un prompt aproximado o una solicitud para escribir instrucciones sobre algo específico. Ajústalo usando el lente de tres capas de abajo y devuelve una versión mejorada en el chat - sin archivos. Este es el predeterminado para "ayúdame a escribir/mejorar un prompt para X". Modo de configuración completa. Tom está montando un nuevo proyecto, herramienta o flujo de trabajo recurrente y quiere el andamiaje real: un documento de spec, criterios de verificación y configuración del entorno (adiciones a CLAUDE.md, salvaguardas, referencias de base de conocimiento). Actívalo con frases como "especifica", "configura el entorno para", "desarrolla el método Karpathy para X", o una solicitud explícita de las tres capas. Si no está claro cuál aplica, haz UNA pregunta rápida en lugar de adivinar - construir la equivocada pierde más tiempo que preguntar. La mayoría de las veces es inferible: una tarea única o un borrador de prompt en mano → coaching; un proyecto o función nuevo sin prompt aún → configuración completa. Capa 1: Spec Por qué importa El ejemplo de Karpathy: pídele a un modelo de frontera si conducir o caminar hasta un lavado de autos a 50 metros, y dice caminar - pasando por alto el hecho obvio de que el auto también necesita llegar allí. Los modelos son excelentes en todo lo comprobable y sorprendentemente malos en decisiones de criterio del mundo real, porque las decisiones de criterio son exactamente lo que falta en la señal de entrenamiento limpia. El trabajo de un spec es entregarle al modelo el criterio que no puede inferir por sí mismo, para que no se reduzca a adivinar el contexto. El prompting superficial de alto nivel estilo "modo plan" no hace esto - es demasiado delgado para llevar comprensión real. Cómo construir uno Encuentra el objetivo real, no solo la tarea. "Escribe el informe de fin de mes" es una tarea. El objetivo es la decisión que ese informe debe respaldar. Si no es obvio por lo que dijo Tom, pregunta - un par de preguntas rápidas aquí ahorran una reescritura mucho mayor después. Trabaja en puntos de control pequeños, no en un gran volcado. Entregar todo y solo reunirse en un resultado terminado deja que la deriva se acumule en silencio. Divide el spec en piezas lo suficientemente pequeñas para verificar en cada paso, especialmente donde haya ambigüedad real. Sé preciso sobre lo que no debe asumirse. Cada palabra vaga en un spec se convierte en una suposición que el modelo rellena - con confianza, en la dirección estadísticamente probable, no necesariamente lo que Tom realmente quiere. Nombra las decisiones de criterio específicas (convenciones de nomenclatura, casos límite, qué pasa con datos conflictivos) en lugar de dejarlas implícitas. Una línea como "señala cualquier suposición que estés haciendo en lugar de elegir una en silencio" hace trabajo real aquí. Qué debe contener un spec Objetivo (la decisión/resultado al que sirve, no solo la tarea), límites de alcance (explícitamente dentro vs. fuera), las decisiones de criterio a señalar en lugar de resolver en silencio, y restricciones divididas en no negociables vs. preferencias. Capa 2: Verifier Por qué importa El marco de Karpathy: estos modelos están más cerca de "fantasmas" que de animales - simuladores estadísticos, no agentes motivados. Gritarle a un modelo, suplicarle o decirle que algo importa mucho no cambia la calidad de la salida. Lo que cambia la calidad de la salida es si hay algo que pueda verificar realmente el trabajo. También es por eso que los modelos son sobrehumanos en código y matemáticas (comprobables limpiamente) y poco fiables en gusto y criterio (nada contra qué verificar) - así que cuanto más explícito y comprobable sea "bien hecho" para una tarea dada, más se puede confiar en la salida en lugar de hojearla con fatiga de revisión. Cómo construir uno Establece criterios de aprobado/fallo por adelantado, en el propio prompt, no después del hecho. "Haz que el informe se vea bien" no es comprobable. "El informe tiene tres secciones y cada una termina con una recomendación" lo es. Escribe criterios como algo que un segundo lector - humano o modelo - pueda verificar sin leer la mente de Tom. Usa un segundo modelo como crítico donde sea barato hacerlo. Un modelo diferente (o el mismo modelo en un contexto nuevo) calificando la salida del primer modelo contra el spec atrapa cosas que la ejecución original racionalizará. Incorpora señal externa real cuando exista. Para código: ¿realmente se despliega, pasan las pruebas? Para trabajo no técnico: ¿coincide con el formato/tono de ejemplos ya conocidos como buenos? Un verificador que solo comprueba consistencia interna es más débil que uno que comprueba contra algo real. Qué debe contener un verifier Los criterios específicos y comprobables de aprobado/fallo (no vibraciones), quién o qué hace la verificación (autoverificación, segundo modelo, señal de despliegue/prueba), y qué pasa en un fallo (reintentar con qué retroalimentación específica, o escalar a Tom). Capa 3: Environment Por qué importa La mayoría de la gente reconstruye el contexto desde cero en cada sesión - reexplicando el proyecto, reafirmando las reglas, esperando que el agente recuerde lo que no debe tocar. Mantener el historial del chat no es lo mismo que un entorno real. Un taller con las herramientas ya en su lugar supera a reexplicar todo el taller en cada visita. Cómo construir uno Un CLAUDE.md que el agente lea automáticamente. Cubre: qué es este espacio de trabajo/repo, qué habilidades personalizadas existen y cuándo usarlas, dónde encontrar las cosas (la arquitectura de conocimiento), y las reglas que siempre aplican. Esta es la pieza de mayor apalancamiento ya que se lee en cada prompt sin que Tom se repita. Una base de conocimiento personal. Un lugar estructurado y recuperable para material de referencia que el agente pueda extraer en lugar de rederivar o alucinar. El material acumulado es un foso; una estructura de recuperación bien organizada sobre él se compone cada vez que se usa. Habilidades reutilizables para cualquier cosa repetida. Si Tom está haciendo algo por segunda vez, debería convertirse en una habilidad en lugar de una excepción reexplicada. Salvaguardas aplicadas a nivel de herramienta, no solo a nivel de prompt. Una instrucción solo de prompt como "no toques las plantillas orientadas al cliente sin preguntar" es una sugerencia que el modelo puede anular bajo presión. La misma regla como una restricción real de herramienta (ruta bloqueada, puerta de permisos) no puede. Clasifica las reglas en tres niveles: Siempre hacer - seguro en piloto automático, no hay necesidad de preguntar Preguntar primero - necesita una verificación rápida antes de proceder Nunca hacer - bloqueado de forma dura, no solo desaconsejado Qué debe contener una configuración de entorno Adiciones propuestas a CLAUDE.md (o un CLAUDE.md completo si no existe), una lista corta de qué pertenece a la base de conocimiento vs. qué está bien dejar fuera, cualquier habilidad nueva que valga la pena extraer, y los niveles de salvaguarda completados para el proyecto específico. Formatos de salida Salida del modo de coaching Devuelve el prompt/instrucciones mejorados directamente en el chat, en un bloque de código delimitado que sea fácil de copiar. Debajo, una nota breve con viñetas (máximo 3-5 líneas) sobre qué cambió y de qué capa proviene - suficiente para mostrar que la mejora no fue cosmética, no una conferencia. No crees archivos para este modo a menos que se pida. Salida del modo de configuración completa Crea tres documentos ligeros con create_file: SPEC.md - objetivo, alcance, decisiones de criterio, restricciones VERIFIER.md - criterios de aprobado/fallo, quién verifica, qué pasa en fallo Una sección de entorno - ya sea un CLAUDE.md nuevo o una adición claramente marcada al existente de Tom, más los niveles de salvaguarda Lee references/templates.md para las plantillas completas y un ejemplo trabajado antes de escribir estos - no improvises la estructura desde cero cada vez. Presenta los tres juntos con un resumen corto de qué hay en cada uno, y señala explícitamente cualquier lugar donde se haya tomado una decisión de criterio que Tom deba verificar en lugar de decidir por él en silencio. El punto central No dejes que nada de lo anterior se convierta en trabajo ocupado que produzca documentos impresionantes mientras la comprensión real de Tom del proyecto sigue siendo delgada. El objetivo de las tres capas es que Tom siga siendo quien sabe por qué importa el proyecto y cómo se ve "bueno" - las capas solo hacen que ese conocimiento sea legible para que un agente actúe de manera fiable. Si un spec, verificador o documento de entorno está llenando espacio en lugar de capturar un criterio real que Tom realmente haría, córtalo. Plantillas para el modo de configuración completa Solo se necesitan cuando kp-prompting se ejecuta en modo de configuración completa (ver SKILL.md). Complétalas según el proyecto real - no dejes corchetes de marcador de posición en los documentos entregados. Plantilla de SPEC.md markdown# Spec: [Nombre del Proyecto/Tarea] ## Objetivo [La decisión o resultado real al que sirve - no solo la descripción de la tarea. Ej.: no "añadir day-parting a la lógica de pujas" sino "reducir el gasto desperdiciado durante horas históricamente de baja conversión sin también reducir volumen durante horas que convierten pero solo se ven lentas a primera vista".] ## Alcance **Dentro del alcance:** - [...] **Fuera del alcance (por ahora):** - [...] ## Decisiones de criterio a señalar, no resolver en silencio - [Punto ambiguo específico - ej.: "qué pasa en una campaña con menos de 2 semanas de datos: aplicar benchmarks de categoría inmediatamente, o esperar datos específicos de la campaña?"] - [...] ## Restricciones **No negociables:** - [...] **Preferencias (pueden intercambiarse):** - [...] ## Puntos de control [Si el alcance es grande: 2-4 puntos donde Tom revise antes de continuar, en lugar de una gran entrega al final] 1. [...] 2. [...] Plantilla de VERIFIER.md markdown# Verifier: [Nombre del Proyecto/Tarea] ## Criterios de aprobado/fallo [Específicos y comprobables - no "se ve bien" o "reduce las horas malas". Ej.: "una hora solo se marca para puja reducida si tiene al menos N leads de historial y un CPA más de X% por encima del promedio de la cuenta".] - [ ] [criterio 1] - [ ] [criterio 2] ## Quién verifica - [ ] Autoverificación del agente contra los criterios anteriores - [ ] Pasada de crítico con segundo modelo (modelo diferente o contexto nuevo, calificando contra el spec) - [ ] Señal externa: [éxito de despliegue / suite de pruebas / coincide con un ejemplo histórico conocido como bueno] ## En caso de fallo [Qué pasa si un criterio falla - reintentar con qué retroalimentación específica, o detenerse y señalar a Tom antes de proceder] Plantilla de adición a Environment / CLAUDE.md markdown## [Nombre del Proyecto/Función] **Qué es esto:** [una o dos oraciones] **Dónde viven las cosas:** [rutas de archivo, fuentes de datos, documentos relacionados] **Habilidades relevantes aquí:** [habilidades existentes a usar, o "candidato para una nueva habilidad: X"] **Reglas:** - Siempre hacer: [...] - Preguntar primero: [...] - Nunca hacer: [...] Ejemplo trabajado Tarea: Tom pide "especificar la adición de reglas automatizadas de day-parting a la habilidad de optimización de campañas". Extracto de SPEC.md: Objetivo: no "añadir una función de day-parting" - el objetivo real es reducir el gasto desperdiciado durante horas históricamente de baja conversión sin también reducir volumen durante horas que convierten pero solo se ven lentas en una mirada rápida. Decisión de criterio señalada: qué pasa en una campaña nueva con menos de 2 semanas de datos. El spec establece explícitamente si el day-parting aplica inmediatamente usando benchmarks de categoría o espera suficiente historial específico de la campaña, en lugar de dejar que el agente elija una en silencio. Punto de control: la lógica de reglas se revisa contra una cuenta real (ya conocida) antes de conectarse para aplicar automáticamente a campañas en vivo. Extracto de VERIFIER.md: Criterio: "una hora solo se marca para puja reducida si tiene al menos 15 leads de historial y un CPA más de 25% por encima del promedio de la cuenta" - comprobable, no "reduce las horas malas". Verificación: el crítico con segundo modelo revisa la regla propuesta contra 2-3 cuentas conocidas por falsos positivos (horas que se ven mal solo por volumen pero están bien en CPA) antes de sugerirse para un cliente en vivo. Extracto de adición a CLAUDE.md: Siempre hacer: extraer y resumir datos de rendimiento por hora, marcar horas que cruzan el umbral Preguntar primero: aplicar una nueva regla de day-parting a una campaña de cliente en vivo por primera vez Nunca hacer: cambiar multiplicadores de puja en una cuenta de cliente sin que pasen los criterios del verificador y la aprobación de Tom primero Nota lo que este ejemplo está haciendo: no está inflando el documento con relleno genérico ("asegurar alta calidad," "seguir mejores prácticas"). Cada línea es una decisión específica que de otro modo se tomaría en silencio y mal. Ese es el trabajo real de las tres capas juntas.