Mastering Claude

Buscar una lección

157 leccións.

  • Chat, Cowork, Claude Code, tres herramientas, tres usosElegir la puerta de entrada adecuada

    Cada entorno de Claude responde a una necesidad diferente, ninguno reemplaza a los otros dos.

  • Cowork, el modo por defecto para un perfil no técnicoElegir la puerta de entrada adecuada

    Cowork actúa directamente sobre las carpetas conectadas y se divide en pequeñas pasadas en lugar de un único tratamiento gigante.

  • Configurar el ordenador para las sesiones largasElegir la puerta de entrada adecuada

    Manten el ordenador activo antes de cualquier proceso largo, de lo contrario la sesión se detiene sin avisar.

  • Entender el token y la ventana de contextoNo quedarse nunca sin tokens

    Cada palabra leída o escrita consume un token, y reabrir una sesión antigua recarga, y por tanto vuelve a pagar, toda su ventana de contexto.

  • Qué hacer cuando se alcanza el límiteNo quedarse nunca sin tokens

    Una cuota alcanzada bloquea el envío de nuevos mensajes hasta que ocurre un evento que depende del tipo de cuenta, y la única acción fiable mientras tanto es saber de antemano a quién contactar en la organización.

  • Los buenos reflejos para ahorrarNo quedarse nunca sin tokens

    Varias sesiones cortas vinculadas a un proyecto hacen releer mucho menos material que una sola sesión prolongada de un día para otro.

  • El proyecto, contenedor del contextoMantener el hilo de un día a otro

    Un proyecto reune archivos, instrucciones y sesiones en un solo lugar que persiste de una vez a otra, una tarea tratada fuera de todo proyecto sigue siendo una sesión aislada que no conserva nada tras su cierre.

  • Activar la memoria, distinta del historialMantener el hilo de un día a otro

    La memoria retiene una selección elegida de lo que se ha dicho, el historial conserva cada conversación tal cual sin que una sesión nueva la relea por si sola.

  • Retomar una sesión sin volver a perderlo todoMantener el hilo de un día a otro

    Abrir una sesión nueva vinculada al mismo proyecto y pedirle que retome el contexto cuesta menos y va más rápido que prolongar una sesión ya muy cargada.

  • Lo que Cowork ve y lo que no veHacer que Claude trabaje en tus archivos reales

    Los archivos que Cowork lee y modifica son los de las carpetas que has conectado, pero su mirada no se detiene en los archivos: según como lo abras, también ve tu pantalla.

  • Trabajar sobre una copia, nunca sobre el originalHacer que Claude trabaje en tus archivos reales

    Un archivo abierto directamente por Claude en una carpeta conectada se modifica en su sitio, no en una copia invisible que encontrarías después.

  • Competencias y plugins, la especialización a demandaHacer que Claude trabaje en tus archivos reales

    Una competencia es una especialización cargada para responder a un dominio preciso, un plugin agrupa varias en un solo paquete instalable.

  • Los conectores, un enlace directo con un softwareHacer que Claude trabaje en tus archivos reales

    Un conector enlaza Claude con un servicio externo tras una autorización explícita, y esa autorización vale más allá de la conversación en curso, hasta en las tareas planificadas.

  • Lo que exige una prudencia particular antes de hacer tratar un documentoDatos personales, la prudencia obligatoria

    Los datos de identidad, de salud o de situación personal son categorías protegidas, y un secreto nunca debe transitar por una conversación, ni siquiera brevemente.

  • Lo que garantiza la cuenta de organización, y lo que no garantizaDatos personales, la prudencia obligatoria

    En una cuenta de organización, Anthropic no entrena sus modelos con las conversaciones, pero la organización sigue siendo la única responsable del tratamiento de los datos que hace transitar por ella.

  • Tratar un primer caso real de principio a finPasar a la práctica y orientarse solo

    Un entregable producido por Claude solo se da por bueno cuando lo has releído tú mismo, el anuncio de éxito o el aspecto pulido de un documento nunca es una prueba del fondo.

  • El glosario de referenciaPasar a la práctica y orientarse solo

    Nueve palabras aparecen sin cesar en las conversaciones sobre la herramienta: agente, token, ventana de contexto, proyecto, habilidad, plugin, conector, tarea programada, subcontratista.

  • Predecir la palabra siguiente, nada másQué es un modelo de lenguaje, sin jerga

    Un modelo de lenguaje solo hace una cosa: predecir el fragmento de texto más probable a continuación de lo que ya ha leído, y una respuesta inventada sale del mismo cálculo que una respuesta exacta, sin que ninguna señal interna las distinga la una de la otra.

  • El token y la ventana, lo que el modelo ve realmenteQué es un modelo de lenguaje, sin jerga

    El modelo ve tokens apilados en una ventana con un techo fijo, no palabras enteras tomadas una por una, y una conversación que se acerca a ese techo cambia de contenido incluso antes de alcanzar su coste máximo, ya que Claude entonces resume los intercambios más antiguos.

  • El mito del ajuste mágicoQué es un modelo de lenguaje, sin jerga

    Dos respuestas diferentes a la misma pregunta no indican una avería: vienen de un ajuste interno, la temperatura, que regula el nivel de riesgo en la elección de la palabra siguiente, y ese ajuste no corrige una petición mal planteada, la petición misma sí puede hacerlo.

  • Una familia de modelos, una elección entre velocidad y profundidadQué es un modelo de lenguaje, sin jerga

    Los modelos de una misma familia comparten el mismo entrenamiento base y solo se diferencian realmente por el equilibrio entre la velocidad de la respuesta y la profundidad del razonamiento aplicado antes de responder.

  • El sentido sin diccionario, y por qué el orden importaQué es un modelo de lenguaje, sin jerga

    Claude no abre ningún diccionario, asocia cada palabra a palabras de sentido cercano y evalúa cada una en relación con todas las demás en el momento de responder, lo que hace que el lugar de una instrucción dentro del mensaje cambie su peso real en la respuesta.

  • Cómo aprendió Claude a responder, y hasta cuándoQué es un modelo de lenguaje, sin jerga

    Claude atraviesa tres etapas de entrenamiento antes de cualquier conversación, una lectura amplia del mundo, un ajuste para convertirse en un asistente útil, y después una autocorrección basada en principios escritos, y el conocimiento que resulta de ello se detiene en una fecha que varía según el modelo utilizado.

  • Los tres bloques de una peticiónEscribir una petición que funciona

    Una petición que funciona separa tres bloques, lo que Claude debe ser, lo que ya se ha dicho, y lo que se pide ahora, y una instrucción explícita da un resultado más fiable que una instrucción vaga dejada al criterio de Claude.

  • Ser claro, directo, y dar el porquéEscribir una petición que funciona

    Claude se comporta como un empleado nuevo y brillante sin contexto implícito sobre tus hábitos, así que una petición gana en precisar el porqué y quien va a leer o escuchar la respuesta, no solo la tarea a realizar.

  • Asignar un rolEscribir una petición que funciona

    Un rol de una frase, colocado al comienzo de una conversación o de un proyecto, orienta el tono, el vocabulario y las prioridades de Claude, y una sola frase ya basta para marcar esa diferencia.

  • Separar los datos de las instruccionesEscribir una petición que funciona

    Mezclar las instrucciones y los datos en un solo bloque de texto crea confusión, mientras que una frontera nítida, etiqueta XML, título, bloque de código o línea de marcado, la elimina.

  • Formatear la salida y hablar en lugar de ClaudeEscribir una petición que funciona

    Precisar el formato exacto esperado, hasta prohibir explícitamente cualquier frase de introducción, elimina los preámbulos inútiles y las salidas mal formadas, mientras que la técnica histórica que consistía en escribir uno mismo el primerísimo carácter de la respuesta de Claude ya no está disponible en los modelos actuales.

  • Hacer que Claude razone antes de concluirEscribir una petición que funciona

    Pedirle a Claude que escriba su razonamiento antes de su conclusión mejora la precisión en las preguntas de varias etapas, tanto si ese razonamiento se invita mediante una frase en la petición como si ya está activo como un modo aparte, y ambas versiones consumen tokens adicionales.

  • Mostrar el objetivo en lugar de prohibirloEscribir una petición que funciona

    Tres a cinco ejemplos entrada hacia salida anclan un formato o un tono mejor que una larga lista de reglas, y una instrucción positiva da un objetivo claro allí donde una instrucción únicamente negativa deja a Claude adivinar por qué reemplazarla.

  • Componer una petición compleja sin inventarEscribir una petición que funciona

    Una petición compleja se compone pieza por pieza, quién debe ser Claude, el contexto, el dato a tratar, lo que se pide, un ejemplo, el formato esperado, y luego una última línea que autoriza a Claude a decir no lo sé en lugar de inventar una respuesta.

  • Hacer durar y reutilizar una petición que funcionaEscribir una petición que funciona

    Una petición que funciona se afina con pequeños toques en lugar de partir de cero, y luego se fija en una plantilla reutilizable donde solo se reemplaza la parte que cambia de una tarea a otra.

  • Un verde no prueba nada hasta que no ha sido probado el mismoVerificar lo que devuelve

    Un control que nunca ha sido puesto en jaque por un caso que debe encontrar realmente no ha probado nada, en el sentido estricto de que probar exige que un comando concreto se haya ejecutado y que su salida haya sido leída: un detector roto da cero problemas, y eso se lee exactamente como un éxito.

  • Prueba el verificador antes de creer su veredictoVerificar lo que devuelve

    Un control que da una cifra plausible no es lo mismo que un control que da una cifra correcta, y un control defectuoso rara vez falla de forma ruidosa, da un resultado que parece correcto.

  • El remedio contra la invención también puede inventarVerificar lo que devuelve

    Un dispositivo de verificación es un entregable como cualquier otro, producido por el mismo tipo de mecanismo que lo que controla: repetir ese mecanismo una segunda vez no lo hace independiente, solo un método realmente distinto lo demuestra.

  • Dónde miras determina lo que encuentrasVerificar lo que devuelve

    Una verificación centrada en el último cambio dice dónde se ha mirado, nunca dónde están realmente los defectos: sin haber examinado el resto con el mismo cuidado, ninguna conclusión sobre la peligrosidad comparada del código reciente y del código antiguo se sostiene.

  • Una verificación muy rigurosa puede aun así no ver nadaVerificar lo que devuelve

    Cuanto más disciplinado es un método de control, más da la ilusión de haberlo cubierto todo, porque solo puede juzgar lo que ya existe, nunca lo que falta por completo.

  • Probado, o simplemente aún no refutadoVerificar lo que devuelve

    Probado significa que un comando concreto se ha ejecutado y que su salida ha sido leída; aún no refutado significa solo que nada ha detectado un problema hasta ahora, una afirmación mucho más débil.

  • Un control de forma nunca ve un valor falsoVerificar lo que devuelve

    Un control automático mide la forma, la codificación, la presencia de una palabra clave, nunca la verdad, y validar una captura de pantalla o una etapa intermedia nunca prueba lo que la persona va a abrir realmente.

  • Reabrir cada fuente antes de creerlaVerificar lo que devuelve

    Un agente de búsqueda reporta lo que un índice muestra, no lo que una página en directo contiene hoy, y presenta un enlace muerto con la misma seguridad que un enlace vivo: toda fuente destinada a sostener una conclusión se reabre antes de ser citada.

  • Contar toda la población, y nombrar la medida por lo que realmente captaVerificar lo que devuelve

    Medir sobre los pocos casos advertidos por azar en lugar de sobre toda la población produce una conclusión llena de seguridad y sin embargo falsa, y esa misma conclusión sigue siendo falsa si el nombre que se le da al resultado dice algo distinto de lo que el instrumento realmente captó.

  • Encadenar los promptsTécnicas que cambian el resultado

    Dividir una tarea compleja en una cadena de prompts cortos, donde la salida de uno se convierte en la entrada del siguiente, hace que cada eslabón sea verificable por separado en lugar de juzgar un único bloque opaco.

  • Darle manos a ClaudeTécnicas que cambian el resultado

    La llamada a herramientas permite que Claude pida la ejecución de una función que tú has definido, pero el modelo nunca ejecuta nada por sí mismo: es tu aplicación, o para ciertas herramientas proporcionadas por Anthropic sus propios servidores, quien ejecuta realmente la operación, y la claridad de la descripción de la herramienta determina la exactitud de los argumentos que envía.

  • Componer un system prompt a partir de varias fuentesTécnicas que cambian el resultado

    Fusionar las mejores reglas de varios system prompts funciona como una operación de escritura ordinaria, siempre que se reescriba cada regla importada para su propio contexto en lugar de copiarla tal cual, y se deje que las reglas ya vigentes decidan cualquier conflicto.

  • Citar las fuentes y no andarse con rodeosTécnicas que cambian el resultado

    Una cita útil cabe en un corchete en línea justo después de la frase que demuestra, una fuente por corchete, sin una sección aparte al final del mensaje, y una respuesta directa plantea el hecho en lugar de anunciarlo y luego cerrarse con una pregunta de cortesía.

  • Salidas estructuradas y salvaguardasTécnicas que cambian el resultado

    Imponer un esquema exacto a una salida y verificar esa salida antes de usarla son dos mitades del mismo reflejo, una fuerza la forma en origen, la otra la controla en destino, y ambas cuentan más cuando la acción que sigue no tiene marcha atrás.

  • Verificar un prompt como se verifica un resultadoTécnicas que cambian el resultado

    Un eval es un conjunto de pruebas fijas que puntúa un prompt, y el meta-prompting usa a Claude para mejorar un prompt existente, pero en ambos casos el resultado sigue siendo un borrador que hay que probar, nunca una respuesta definitiva.

  • Hacer decir varias veces, y contradecirse uno mismoTécnicas que cambian el resultado

    Pedir varias respuestas independientes y quedarse con la mayoría filtra el ruido de una sola respuesta, y pedirle a Claude que haga de abogado del diablo contra su propia respuesta encuentra errores que un solo pase deja pasar, siempre que se haga siempre una síntesis final para separar las objeciones válidas del ruido.

  • El panorama de los modelos, una misma familia de predictoresElegir tu modelo y tu herramienta

    Claude, GPT, Gemini y los modelos de pesos abiertos son todos predictores de la palabra siguiente entrenados de forma distinta, y una plantilla de prompt escrita para uno se traslada casi sin cambios a los demás.

  • Enrutar por tarea, no por marcaElegir tu modelo y tu herramienta

    Elegir un modelo se decide según la naturaleza de la tarea, su impacto y su novedad, no según una fidelidad de marca, y un planteamiento más honesto de una solicitud suele desbloquear más que un cambio de modelo.

  • Componer un system prompt entre varios proveedoresElegir tu modelo y tu herramienta

    Cuando un prompt debe funcionar en varios proveedores, se identifica la regla más fuerte de cada uno, se fusionan sin contradicción, y las reglas escritas por el propietario del prompt prevalecen en general sobre los valores por defecto de un proveedor, salvo cuando entrarían en conflicto con los límites de seguridad que ese proveedor impone él mismo.

  • Modelo local, a medida, o simplemente un mejor promptElegir tu modelo y tu herramienta

    Un modelo de pesos abiertos que se ejecuta en local no genera ningún coste facturado por llamada y no hace salir ningún dato hacia el exterior, un modelo ajustado a medida cuesta caro construir y solo se justifica a muy gran volumen o para un formato fijo, y en la inmensa mayoría de los casos un prompt mejor escrito resuelve el problema más rápido que ambos.

  • Abrir Cowork e instalar tu primer espacio de trabajoCowork, el colega digital

    Cowork es un agente de escritorio que exige un plan de pago y, para tocar tus archivos locales, la aplicación Claude Desktop abierta y conectada; un proyecto de Cowork agrupa carpetas, instrucciones y una memoria que le son propias.

  • Lo que Cowork puede tocar, y lo que nunca debe tocarCowork, el colega digital

    El acceso de Cowork se divide en tres planos distintos, las carpetas conectadas, el uso directo de tus aplicaciones y de tu pantalla, y una red aislada que bloquea por defecto las direcciones internas; en los tres casos, una eliminación definitiva de archivo siempre exige tu confirmación.

  • Escribir un brief que Cowork pueda ejecutar, y luego leer su plan antes de que empieceCowork, el colega digital

    Un buen brief nombra un resultado, su fuente, su destino y el espacio de trabajo en cuestión, como para un colega que empieza ese mismo día; Cowork responde con un plan que hay que revisar, porque una hipótesis falsa detectada antes de la ejecución se corrige sin coste, detectada después puede exigir deshacer escrituras.

  • Elegir tu nivel de aprobación, paso a pasoCowork, el colega digital

    Cowork propone tres modos de aprobación, Manual que te hace validar cada acción, Automático que deja que Claude se revise a sí mismo antes de actuar, y Sin aprobación que ya no verifica nada: la eliminación definitiva de un archivo sigue confirmándose en los tres modos, una tarea se detiene en cualquier momento, y en una cuenta Team o Enterprise un administrador puede retirar el modo Automático del selector.

  • Reconstruir una hoja de cálculo real o un informe, no un borrador para corregirCowork, el colega digital

    Cowork entrega archivos terminados, un libro con fórmulas que recalculan de verdad, una presentación montada, un documento con formato, no solo texto plano para retomar: nombrar la estructura exacta esperada o proporcionar un modelo para copiar acerca el resultado a lo que realmente se va a usar, y una cifra que se muestra correcta en una celda nunca demuestra que la fórmula que la produjo sea correcta.

  • Conectores: lo que realmente leen y escribenCowork, el colega digital

    Las capacidades de un conector se verifican servicio por servicio: al relevamiento del 2 de septiembre de 2026, el conector Gmail de Google Workspace puede enviar, responder y reenviar mensajes directamente, con una aprobación solicitada por defecto antes de cada envío que, en un plan Team o Enterprise, un propietario de organización puede autorizar a los miembros a levantar, mientras que el conector Microsoft 365 para Outlook también puede enviar, pero solo una vez que un administrador de la cuenta haya activado esta capacidad para toda la organización.

  • Tarea planificada o Computer Use: en qué orden lo intenta CoworkCowork, el colega digital

    Cowork intenta primero un conector, luego el navegador integrado en la aplicación de escritorio, y como último recurso el control directo de la pantalla, siempre en ese orden fijo, incluso para una tarea planificada que se ejecuta sin supervisión.

  • Cowork en todas partes, quién puede hacer qué, y el rastro que dejaCowork, el colega digital

    Cowork pasó del escritorio solo a la web y al móvil el 7 de julio de 2026 y sigue en beta en estas dos superficies, con sesiones en la nube que continúan sin ningún dispositivo encendido; en una cuenta Enterprise, roles personalizados delimitan el acceso equipo por equipo, y la actividad de Cowork se encuentra en una exportación técnica, no en la transcripción del chat en sí, salvo para una sesión que se ejecuta en local en el equipo, cuyo historial permanece únicamente en esa computadora.

  • Receta: ordenar tu correo sin enviar nada por errorRecetas para el trabajo diario

    Un ataque por inyección de prompt exige dos condiciones a la vez, leer un contenido no confiable y poder actuar sobre él: para el correo, la verdadera barrera ya no es la incapacidad de enviar, depende del ajuste de aprobación vigente en tu espacio, a verificar antes de confiar solo en tu propia relectura.

  • Receta: transformar notas dispersas en un documento o una hoja de cálculo limpiaRecetas para el trabajo diario

    Cowork produce documentos estructurados y hojas de cálculo con fórmulas que funcionan a partir de notas en bruto: en un lote grande, pedir explícitamente un plan y luego cada sección por separado da un resultado más fiable que una sola gran instrucción lanzada sobre toda la carpeta.

  • Receta: construir un texto en pasos separados en lugar de una sola vezRecetas para el trabajo diario

    Un texto importante se divide en pasos nombrados, cada uno con un solo rol, un plan aprobado primero, la redacción después, un ajuste del tono como paso propio, y luego una relectura confiada a un rol de editor en lugar de una simple petición de reescritura.

  • Receta: organizar la memoria común del equipo sin duplicarlaRecetas para el trabajo diario

    Una buena memoria común se apoya en cuatro gestos, reunir, detectar los duplicados incluso cuando la formulación difiere, vincular lo que va junto, y encontrar rápido gracias a un índice ligero en lugar de rebuscar en toda la carpeta cada vez.

  • Receta: producir un mismo documento en varios idiomas sin que diverjaRecetas para el trabajo diario

    Una fuente única y bloqueada dirige todas las versiones traducidas, y un control de coherencia compara después las cifras y los términos clave entre cada idioma, para que una corrección hecha en una versión no se olvide en las demás.

  • Receta: compartir un documento en un solo archivo que se abre en cualquier lugarRecetas para el trabajo diario

    Un documento destinado a enviarse por correo o mensajería debe caber en un solo archivo sin enlace externo ni dependencia, validado al reabrirlo sin conexión antes del envío, para que se muestre igual en casa de todo el mundo sin instalación.

  • Claude Code y el bucle del agenteFundamentos y bucle del agente

    Claude Code encadena reflexión, llamada real a una herramienta y lectura del resultado en bucle hasta lograr el objetivo, no responde una sola vez como un chat.

  • CLAUDE.md, la memoria del proyectoFundamentos y bucle del agente

    CLAUDE.md se lee automáticamente al inicio de cada sesión en el repositorio donde se encuentra, y sus reglas se leen como contexto, sin garantía de aplicación estricta.

  • Los comandos slash esencialesFundamentos y bucle del agente

    Un pequeño conjunto de comandos slash pilota toda una sesión de Claude Code, memoria del proyecto, contexto de la conversación y extensiones activas, sin tocar nunca el código del repositorio.

  • Permisos y modo planFundamentos y bucle del agente

    El modo de permiso decide qué acciones ejecuta Claude Code sin preguntar nada, y desde la versión 2.1.228, en sesión interactiva de terminal o VS Code, el modo que recibe una sesión nueva en las ofertas Pro, Max y Team ya no es el modo default sino el modo auto, que actúa ampliamente bajo la vigilancia en segundo plano de un segundo modelo.

  • Interrumpir y redirigir en plena tareaFundamentos y bucle del agente

    Esc interrumpe la vuelta en curso, reflexión o llamada a herramienta, sin perder el contexto acumulado, mientras que Ctrl+C responde a una pregunta distinta y, pulsada una segunda vez cuando nada está corriendo, termina la sesión de Claude Code misma.

  • Apuntar a los archivos con @Fundamentos y bucle del agente

    El símbolo arroba abre un menú que apunta a un archivo o una carpeta real del disco, se filtra a medida que se teclea, y distingue claramente el instante en que se inserta una ruta en el mensaje del instante en que ese mensaje se envía.

  • Ejecutar comandos de shellFundamentos y bucle del agente

    La herramienta Bash ejecuta comandos reales en tu equipo, Claude lee la salida realmente producida para continuar su razonamiento, y aparece un aviso de permiso antes de cada comando nuevo.

  • Leer y aprobar un diffFundamentos y bucle del agente

    Un diff se lee línea por línea antes de aprobarse, y la aprobación en sí se hace hoy mediante un menú de opciones con nombre en lugar de una pulsación libre de letra.

  • La lista de tareas y la línea de estadoFundamentos y bucle del agente

    En los modelos más recientes, la lista de tareas permanece vacía por defecto, ya que Claude gestiona el trabajo en varias etapas sin mostrarlo, mientras que una línea de estado configurada mediante un script muestra en directo el modelo activo, la ventana de contexto y el costo de la sesión.

  • El mapa de una instalación estructuradaUna instalación estructurada

    Una instalación de Claude Code que aguanta con el tiempo se lee como un mapa de siete elementos, el motor, la constitución CLAUDE.md, la memoria de archivos, el transporte git, los hooks, las skills y el latido programado, en lugar de como un amontonamiento de ajustes sin plan.

  • Instalar, conectarse y primer lanzamientoUna instalación estructurada

    El instalador nativo de Claude Code se actualiza solo, la conexión se hace mediante una suscripción Pro, Max, Team, Enterprise o Console en lugar de una clave API olvidada en el entorno, y claude doctor entrega un diagnóstico de solo lectura antes de cualquier corrección.

  • CLAUDE.md global, una constituciónUna instalación estructurada

    El CLAUDE.md global ahora apunta a una longitud en líneas en lugar de en kilobytes, y no prevalece sobre los demás CLAUDE.md por sobrescritura: las cuatro escalas, gestionada, usuario, proyecto, local, se concatenan en el contexto de la más amplia a la más específica.

  • Conectar la memoria de archivos a gitUna instalación estructurada

    Una carpeta de memoria versionada con git, con un remote privado y una regla de fusión que conserva ambos contenidos en lugar de forzar, sigue siendo una técnica que hay que construir uno mismo, distinta de la memoria automática nativa que, por su parte, nunca sale de la máquina local.

  • Hooks y latidoUna instalación estructurada

    Los eventos del ciclo de vida disparan hooks según tres cadencias distintas, SessionStart y SessionEnd forman la pareja natural para automatizar el protocolo de memoria, y la consolidación nocturna sigue siendo una tarea programada del sistema operativo que hay que construir uno mismo, no un mecanismo de Claude Code documentado bajo ese nombre.

  • Depurar tus skills y cerrar la instalaciónUna instalación estructurada

    Una skill se instala una por una frente a una necesidad ya encontrada, nunca por lotes, y cerrar la instalación consiste en demostrar cada uno de los siete elementos del mapa del módulo mediante un gesto ejecutable en lugar de suponerlos ya implementados.

  • Skills: enseñar un workflow a ClaudeExtender: habilidades, MCP, subagentes, hooks, plugins

    Una skill encapsula un workflow reproducible en un archivo SKILL.md, invocada por un comando slash explícito o por correspondencia automática con su descripción.

  • Crear una skill que también se convierte en un comandoExtender: habilidades, MCP, subagentes, hooks, plugins

    Un comando personalizado y una skill son ahora el mismo mecanismo: un archivo .claude/commands/nombre.md y una carpeta .claude/skills/nombre/SKILL.md producen ambos el comando /nombre con el mismo comportamiento, y para una skill personal o de proyecto, es el nombre de la carpeta, no el campo name del frontmatter, el que se convierte en el nombre del comando.

  • Descubrir, depurar y apilar skillsExtender: habilidades, MCP, subagentes, hooks, plugins

    Las skills se descubren en dos bibliotecas públicas mantenidas por Anthropic, y varias skills declaradas para necesidades distintas pueden cargarse juntas en una misma tarea, pero una descripción mal elegida nunca se activa, ni sola ni apilada.

  • MCP: el protocolo de conexiónExtender: habilidades, MCP, subagentes, hooks, plugins

    MCP es el estándar abierto que conecta a Claude con herramientas y datos externos alrededor de tres primitivas: las herramientas que puede llamar, los recursos que puede leer, las invitaciones reutilizables que puede proponer.

  • Conectar un servidor MCP y qué ha cambiadoExtender: habilidades, MCP, subagentes, hooks, plugins

    Un servidor MCP se conecta por OAuth o por clave, se verifica con claude mcp list, y el propio protocolo cambió de núcleo el 28 de julio de 2026, un hecho independiente de cualquier versión de Claude Code.

  • Construir tu propio servidor MCPExtender: habilidades, MCP, subagentes, hooks, plugins

    Un servidor MCP casero se lanza como proceso hijo mediante transporte stdio, declara en inputSchema un esquema JSON que el propio servidor debe validar, y una descripción precisa decide cuándo Claude lo llama.

  • Subagentes: delegar en un contexto aisladoExtender: habilidades, MCP, subagentes, hooks, plugins

    Un subagente procesa una tarea en una ventana de contexto aislada y solo devuelve su conclusión, lo que mantiene limpia la conversación principal y permite lanzar varios en paralelo.

  • Hooks: automatizar el ciclo de vidaExtender: habilidades, MCP, subagentes, hooks, plugins

    Un hook es una acción que el arnés ejecuta él mismo ante un evento preciso del ciclo de vida, nunca una preferencia confiada al modelo esperando que la recuerde.

  • Los eventos de hook, del disparo al mensajeExtender: habilidades, MCP, subagentes, hooks, plugins

    PreToolUse puede impedir que una llamada se produzca, PostToolUse ya solo puede reaccionar después de los hechos, y la decisión de un hook pasa por campos JSON precisos, nunca por una frase escrita en la salida estándar.

  • Plugins: agrupar skills, hooks, MCP y agentesExtender: habilidades, MCP, subagentes, hooks, plugins

    Un plugin agrupa skills, hooks, servidores MCP y comandos en un solo directorio versionado, instalable y compartible de una sola vez, con un manifiesto único que vive aparte de todo lo demás.

  • settings.json en profundidadExtender: habilidades, MCP, subagentes, hooks, plugins

    Cinco niveles de settings.json se suceden del más fuerte al más débil, una clave escalar común a dos archivos se decide según el nivel más prioritario, pero la mayoría de las listas, entre ellas permissions.allow y permissions.deny, se fusionan entre niveles en lugar de sobrescribirse.

  • El enrutamiento de las skills falla en silencioExtender: habilidades, MCP, subagentes, hooks, plugins

    Claude decide invocar una skill comparando el vocabulario de la solicitud con el único campo description de esa skill, y un desajuste de idioma o de jerga entre ambos hace fallar la invocación automática sin ninguna señal visible en la respuesta.

  • Depurar y corregir un bugGestos cotidianos

    Un comando de reproducción preciso y una traza de pila completa orientan el diagnóstico hacia la causa real de un bug, y la corrección no se declara cerrada hasta que se ha ejecutado un test de regresión que reproduce el caso defectuoso y se ha leído su salida.

  • Construir y refactorizar con los tests primeroGestos cotidianos

    Claude Code examina los archivos de test ya presentes en un proyecto para escribir un nuevo test con el mismo estilo antes de la implementación, y confirmar que ese test falla realmente prueba que efectivamente está probando algo que todavía no existe.

  • Revisar código y pilotar git en lenguaje naturalGestos cotidianos

    La revisión de código local con /code-review ofrece cinco niveles de esfuerzo de low a max, y ultra no es un sexto nivel de la misma escala sino un dispositivo distinto, una revisión multiagente en la nube facturada por separado.

  • Tomar el control, documentar y migrar una base de códigoGestos cotidianos

    En un repositorio desconocido, una visión de conjunto solicitada antes de cualquier modificación orienta las preguntas siguientes, y el comando /init lee realmente el contenido del proyecto para escribir un primer CLAUDE.md en lugar de partir de una página en blanco.

  • Automatizar una tarea repetitiva y escribir un script desechableGestos cotidianos

    Automatizar un gesto repetido empieza por separar lo que permanece fijo de lo que varía cada vez, se describe por su entrada, su salida y el entorno donde debe ejecutarse, y se verifica con un ensayo en vacío antes de cualquier paso que suprima, mueva o sobrescriba algo.

  • Los gestos rápidos de la terminalGestos cotidianos

    Un puñado de gestos breves cubre lo esencial de una sesión en el día a día: retomar una sesión precisa, volver a un punto de control anterior, lanzar un comando de shell sin salir de la conversación, y pedir un razonamiento más profundo para un solo turno sin cambiar el ajuste de toda la sesión.

  • Modo headless, estilos de salida y tareas en segundo planoGestos cotidianos

    El modo headless ejecuta Claude Code sin interfaz interactiva con -p, --output-format determina si la salida sigue siendo texto o se convierte en un objeto JSON utilizable por un script, con el costo total incluido, y run_in_background deja que un comando largo continúe sin bloquear la conversación.

  • Paralelizar: worktrees, modelo y modo rápidoGestos cotidianos

    Un git worktree aísla una sesión paralela en su propia rama, y el indicador --worktree lo automatiza ahora por completo, donde antes solo existía el gesto manual git worktree add.

  • Trampas de escritura: archivos, ediciones paralelas y entregables perdidosGestos cotidianos

    Un informe de éxito escrito por un subagente no prueba nada sobre el estado real de los archivos, ya que arranca en un contexto aislado sin acceso a lo que el agente principal ya leyó o escribió, y la única prueba fiable sigue siendo un diff verificado después, no el texto del informe.

  • Bucles, contexto contaminado y reinicioCuando algo falla

    La señal de un bucle es la repetición del mismo mensaje de error, un contexto saturado se trata con una compactación específica o con un borrado completo, y reiniciar con un resumen escrito a mano de las decisiones ya tomadas vale más que insistir en una conversación degradada.

  • Deshacer y recuperar una modificaciónCuando algo falla

    Para deshacer la última acción de Claude Code en la sesión en curso, el menú de puntos de reanudación abierto por /rewind precede ahora a Git, que sigue siendo necesario para todo lo que este sistema no sigue: una modificación hecha por un comando bash, la edición de un subagente en segundo plano, o un archivo enlazado por un enlace simbólico o físico.

  • Errores de API y limite de tasaCuando algo falla

    Una llamada a la API puede fallar de varias maneras distintas: un error 400 o 404 casi siempre señala una solicitud mal formada que debe corregirse antes de cualquier nuevo intento, salvo el caso particular de un 400 devuelto por haber alcanzado un límite de gasto, mientras que un error 429 solo se resuelve esperando si lleva una cabecera Retry-After, lo cual no es el caso de un límite de gasto alcanzado.

  • Un comando bloqueadoCuando algo falla

    Un comando de shell que deja de responder se interrumpe con Ctrl+C sin cerrar la sesión, y el plazo que lo hace pasar a segundo plano ya lo fija el propio Claude, no un prefijo que se añade a mano.

  • Varias sesiones mueren juntas, sospecha de la máquinaCuando algo falla

    Cuando varias sesiones mueren en el mismo instante sin ningún rastro en sus propios registros, la causa probable es el sistema operativo que mata procesos bajo presión de memoria, y el registro del sistema resuelve la duda más rápido que una caza de errores de la aplicación.

  • La solicitud puede partir de una premisa falsaCuando algo falla

    Una solicitud puede describir el síntoma con exactitud a la vez que se equivoca sobre la causa, y ejecutar esa solicitud al pie de la letra entonces no corrige nada o agrava la situación.

  • Leer la función invocada, probar al culpableCuando algo falla

    Una corrección cuya prueba unitaria pasa en verde puede quedar anulada, en la misma vuelta de ejecución, por la función invocada justo después, y la función ya corregida solo es un culpable probado una vez que una prueba ha aislado su efecto del de las funciones siguientes.

  • Las cuatro palancas de una sesión largaContexto y coste

    Una sesión que se prolonga se apoya en solo cuatro palancas: la caché, que reutiliza un prefijo estable, la retirada de las salidas de herramientas caducadas, la compactación, que resume el historial, y la partición, que delega el trabajo voluminoso a subagentes aislados.

  • Compactar, borrar, leer solo lo necesarioContexto y coste

    El comando /compact reemplaza el historial de mensajes por un resumen y continúa la misma conversación, el comando /clear borra ese historial y empieza de cero, y en ambos casos los archivos del proyecto en disco no se mueven: el gesto que más ahorra sigue siendo hacer que Claude lea solo el tramo pertinente de un archivo.

  • Caché de prompt y Batch API, dos descuentos que conocerContexto y coste

    La caché de prompt factura la lectura de un prefijo idéntico a aproximadamente el diez por ciento del precio de entrada normal, con una duración de vida que depende de la oferta, una hora para la conversación principal de una suscripción de pago utilizada dentro de su plan, cinco minutos para una clave de API o un subagente; la Batch API, por su parte, procesa un lote de solicitudes de forma diferida con un descuento del cincuenta por ciento, sobre una cuota de tasa separada.

  • El umbral de autocompactado no hace lo que se creeContexto y coste

    El umbral de autocompactado activa un resumen de la conversación cuando el contexto lo alcanza, no es un muro que cierre la ventana: un valor configurado por encima de la ventana real del modelo activo queda limitado a esa ventana, un comportamiento documentado cuya ausencia de aviso en pantalla queda por verificar uno mismo.

  • Una ventana de contexto no sigue al modeloContexto y coste

    Una ventana ampliada no parece trasladarse automáticamente de un modelo a otro, un punto que la documentación no zanja explícitamente: el sufijo de tamaño hay que volver a escribirlo por precaución en cada cambio de modelo mediante el comando /model, salvo para dos modelos nombrados cuyo comportamiento difiere del caso general.

  • De dónde viene realmente la factura, y por qué un recuento mienteContexto y coste

    El coste real de una sesión rara vez se esconde donde se le busca: un recuento de tokens confunde a menudo una relectura a tarifa de caché con una primera lectura a tarifa completa, un puñado de sesiones maratón carga con la mayor parte de la factura porque todo el historial se relee en cada llamada de herramienta, y todo archivo cargado automáticamente al inicio se vuelve a pagar entero en cada compactación, no solo una vez al principio.

  • Cuota, límite de tasa y enrutamiento hacia el modelo más baratoContexto y coste

    Dos límites distintos gobiernan una sesión, el coste en dinero y el límite de tasa en tokens por minuto, y ambos se tratan con el mismo reflejo: enrutar las tareas repetitivas hacia Haiku o Sonnet, reservar Opus para el razonamiento difícil, y esperar respetando un plazo creciente tras un error 429 en lugar de reintentar de inmediato.

  • Memoria en archivos: estructura y disciplinas básicasEl segundo cerebro

    La memoria de Claude Code vive en una carpeta de archivos markdown, un hecho por archivo clasificado mediante un campo type con cuatro valores, y una nota que lleva una sola idea vinculada al menos a otra sigue siendo localizable en unos segundos en lugar de mediante una relectura completa.

  • Obsidian: wikilinks, mapas de contenido y tipos de memoriaEl segundo cerebro

    El enlace entre dobles corchetes teje una red en lugar de una pila de carpetas, el mapa de contenido que los reúne es una práctica comunitaria y no una función del software, y una nota de tipo user de la memoria automática de Claude Code permanece guardada en su proyecto por defecto, salvo ajuste explícito: las memorias realmente comunes a todos los proyectos son el archivo de instrucciones personal, las reglas de nivel de usuario y la política gestionada por la organización.

  • Interrogar un grafo en lugar de releerlo todoEl segundo cerebro

    Un grafo de conocimiento construido una vez responde a una pregunta recorriendo enlaces explícitos, lo que cuesta bastante menos tokens que una relectura completa de los archivos fuente, una diferencia ilustrada por un ejemplo público que lleva su propia reserva, y el mismo principio se aplica a un transcript antiguo de sesión, interrogado por niveles antes de reabrirlo entero.

  • Dream y aprendizaje continuo: la consolidación nocturnaEl segundo cerebro

    Una consolidación nocturna de memoria es una automatización personal construida sobre una tarea programada, no una función nativa de Claude: digiere las notas en cuatro fases, orientación, recopilación, consolidación por fusión y archivado, verificación, y solo una tarea que se ejecute en el equipo o en una sesión abierta puede leer una carpeta de notas almacenada localmente.

  • Una cifra perecedera en un archivo siempre cargadoEl segundo cerebro

    Un hecho medido y caducado citado como actual es peor que la ausencia de cifra, porque conserva el aire de autoridad mientras elimina el reflejo de verificación: la prueba se resume en una pregunta, ¿se avisaría a alguien de un cambio que ocurriera mañana?, y si la respuesta es no, la cifra no tiene nada que hacer en un archivo que se carga en cada conversación.

  • Una bóveda compartida no tiene edición concurrenteEl segundo cerebro

    Una aplicación de notas basada en archivos locales no bloquea nada en una unidad de red compartida: un testimonio público documenta una carpeta de configuración que se sobrescribe entre usuarios en este tipo de montaje, y ese mismo mecanismo hace plausible, sin que la fuente lo documente ella misma, la pérdida silenciosa de una edición de nota.

  • El diario del asistente habla sobre todo del asistenteEl segundo cerebro

    Una revisión de un gran corpus de memoria mantenido por un agente muestra que la mayoría de las entradas documentan los errores del propio agente, escritas por él, sobre él, con casi ninguna instrucción explícita de la persona a la que se cree estar perfilando: es como juzgar a un piloto por el diario de mantenimiento del avión.

  • Fan-out, pipeline, barrera: elegir la arquitectura, o renunciar a ellaVarios agentes y verificación adversa

    El fan-out lanza agentes independientes en paralelo detrás de una barrera común, el pipeline hace atravesar cada elemento sin barrera y sigue siendo el valor por defecto de las tareas de varias etapas, una barrera solo se justifica si una etapa necesita de verdad el resultado completo de la anterior, y a veces la mejor decisión es no usar ningún agente cuando una sola llamada ya basta.

  • Aislar y ejecutar en segundo plano: worktrees y bucle en secoVarios agentes y verificación adversa

    Un worktree de git por agente evita que los archivos de varios agentes paralelos entren en colisión, un bucle en seco repite hasta que un ciclo ya no devuelve nada nuevo apoyándose en un conjunto ya visto, y desde el 13 de agosto de 2026 un agente que no es compañero de equipo lanzado en una sesión interactiva se ejecuta por defecto en segundo plano con notificación al final en lugar de bloquear la sesión.

  • Sostener un fan-out a gran escalaVarios agentes y verificación adversa

    Un entregable voluminoso confiado a un solo agente se ve cortado por un límite de tamaño sin que se escriba nada: fraccionar por eje, hacer que cada agente escriba en su propio archivo, respetar el tope documentado de dieciséis agentes activos a la vez y de mil agentes en total en una misma ejecución, una sola llamada que acepta hasta 4096 elementos que el runtime ordena por sí mismo bajo ese tope, y luego verificar comparando los archivos esperados con lo que existe realmente en el disco en lugar de creer a los agentes bajo palabra.

  • Workflows deterministas: esquemas, checkpoints, reanudaciónVarios agentes y verificación adversa

    Un workflow es un script que orquesta subagentes de forma determinista, con una salida estructurada mediante un esquema JSON y un checkpoint después de cada etapa, pero el modelo que se aplica a un agente relanzado sigue un orden de prioridad de cuatro niveles, y sin que los tres primeros estén rellenados, ese agente hereda como último recurso el modelo de la sesión que lo ejecuta, no de la que escribió el script.

  • Verificación adversarial, paneles de jueces y crítica de completitudVarios agentes y verificación adversa

    Tres roles de verificación sirven ángulos distintos y no se sustituyen entre sí: el subagente verificador solo recibe el artefacto a juzgar, los criterios de éxito y las herramientas para verificar, nunca el diagnóstico ni el historial de quien lo construyó, y su silencio solo es legítimo si de verdad buscó sin encontrar nada, ya que el sesgo por defecto ante una duda se inclina hacia el rechazo; un panel que compara varias soluciones puntuadas es una práctica extendida del sector, no un patrón que Anthropic nombre; y una crítica de completitud, patrón documentado bajo este nombre, busca exclusivamente lo que falta respecto al pliego de condiciones, nunca los errores de lo ya entregado.

  • Multiplicar los agentes puede multiplicar el errorVarios agentes y verificación adversa

    Un estudio que pone a prueba cinco arquitecturas de agentes en 260 configuraciones mide una tasa de error amplificada hasta unas diecisiete veces la de un agente solo cuando agentes independientes trabajan sin un coordinador que valide sus salidas, frente a unas cuatro veces cuando un coordinador las valida, y en una tarea estrictamente secuencial, las cuatro arquitecturas multiagente probadas retroceden todas frente a un agente solo.

  • Una premisa no verificada en un prompt vuelve como conclusiónVarios agentes y verificación adversa

    El texto de encuadre que un orquestador escribe en el prompt de cada agente permanece invisible para la revisión adversa, que recibe el artefacto producido y unos criterios de éxito, nunca la intención ni el historial de quien construyó la tarea: una afirmación falsa deslizada en ese encuadre atraviesa entonces toda la cadena sin ser puesta a prueba, y un fan-out que envía el mismo encuadre a varios agentes multiplica esta exposición en vez de diluirla.

  • Tres estados de fallo, y aceptar un riesgo correctamenteVarios agentes y verificación adversa

    Una automatización que procesa una cola debería distinguir éxito, fallo recuperable que se reintentará, y fallo definitivo abandonado, y solo el tercero debe llegar a una persona, si no cada fallo recuperable apaga el valor de la alerta el día en que tiene razón; aceptar un riesgo con un control compensatorio difiere de ignorarlo, una instantánea tomada antes de la ejecución permite clasificar el resultado en tres vías, variación normal silenciosa, cambio importante que solo alerta, pérdida catastrófica que restaura automáticamente.

  • Secretos: nunca hacerlos transitar, nunca mostrarlos en claroSeguridad y datos

    Un secreto pegado en una conversación, aunque sea brevemente, permanece después presente en los registros y en cualquier relectura automática del historial, y un comando de configuración lanzado por un motivo preciso puede mostrar un secreto vecino en claro si su filtro es demasiado amplio.

  • Un secreto en un commit está quemado: rotación inmediata, nunca la fechaSeguridad y datos

    Un secreto seguido por un repositorio se trata como comprometido en el instante en que se escribe, no cuando alguien demuestra que ha sido leído, y el remedio que alcanza cada copia es hacer rotar el identificador, la reescritura del historial llega en segundo lugar y no siempre es necesaria.

  • Seudónimo y anónimo, dos cosas diferentesSeguridad y datos

    Un número de referencia en lugar de un nombre sigue siendo un dato personal en cuanto existe en alguna parte una tabla de correspondencia, lo que puede convertir al destinatario en un encargado del tratamiento según su papel real más que en una simple anonimización, y una identidad seudónima en un repositorio necesita su propia configuración local.

  • Auditar una skill antes de instalarlaSeguridad y datos

    Un estudio fechado encontró una falla de seguridad en más de un tercio de una amplia muestra de skills de terceros, de las cuales la gran mayoría de los casos confirmados como maliciosos pasaba por una instrucción oculta, y dos vulnerabilidades reales dejaron que un repositorio malicioso se ejecutara antes de la menor confirmación, lo que solo deja la cuarentena, la lectura íntegra y el escaneo sistemático como protocolo fiable.

  • Lo que un agente puede filtrar sin que se lo pidasSeguridad y datos

    Una inyección de prompt indirecta esconde una instrucción en un contenido que el agente lee en vez de en lo que tú escribiste, un archivo generado no tiene un autor que se responsabilice de su contenido, y una regla de configuración que apunta a una ruta de archivo se acepta sin error a la vez que no bloquea nada para la herramienta que ejecuta comandos directos, mientras que una regla que apunta al nombre de esa herramienta sí bloquea de verdad.

  • Automatizacion responsable: reversible primero, fallo señalado, correctivo solicitadoSeguridad y datos

    Una acción irreversible espera un punto de control humano antes de ejecutarse, pero ese control solo es automático en el modo de permiso Manual, el más prudente de los seis modos documentados: en las ofertas de pago una sesión arranca sin embargo en modo automático por defecto, y varios de esos modos aprueban de antemano los comandos de archivos dentro de la carpeta de trabajo, incluida la eliminación, lo que traslada la responsabilidad del punto de control a quien diseña la automatización.

  • Lo que sale de la máquina, lo que se archiva, lo que nunca se comparteSeguridad y datos

    Una petición envía por la red el texto del prompt y las respuestas del modelo, cifrados en tránsito, y la copia local de ese intercambio permanece luego legible en claro en el disco durante una duración fijada por defecto; eliminar un archivo no deja ningún camino de vuelta mientras que archivarlo lo mantiene disponible y reversible; y un documento interno rico en detalles se vuelve peligroso en cuanto sale hacia el exterior, por la misma razón que lo hace útil internamente, lo que exige un inventario en bruto y luego una relectura adversarial antes de cualquier envío.

  • La petición, una única puerta de entradaLa API de Claude para quienes construyen

    Toda interacción con Claude pasa por un único punto de entrada HTTP, la petición POST /v1/messages, que recibe un array de turnos y siempre devuelve la misma estructura de respuesta.

  • Roles que se sostienen, no un prerrellenado que rompeLa API de Claude para quienes construyen

    El prerrellenado del turno assistant, una práctica que empezaba la respuesta de Claude en lugar del modelo, ahora es rechazado con un error 400 en los modelos actuales; una instrucción system estable o una salida forzada lo sustituyen.

  • Las herramientas, Claude propone, el código disponeLa API de Claude para quienes construyen

    Una herramienta se declara mediante un esquema llamado input_schema; Claude nunca la ejecuta él mismo, devuelve una solicitud de uso que el código ejecuta antes de devolver el resultado para que la conversación continúe.

  • Recibir la respuesta en streamingLa API de Claude para quienes construyen

    El modo de streaming mantiene una única conexión HTTP abierta y entrega el texto por fragmentos a medida que se genera, y el recuento acumulado de tokens se lee en el último evento message_delta recibido, nunca en el evento final message_stop.

  • Dos palancas de coste, la memoria en caché y el procesamiento por lotesLa API de Claude para quienes construyen

    Un prefijo de petición marcado como reutilizable cuesta una fracción reducida del precio normal cuando se relee desde la caché, y un conjunto de peticiones no urgentes tratado por lotes cuesta menos que un tratamiento inmediato, dos reducciones que se acumulan entre sí y con los demás modificadores de precio.

  • Contar antes de enviar, la ventana de contextoLa API de Claude para quienes construyen

    Un punto de conteo dedicado devuelve el número de tokens de una petición antes de enviarla, y la ventana de contexto con la que comparar esa cifra ya no es un valor común a toda una gama de modelos, ahora varía fuertemente de una familia a otra.

  • Elegir un modelo, cambiarlo, encajar un rechazoLa API de Claude para quienes construyen

    La elección de un modelo es un compromiso entre calidad, velocidad y coste que se revisa en cada nueva generación, y un rechazo devuelto por un clasificador de seguridad se trata como un caso normal del protocolo, no como una averia.

  • Pipeline de contenido, del brief al entregable compartibleCasos reales de principio a fin

    Un pipeline de contenido fiable separa seis roles con una sola tarea cada uno, del brief validado al archivo HTML único verificable sin conexión, y mezclar dos de estos roles en la misma pasada hace perder el control.

  • Construir un activo de datos, conjunto sintético o base de conocimientoCasos reales de principio a fin

    Un conjunto de datos sintético y una base de conocimiento comparten la misma arquitectura de cuatro operaciones, un esquema común, un identificador de correspondencia, una deduplicación y una validación antes de cualquier uso posterior.

  • La búsqueda en abanico, con verificación contradictoriaCasos reales de principio a fin

    Lanzar varias búsquedas en paralelo en lugar de en secuencia acelera la investigación, pero una afirmación solo se cita después de haber resistido un intento real de refutarla.

  • Verificar antes de creer, cuatro trampas realesCasos reales de principio a fin

    Un informe redactado por el agente de un tercero, una skill de pago vendida como un lote de funcionalidades, un conector de datos anunciado como sincronizado y una página de la competencia que muestra una funcionalidad ausente comparten el mismo fallo: cada uno sustituye una medición directa por una afirmación que habría que verificar antes de citarla.

  • Una aplicación móvil de principio a finCasos reales de principio a fin

    Un scaffold, la estructura inicial generada automáticamente para una aplicación, una navegación entre pantallas, una llamada de red y una corrección de los tipos señalados como error pueden encadenarse en una sola sesión de trabajo, con una vista previa que se actualiza en tu propio teléfono con cada modificación.

  • Automatizar la propia práctica, pila y skillCasos reales de principio a fin

    Una llamada scriptable sin interfaz, unos disparadores de ciclo de vida y una memoria destilada forman una pila que sigue trabajando sola, y un gesto repetido una tercera vez merece convertirse en un comando con nombre.

  • Hacer tu sitio legible por las IA, citación y navegación agénticaCasos reales de principio a fin

    Ser citado por un asistente conversacional y ser utilizable por un agente que navega son dos exigencias distintas, una se juega fuera del sitio sobre las menciones fiables, la otra se juega en la propia página.

  • Calentamiento, montar un prompt y marcar tu checklistTaller, proyecto final y examen

    Reconstruir de memoria un prompt completo y marcar tu propia checklist de practicante antes de cualquier proyecto revela los automatismos que aún faltan, allí donde una relectura de un ejemplo solo pondría a prueba la lectura.

  • Situarte, de principiante a experto, antes de elegir tu proyectoTaller, proyecto final y examen

    Cuatro niveles de autonomía, un Project con instrucciones, una sesión de Claude Code encuadrada por un archivo de configuración, una skill propia, una carpeta de memoria enlazada y consolidada, indican cuál de los tres proyectos de fin de recorrido corresponde a tu propio nivel.

  • El capstone, tres proyectos reales a elegirTaller, proyecto final y examen

    Entregar una pequeña funcionalidad real, construir tu propio segundo cerebro enlazado por archivos, o montar un pipeline de contenido desde el brief hasta la publicación son tres proyectos con la misma exigencia, uno solo basta para validar el recorrido.

  • Capstone avanzado, la revisión contradictoria multiagenteTaller, proyecto final y examen

    Un orquestador que distribuye roles estrechos a varios revisores en paralelo, una etapa que bloquea las salidas incompletas, y luego una síntesis que hace aflorar los conflictos en lugar de suavizarlos, producen una revisión más fiable que un revisor único.

  • La checklist de graduación, el examen finalTaller, proyecto final y examen

    Una autoevaluación escrita revela lagunas que una simple relectura no muestra, y la elección del modelo, al igual que los bucles agénticos con puntos de control, marcan la frontera entre practicante y principiante.