Parte 1: Los 7 Puntos de Extensión de Claude — El Modelo Mental

Necesitas que Claude ejecute tests antes de cada commit. ¿Dónde pones esa regla?

Opción A: Agregar "Siempre ejecutar tests antes de commitear" a tu CLAUDE.md. Opción B: Crear un skill llamado /pre-commit que ejecute la suite de tests. Opción C: Escribir un hook que se active en el evento PreCommit y realmente ejecute npm test. Opción D: Construir un MCP server que... no, eso no tiene sentido aquí. ¿Cierto?

Si has pasado más de cinco minutos tratando de entender dónde van las cosas en el sistema de extensiones de Claude, no estás solo. Entre CLAUDE.md, Skills, Hooks, MCP Servers, Connectors, Claude Apps y Plugins, hay siete mecanismos diferentes para extender el comportamiento de Claude. Algunos suenan similares. Algunos tienen capacidades que se superponen. Y la documentación, aunque exhaustiva, no siempre deja claro cuándo usar cuál.

Aquí está la respuesta a la pregunta del test, por cierto: Opción C. Un Hook. Porque ejecutar tests antes de un commit no es una sugerencia — es un requisito. Y esa distinción entre "debería" y "debe" es la clave para entender todo el stack de extensiones.

Esta es la Parte 1 de una serie de cuatro partes sobre el ecosistema de extensiones de Claude. Construiremos el modelo mental aquí, y luego profundizaremos en cada mecanismo en la Parte 2 (CLAUDE.md, Hooks, Skills), Parte 3 (MCP Servers, Connectors, Claude Apps) y Parte 4 (componiendo un stack de producción real).

Los 7 puntos de extensión de un vistazo

Siete mecanismos, siete trabajos diferentes. Tres moldean cómo piensa Claude (CLAUDE.md, Skills, Hooks). Tres expanden a qué puede acceder Claude (MCP Servers, Connectors, Claude Apps). Uno los agrupa (Plugins). Aquí está el panorama completo.

Siete mecanismos. Parece mucho. Pero aquí está el tema: no son siete enfoques que compiten por el mismo problema. Están organizados en dos ejes claros, y una vez que ves esos ejes, todo el sistema encaja.

¿Por qué importa si una regla es determinista o probabilística?

Porque esa única distinción resuelve el 80% de la confusión sobre dónde deben ir las cosas. Determinista significa que siempre sucede, sin excepciones. Probabilístico significa que Claude usa su criterio sobre cuándo y cómo aplicarla. Si no interiorizas nada más de este artículo, interioriza esto.

Determinista significa que el mecanismo se ejecuta sin importar lo que Claude decida. No importa si Claude está confundido, distraído por un prompt complejo, o en medio de un flujo de trabajo de 50 pasos. El mecanismo se activa. Cada vez.

Probabilístico significa que Claude lee la instrucción y usa su criterio sobre cómo aplicarla. La mayoría de las veces la sigue. Pero la longitud del contexto, instrucciones en competencia, situaciones ambiguas y la pura complejidad pueden hacer que omita o aplique mal una regla.

Así es como se dividen los siete puntos de extensión:

Esto es lo que significa en la práctica:

Los Hooks son deterministas. Cuando configuras un hook PreCommit, se ejecuta antes de cada commit. Claude no decide si ejecutarlo. El sistema ejecuta el script de shell, verifica el código de salida y bloquea el commit si falla. Claude podría estar en medio de escribir un soneto — el hook igual se activa.

Los MCP Servers son deterministas en ejecución. Una vez que Claude decide llamar una herramienta MCP, el servidor la ejecuta de forma determinista. La herramienta se ejecuta, devuelve un resultado, y ese resultado entra al contexto de Claude. No hay un "ah, me saltaré la llamada API esta vez." Sin embargo, si Claude decide llamar la herramienta es probabilístico — depende del criterio de Claude sobre si la herramienta es relevante.

CLAUDE.md es probabilístico. Claude lee las reglas de tu proyecto y genuinamente intenta seguirlas. Pero CLAUDE.md compite con todo lo demás en la ventana de contexto: el prompt del usuario, historial de conversación, resultados de herramientas y el system prompt. Con ~150-200 instrucciones siendo el techo práctico para un cumplimiento confiable, un CLAUDE.md de 500 líneas significa que las reglas cerca del final reciben menos atención que las reglas al inicio.

Los Skills son probabilísticos con un atajo opt-in. Cuando Claude carga un skill, sigue el procedimiento. Pero Claude decide cuándo cargar un skill basado en lo que parece relevante. Puedes forzarlo con /nombre-del-skill, que es por qué existen los comandos slash — evitan el criterio de Claude y dicen "carga esto, ahora."

Esto no es un defecto. Es un diseño. Quieres que Claude use criterio sobre cuándo aplicar una convención de código o qué flujo de trabajo seguir. No quieres que Claude use criterio sobre si ejecutar tus verificaciones de seguridad.

¿Cuál es la diferencia entre extensiones de "cerebro" y "sistema nervioso"?

Tres puntos de extensión moldean cómo piensa Claude (su conocimiento, procedimientos y barreras de protección). Otros tres expanden a qué puede acceder Claude (bases de datos, APIs, herramientas SaaS). Los Plugins abarcan ambos. Saber en qué mitad cae tu problema reduce siete opciones a tres.

El Cerebro Interno (CLAUDE.md + Skills + Hooks) controla el comportamiento de Claude dentro de tu proyecto:

• CLAUDE.md es conocimiento fundacional: "Este es un monorepo NestJS. Usamos pnpm. Nunca usamos doc.save() — siempre findByIdAndUpdate()." Es la wiki del proyecto que Claude interioriza.
• Skills son conocimiento procedimental: "Al hacer deploy a staging, primero ejecuta la suite de tests, luego construye la imagen Docker, luego sube a Fly.io, luego verifica el endpoint de health." Son runbooks que Claude puede ejecutar paso a paso.
• Hooks son barreras de protección del comportamiento: "Antes de cualquier commit, ejecuta lint. Después de cualquier edición de archivo, verifica secretos. Antes de cualquier comando destructivo, requiere confirmación." Son las redes de seguridad que atrapan errores sin importar lo que Claude esté pensando.

El Sistema Nervioso Externo (MCP Servers + Connectors + Claude Apps) extiende el alcance de Claude al mundo exterior:

• MCP Servers son conexiones personalizadas que tú construyes: un servidor que consulta tu base de datos de producción, una integración con tu pipeline de deploy interno, un puente a la API propietaria de tu empresa.
• Connectors son conexiones llave en mano que Anthropic mantiene: Jira, Notion, Salesforce, GitHub, Slack — más de 200 integraciones con autenticación administrada.
• Claude Apps son Connectors con una capa visual: cuando un connector de Figma devuelve un diseño, Claude Apps lo renderiza como una vista previa interactiva dentro de la conversación en lugar de mostrar JSON.

El atajo mental: si tu pregunta es "¿Cómo debería comportarse Claude?" la respuesta está en el Cerebro (CLAUDE.md, Skills, Hooks). Si tu pregunta es "¿A qué debería acceder Claude?" la respuesta está en el Sistema Nervioso (MCP, Connectors, Apps).

La mayoría de las configuraciones del mundo real necesitan ambas mitades trabajando juntas. Un skill de deploy (Cerebro) llama a tu MCP server de CI/CD (Sistema Nervioso). Un hook de code review (Cerebro) verifica contra una herramienta MCP de linting (Sistema Nervioso). El Cerebro conoce los procedimientos y reglas; el Sistema Nervioso proporciona las herramientas y datos.

¿Qué punto de extensión deberías usar?

Haz tres preguntas en orden: ¿Nunca debe ser violado? (Hook.) ¿Enseña un procedimiento de múltiples pasos? (Skill.) ¿Necesita datos externos? (MCP o Connector.) Todo lo demás es CLAUDE.md. Aquí está el árbol de decisión completo.

Algunos ejemplos reales:

"Nunca hacer commit sin ejecutar tests" — ¿Nunca debe ser violado? Sí. Hook. Configura un hook PreCommit que ejecute tu suite de tests. Si los tests fallan (salida distinta de cero), el commit se bloquea. Claude no tiene voto.

"Cuando digo /deploy, ejecutar el pipeline de deploy a staging" — ¿Procedimiento de múltiples pasos? Sí. Skill. Escribe un skill en markdown que describa cada paso: ejecutar tests, construir imagen, hacer deploy a Fly.io, verificar health, publicar en Slack. Claude sigue los pasos en orden.

"Usamos NestJS con MongoDB, nunca usar doc.save()" — ¿Establece convenciones del proyecto? Sí. CLAUDE.md. Este es contexto fundacional que Claude debería conocer siempre. Influye en cada decisión de generación de código sin necesitar un disparador específico. (Si te interesa el desafío más amplio de gestionar instrucciones a nivel de prompt para agentes de IA, ese artículo cubre las técnicas que aplican aquí también.)

"Buscar datos de clientes en nuestra base de datos Postgres" — ¿Necesita acceso a datos externos? Sí. ¿Sistema personalizado? Sí. MCP Server. Construye un servidor que exponga una herramienta query_customer, y Claude puede llamarla cuando sea relevante. (Nuestra guía sobre construir tu propio sistema de herramientas para agentes recorre este patrón de principio a fin.)

"Traer los últimos tickets de Jira de mi sprint" — ¿Necesita datos externos? Sí. ¿Herramienta SaaS común? Sí. Connector. Jira tiene un connector administrado en Claude.ai. Configuración con un clic, Anthropic maneja la autenticación.

"Mostrarme el diseño de Figma para este componente y dejarme anotarlo" — ¿UI interactiva? Sí. Claude App. La integración de Figma renderiza diseños como vistas previas interactivas, no solo payloads JSON.

"Compartir nuestro flujo de deploy del equipo con otros equipos" — ¿Distribuir una combinación de skills, hooks y configs MCP? Plugin. Empaquétalo para que otros equipos puedan instalarlo con un solo comando.

¿Cómo se ve cada punto de extensión en la práctica?

Cada mecanismo corresponde a un archivo o configuración específica que puedes ver, editar y versionar. Aquí está la estructura de los siete — suficiente para orientarte antes de profundizar en las Partes 2 y 3.

CLAUDE.md

El archivo de instrucciones a nivel raíz de tu proyecto. Claude lo lee al inicio de cada conversación:

# CLAUDE.md
 
## Project: acme-platform
- Tech stack: NestJS + MongoDB + pnpm workspaces
- Port: 3100
- All workflows go through Makefile targets
 
## Hard Rules
- NEVER use doc.save() — always findByIdAndUpdate()
- NEVER push to main — always create a PR
- All API responses wrap in { success, data }
 
## Architecture
- services/ contains microservices
- packages/ contains shared libraries
- apps/ contains frontend applications

Mantenlo enfocado. El techo de ~150 instrucciones es real. Todo en CLAUDE.md compite por el mismo presupuesto de atención — el mismo desafío que enfrentan los equipos con la gestión de prompts a escala.

Skills

Archivos markdown en .claude/commands/ que Claude puede invocar:

.claude/
  commands/
    deploy.md          # /deploy — staging deployment procedure
    review.md          # /review — code review workflow
    test.md            # /test — run tests with coverage

Un archivo de skill se ve así:

# Deploy to Staging
 
Run the following steps in order:
 
1. Run the full test suite: `make test-all`
2. If tests fail, stop and report failures
3. Build the Docker image: `make docker-build`
4. Deploy to staging: `make deploy-staging`
5. Wait 30 seconds, then check health: `make health-check-staging`
6. Post results to #deploys channel

Cada skill consume 30-50 tokens al cargarse. Son ligeros por diseño — puedes tener docenas sin afectar el rendimiento. Claude los carga bajo demanda, que es la diferencia crítica con CLAUDE.md (siempre cargado).

Hooks

Scripts de shell que se activan en eventos específicos del ciclo de vida:

{
  "hooks": {
    "PreCommit": [
      {
        "command": "npm test",
        "description": "Run tests before commit",
        "blocking": true
      }
    ],
    "PreToolCall": [
      {
        "command": ".claude/hooks/check-file-permissions.sh",
        "description": "Block edits to protected files",
        "blocking": true
      }
    ],
    "PostToolCall": [
      {
        "command": ".claude/hooks/log-tool-usage.sh",
        "description": "Audit trail for tool calls",
        "blocking": false
      }
    ]
  }
}

El script del hook recibe contexto del evento vía stdin y variables de entorno. Un código de salida distinto de cero bloquea la acción (si blocking: true). Este es el único mecanismo que te da cumplimiento programático — no una sugerencia amable, sino un freno absoluto.

MCP Servers

Una configuración que apunta a Claude hacia tu servidor de herramientas personalizado:

{
  "mcpServers": {
    "acme-db": {
      "command": "node",
      "args": ["./mcp-servers/database/index.js"],
      "env": {
        "DATABASE_URL": "postgresql://..."
      }
    },
    "deploy-tools": {
      "url": "https://mcp.internal.acme.com/deploy",
      "headers": {
        "Authorization": "Bearer ${DEPLOY_TOKEN}"
      }
    }
  }
}

El MCP server expone herramientas que Claude descubre en tiempo de ejecución a través del Model Context Protocol. Los servidores locales se conectan vía stdio, los servidores remotos se conectan por Streamable HTTP. Si has construido un MCP server antes (tenemos un tutorial completo en esta serie), esta configuración es todo lo que se necesita para conectarlo a Claude.

Connectors y Claude Apps

Los Connectors se configuran a través de la interfaz de Claude.ai — no se requiere código. Te autentificas una vez, y Claude puede acceder al servicio:

Jira, Notion, Salesforce, GitHub, Slack, Linear, Asana — más de 200 integraciones disponibles. Los Connectors usan el protocolo MCP internamente, pero Anthropic administra el servidor, la autenticación y las actualizaciones.

Claude Apps extienden los connectors con UI interactiva. Cuando un connector de Figma devuelve un diseño, Claude Apps lo renderiza como algo que puedes ver, anotar e interactuar dentro de la ventana de conversación. Fueron lanzadas en enero de 2026 como la extensión MCP Apps del protocolo.

Plugins

Los Plugins agrupan múltiples tipos de extensión en un paquete compartible e instalable:

my-team-plugin/
  skills/
    deploy.md
    review.md
  hooks/
    pre-commit.sh
  mcp/
    config.json
  manifest.json

Piensa en los plugins como paquetes npm para la configuración de Claude. En lugar de decirle a cada nuevo desarrollador que "copie estos cinco archivos en su directorio .claude/", publicas un plugin que pueden instalar con un solo comando. El manifiesto del plugin declara qué skills, hooks y configuraciones MCP proporciona.

¿Cuáles son los errores de configuración más comunes?

Cada error a continuación proviene de malinterpretar la línea determinista/probabilístico. El mayor infractor: poner reglas de seguridad en CLAUDE.md en lugar de Hooks. Una vez que interiorizas el modelo mental anterior, estos se vuelven obvios — pero casi todos caen en al menos uno.

Error 1: reglas de seguridad en CLAUDE.md

El problema: Agregas "NUNCA hacer push a main" o "SIEMPRE ejecutar tests antes del commit" a CLAUDE.md. Claude lo sigue el 90% de las veces. El otro 10% — usualmente durante una operación compleja de múltiples pasos cuando el contexto está lleno — hace push directamente a main.

Por qué sucede: CLAUDE.md es probabilístico. Claude genuinamente intenta seguir cada instrucción, pero la atención es finita. Reglas críticas de seguridad enterradas entre 200 otras instrucciones no obtienen 100% de cumplimiento.

La solución: Mueve las reglas de seguridad estrictas a Hooks. Un hook PreCommit que verifica el nombre de la rama y rechaza commits a main se activa cada vez. Un hook PreToolCall que bloquea git push cuando el destino es main es absoluto. Usa CLAUDE.md para convenciones, Hooks para cumplimiento.

Error 2: construir MCP Servers para procedimientos internos

El problema: Alguien construye un MCP server con una herramienta run_deployment porque quiere que Claude siga un procedimiento de deploy. El servidor se convierte en un wrapper alrededor de scripts de shell que Claude podría ejecutar directamente.

Por qué sucede: Los MCP servers son emocionantes, y "darle una herramienta a Claude" se siente como la abstracción correcta. Pero si la herramienta es solo "ejecutar estos comandos de shell en orden", has agregado un salto de red, un servidor para mantener y una capa de protocolo sin beneficio.

La solución: Usa un Skill. Un skill de deploy que guía a Claude a través de make test && make build && make deploy es más simple, más barato y más fácil de mantener. Reserva los MCP servers para acceso a sistemas externos — bases de datos, APIs, servicios de terceros — donde necesitas que Claude alcance fuera de su propia máquina.

Error 3: sobrecargar CLAUDE.md

El problema: CLAUDE.md crece a más de 500 líneas. Incluye estándares de código, decisiones arquitectónicas, procedimientos de deploy, documentación de API, convenciones del equipo y una sección sobre cómo hacer café. Claude empieza a descartar silenciosamente reglas del final del archivo.

Por qué sucede: CLAUDE.md es el primer mecanismo de extensión que descubren los desarrolladores. Es fácil de editar. Todo se siente importante. Así que todo termina ahí.

La solución: CLAUDE.md es para contexto fundacional del proyecto — lo que Claude necesita en cada conversación. Mueve el conocimiento procedimental a Skills (carga bajo demanda, 30-50 tokens cada uno). Mueve las reglas de cumplimiento a Hooks. Mueve la documentación de referencia a archivos que Claude pueda leer cuando los necesite. Un CLAUDE.md enfocado de 50-100 líneas es más efectivo que una enciclopedia de 500 líneas.

Error 4: Connectors donde van MCP Servers (y viceversa)

El problema: Un equipo intenta usar un Connector para su API interna personalizada, o construye un MCP server completo para integrarse con Jira.

Por qué sucede: El límite entre MCP y Connector no es inmediatamente obvio. Ambos conectan a Claude con servicios externos. Ambos usan el protocolo MCP.

La solución: Heurística simple: si Anthropic ya mantiene un connector para el servicio (Jira, GitHub, Slack, Notion, etc.), usa el Connector. Tiene autenticación administrada, actualizaciones automáticas y cero mantenimiento. Si es tu propio sistema interno, base de datos o API propietaria, construye un MCP server. El esfuerzo de construir un servidor se justifica por la personalización que necesitas.

Error 5: omitir los Hooks por completo

El problema: Un equipo usa solo CLAUDE.md y Skills. No tienen Hooks. Claude ocasionalmente edita archivos que no debería, hace commits sin ejecutar tests o ejecuta comandos peligrosos sin confirmación.

Por qué sucede: Los Hooks requieren escribir scripts de shell y entender el ciclo de vida de eventos. Es el mecanismo menos descubrible. Muchos desarrolladores no se enteran de que los Hooks existen hasta que los muerde una falla de regla probabilística.

La solución: Empieza con tres hooks que cubren los riesgos más comunes: un hook PreCommit que ejecuta lint y tests, un hook PreToolCall que bloquea escrituras a archivos protegidos (configuraciones de producción, archivos de migración, código vendorizado) y un hook PostToolCall que registra ediciones de archivos para auditoría. Puedes agregar más a medida que descubras nuevos modos de falla, pero estos tres atrapan la mayoría de los problemas.

¿Cómo se componen estas extensiones?

No eliges un solo mecanismo — los apilas en capas. CLAUDE.md es la base, los Skills agregan procedimientos, los Hooks agregan barreras de protección, MCP agrega alcance externo y los Connectors conectan SaaS. Cada capa maneja lo que hace mejor. Empieza pequeño y agrega capas conforme tu proyecto crece.

Capa 1: CLAUDE.md (Base)

Empieza aquí. Todo proyecto necesita contexto fundacional: stack tecnológico, estructura del proyecto, convenciones de código, decisiones arquitectónicas clave. Esta es la configuración mínima viable de Claude. No cuesta nada mantenerla y le da a Claude el contexto que necesita para ser útil desde la primera conversación.

Capa 2: Skills (Procedimientos)

Una vez que Claude conoce tu proyecto, enséñale tus flujos de trabajo. Procedimientos de deploy, checklists de PR review, patrones de testing, pasos de migración de datos. Los Skills son baratos (30-50 tokens cada uno, cargados bajo demanda) y poderosos — convierten a Claude de un asistente de código en un compañero de flujo de trabajo.

Capa 3: Hooks (Barreras de protección)

Después de que hayas atrapado a Claude cometiendo un error que nunca quieres que se repita — hacer push a main, editar una config de producción, commitear sin tests — agrega un Hook. Los Hooks son reactivos: los agregas cuando descubres un modo de falla. Empieza con los tres grandes (testing pre-commit, protección de archivos, bloqueo de comandos peligrosos) y crece a partir de ahí.

Capa 4: MCP Servers (Alcance externo)

Cuando Claude necesita acceder a sistemas fuera de tu base de código — bases de datos, APIs, dashboards de monitoreo, pipelines de deploy — construye un MCP server. Cada servidor es un punto de integración enfocado. En Chanl, nuestros agentes se conectan a bases de datos de clientes, bases de conocimiento y APIs externas a través de MCP — el mismo protocolo que usa Claude Code.

Capa 5: Connectors y Apps (Ecosistema SaaS)

Para herramientas SaaS estándar, conecta un Connector en lugar de construir desde cero. Cuando necesitas interacción visual (herramientas de diseño, dashboards, editores de documentos), Claude Apps cierran la brecha entre datos y UI.

Lo bueno de este sistema de capas es que no necesitas configurar todo el primer día. Empieza con CLAUDE.md. Agrega skills mientras documentas flujos de trabajo. Agrega hooks cuando algo sale mal. Agrega MCP servers cuando necesites datos externos. El sistema crece orgánicamente con tus necesidades. (Si estás construyendo sistemas multi-agente, cada agente puede tener su propio stack de extensiones — agentes orquestadores con diferentes archivos CLAUDE.md, hooks y conexiones MCP que los agentes especialistas que coordinan.)

Un Directorio .claude/ Real

Así es como se ve una configuración de producción de Claude Code. Esto no es teórico — es una versión simplificada de lo que usamos en Chanl para nuestro backend de plataforma:

.claude/
  CLAUDE.md                    # Project conventions (~80 lines)
  settings.json                # Hook configurations
 
  commands/                    # Skills (slash commands)
    deploy.md                  # /deploy — staging/prod pipeline
    review.md                  # /review — PR review workflow
    plan.md                    # /plan — TDD session planning
    commit.md                  # /commit — review + commit + push
    test.md                    # /test — run use case tests
 
  rules/                       # Scoped rules (load based on file globs)
    backend-services.md        # Loads when editing services/**/*.ts
    frontend-apps.md           # Loads when editing apps/**/*.tsx
    sdk-cli.md                 # Loads when editing packages/sdk/**
    api-contracts.md           # Loads when editing *.controller.ts
    deploy-infra.md            # Loads when editing Dockerfile, fly.toml
 
  hooks/
    pre-commit.sh              # Runs lint + tests
    check-permissions.sh       # Blocks edits to protected files
    log-edits.sh               # Audit trail for file changes
 
.mcp.json                      # MCP server configurations

Nota las reglas con alcance en .claude/rules/. Estas son una funcionalidad de CLAUDE.md que aborda el problema de "demasiadas instrucciones". En lugar de meter 400 líneas de reglas en el CLAUDE.md raíz, las divides en archivos por tema con frontmatter globs:. Las reglas de backend solo se cargan cuando estás editando archivos de backend. Las reglas de frontend solo se cargan cuando estás editando componentes. Esto mantiene manejable el conteo de instrucciones de cada conversación mientras le da a Claude contexto profundo para cualquier área en la que estés trabajando.

Qué viene en las partes 2, 3 y 4

Este artículo te dio el modelo mental. Los siguientes tres profundizan en cada mecanismo con código real, configuraciones reales y patrones de producción.

Parte 2: CLAUDE.md, Hooks y Skills — El Cerebro Interno de Claude cubre los tres mecanismos que moldean el comportamiento de Claude. Aprenderás cómo estructurar CLAUDE.md para máxima retención, escribir hooks que capturen modos de falla reales y construir skills que codifiquen flujos de trabajo complejos. Veremos reglas con alcance, tipos de eventos de hooks y la diferencia entre configuración a nivel de equipo y de proyecto.

Parte 3: MCP Servers, Connectors y Claude Apps — El Sistema Nervioso Externo se sumerge en integraciones externas. Construiremos un MCP server desde cero, recorreremos la configuración de Connectors y exploraremos Claude Apps con UI interactiva. Si has leído nuestro tutorial de MCP, la Parte 3 continúa donde terminó — enfocándose en cómo MCP encaja en el ecosistema más amplio de extensiones en lugar del protocolo en sí.

Parte 4: Componiendo un Stack de Producción es la recompensa. Recorreremos una configuración del mundo real — un equipo construyendo agentes de IA para producción — y mostraremos cómo CLAUDE.md, Skills, Hooks, MCP Servers y Plugins se componen en un sistema que maneja todo desde la generación de código hasta el deploy y el monitoreo. Aquí es donde el modelo mental de la Parte 1 se encuentra con la ingeniería real.

El ecosistema de extensiones está creciendo rápido. MCP se movió a la Linux Foundation. Los Connectors superaron las 200 integraciones. Claude Apps se lanzaron en enero de 2026. Los Plugins están haciendo las configuraciones compartibles entre equipos. La base que construyas ahora — entender qué mecanismo maneja qué trabajo — dará frutos a medida que lleguen nuevas capacidades.

Empieza con CLAUDE.md. Agrega skills para tu primer flujo de trabajo. Agrega un hook la primera vez que algo salga mal. Construye a partir de ahí. La estrategia de capas significa que nunca estás atrapado — siempre estás agregando capacidad sobre una base sólida.

Aprende IA Agéntica

Una lección por semana: técnicas prácticas para construir, probar y lanzar agentes IA. Desde ingeniería de prompts hasta monitoreo en producción. Aprende haciendo.

Subscribe

500+ ingenieros suscritos