Deixa de usar o teu provedor de IA como un teleprompter e crea subaxentes, habilidades e comandos

Pasar da dependencia de prompts a sistemas de axentes intelixentes

A maioría da xente aínda usa a IA como se fose un teleprompter.

Escriben un prompt. Agardan. Obteñen unha resposta. Cópiana e pégana noutro sitio. Logo volven facelo. E outra vez. Cada interacción comeza de cero. Cada conversa esquece o que veu antes.

Isto non é colaboración. É ditado con pasos extra.

En 2026, se aínda estás usando o teu provedor de IA como un teleprompter, estás a perder o cambio enteiro que está acontecendo baixo os teus pés.

O problema do teleprompter

Cando usas a IA como un teleprompter, estás a tratar un sistema potencialmente autónomo como un xerador de texto dun só disparo. O patrón vese así:

1. Escribes un prompt detallado
2. Agardas pola resposta
3. Avalías manualmente a saída
4. Refinas e volves lanzar o prompt
5. Perdes todo o contexto cando pechas o chat

Este modelo ten tres fallos fatais:

Sen coñecemento persistente. Cada conversación é unha lousa en branco. Explicas o mesmo contexto unha e outra vez. A túa IA non coñece a túa codebase, as túas preferencias, as túas limitacións nin o teu historial.

Sen delegación. Ti segues a ser o pescozo de botella. Cada decisión, cada validación, cada seguinte paso require a túa intervención. A IA agarda a que lle digas que debe facer despois.

Sen especialización. Usas unha interface xenérica para todo: programación, documentación, deseño, probas, despregue. Un estilo de prompt. Unha xanela de contexto. Unha conversa facendo o traballo de moitas.

O modelo de teleprompter trata a IA como unha ferramenta. Pero as ferramentas non escalan a autonomía. Os axentes si.

Que cambia cando pensas en termos de axentes

En Claude Code, a arquitectura de axentes consta de tres primitivas:

• Subaxentes: instancias especializadas de Claude con fiestras de contexto illadas (~/.claude/agents/)
• Habilidades (Skills): módulos de coñecemento auto-detonados con ficheiros SKILL.md (~/.claude/skills/)
• Ordes (Commands): ordes de barra inclinada activadas polo usuario para accións explícitas (~/.claude/commands/)

A diferenza clave respecto ao prompting tradicional:

• As habilidades detónanse automaticamente por Claude en función do contexto
• As ordes requiren que escribas /command explicitamente
• Os subaxentes executan nun contexto separado coas súas propias ferramentas

Considera a diferenza:

Enfoque teleprompter:

«Escríbeme un componente de tarxeta con imaxe, título, texto do corpo e un botón principal seguindo os patróns do noso sistema de deseño e os estándares de accesibilidade...»

Enfoque Claude Code:

/generate card --variant=default --with-image=true --with-button=true

O primeiro é unha petición. O segundo invoca unha habilidade que xa sabe que é unha tarxeta, que require o teu sistema de deseño, que estándares de accesibilidade se aplican e como validar a súa propia saída.

A arquitectura: subaxentes, habilidades e ordes

Esta é a estrutura que substitúe o modelo de teleprompter:

Nivel 1: Subaxentes

Os subaxentes son ficheiros Markdown independentes en ~/.claude/agents/ que executan traballo en paralelo. Teñen as súas propias fiestras de contexto e poden invocar habilidades.

~/.claude/agents/
├── header-builder.md
├── footer-builder.md
└── dashboard-builder.md

Cada ficheiro de subaxente ten un frontmatter YAML:

• name: identificador claro
• description: que fai e cando invocalo
• tools: capacidades permitidas (Read, Write, Bash, Grep, Glob)

Exemplo de subaxente (header-builder.md):

---
name: header-builder
description: Build complete header components with navigation
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist...

Nivel 2: Habilidades

As habilidades son módulos de coñecemento auto-detonados. Cando lle pides algo a Claude que encaixa co propósito dunha habilidade, Claude aplícaa automaticamente.

~/.claude/skills/
├── card/
│   ├── SKILL.md
│   ├── workflows/
│   │   ├── generate.md
│   │   ├── validate.md
│   │   └── improve.md
│   ├── references/
│   │   └── schema.yml
│   └── scripts/
│       └── validate.py

Isto segue a metodoloxía Atomic Design: átomos, moléculas, organismos. Cada habilidade é experta nunha soa cousa. Cando precisas unha tarxeta, a habilidade de tarxeta detónase automaticamente.

Cada habilidade sabe:

• O esquema do compoñente (props, slots, variantes)
• As convencións do teu sistema de deseño
• Patróns específicos do framework
• Requisitos de accesibilidade WCAG
• Habilidades relacionadas ás que pode facer referencia

Nivel 3: Ordes

As ordes son atallos activados polo usuario. Escribes /command para invocalas. Viven en workflows de habilidades ou globalmente:

~/.claude/skills/card/workflows/
├── generate.md    # /generate card
├── validate.md    # /validate card
├── improve.md     # /improve card
├── document.md    # /document card
├── test.md        # /test card
└── a11y.md        # /a11y card

As ordes poden invocar subaxentes para planificación, e logo o Claude principal encárgase da execución. Isto dálle fluxos de traballo estruturados con acceso completo ás ferramentas.

Exemplo completo: habilidade de tarxeta

Vouche amosar exactamente como funciona isto cunha habilidade real:

A estrutura da habilidade

~/.claude/skills/card/
├── SKILL.md           # Core prompt and instructions
├── workflows/         # Slash commands
│   ├── generate.md
│   ├── validate.md
│   ├── improve.md
│   ├── document.md
│   ├── test.md
│   └── a11y.md
├── references/        # Documentation loaded into context
│   └── schema.yml
└── scripts/           # Executable Python/Bash scripts
    └── validate.py

O ficheiro SKILL.md

---
name: card
description: Generate and validate card components 
  for any design system with accessibility checks
---  # Card Skill  When user requests card components, this skill 
auto-triggers based on context.
 ## Schema  props:
  title: string
  body: string
  image: { src, alt, width }
  variant: default | horizontal | overlay
 slots:
  header: Custom header content
  footer: Buttons, links
 ## Related Skills  This skill can reference:
- image
- heading
- button
- link
- text

Uso de ordes con barra inclinada

Xerar unha tarxeta nova:

/generate card \   --variant="default" \   --title="Welcome" \   --with-image=true \   --with-button=true

Validar unha tarxeta existente:

/validate card \   --file="components/card.jsx"

Comprobar o cumprimento de accesibilidade:

/a11y card --level="AA"

Mellorar a UX para un contexto específico:

/improve card \   --context="e-commerce product listing" \   --focus="conversion"

Que pasa por debaixo do capó

Cando invocas /generate card, Claude:

1. Detona a habilidade de tarxeta: SKILL.md cárgase no contexto
2. Le o esquema: Valida os teus parámetros fronte ás propiedades permitidas
3. Referencia outras habilidades: as habilidades de imaxe, heading, button achegan a súa especialización
4. Executa o workflow: execútase workflows/generate.md
5. Auto-valídase: executa o workflow de validación sobre a súa propia saída
6. Devolve o resultado: Fornece o compoñente máis calquera aviso

A habilidade de tarxeta non se limita a xerar markup. Orquestra un sistema de especialistas, cada un achegando o seu coñecemento de dominio.

Por que isto importa: de constructor a pensador de sistemas

O modelo de teleprompter mantente como operador. O modelo de habilidades convérteche en arquitecto.

Cando pasei de escribir prompts a deseñar habilidades, varias cousas cambiaron:

Deixei de repetir contexto. Cada habilidade xa coñece o seu dominio. Non explico que é unha tarxeta cada vez que preciso unha.

Empecei a pensar en composición. Unha páxina non é un só prompt: é unha coordinación de organismos, que son coordinacións de moléculas, que son coordinacións de átomos. Cada capa ten a súa propia habilidade.

Deleguei a validación. En vez de revisar manualmente cada saída, a orde /validate comproba a estrutura, a orde /a11y comproba o cumprimento de WCAG, e a orde /test executa comprobacións automatizadas. Eu reviso as excepcións, non todos os resultados.

Construín coñecemento institucional. Cando melloro o SKILL.md dunha habilidade, esa mellora persiste. O sistema faise máis intelixente co tempo, non só durante unha conversa concreta.

Esta é a diferenza entre usar IA e construír con IA.

O deseño é o código

No meu traballo con sistemas de deseño, cheguei a un principio: O deseño é o código.

Cando os design tokens, os esquemas de compoñentes e as configuracións de axentes están aliñados, non hai unha capa de tradución entre o que especifican as persoas de deseño e o que constrúen as persoas de desenvolvemento. A especificación é a implementación.

Así é como os axentes fan isto real:

# The schema IS the source of truth schema:   props:     variant:       type: string
      enum: [primary, secondary, success, danger, warning, info]       default: primary
    size:       type: string
      enum: [sm, md, lg]       default: md
 tokens:   colors:     - --btn-bg
    - --btn-color
    - --btn-border-color

Este esquema non é só documentación. É a fonte de verdade. O axente xera compoñentes a partir del. O validador comproba contra el. Os design tokens fan referencia a el. Un ficheiro, moitos usos.

Cando unha deseñadora actualiza os valores dos tokens en Figma, actualízase a configuración do axente. Cando se actualiza a configuración do axente, actualízanse os compoñentes xerados. O deseño é o código porque ambos se derivan do mesmo esquema.

Como comezar a construír con Claude Code

Se estás preparado para ir máis alá do modelo de teleprompter, aquí tes un camiño práctico:

Paso 1: Identifica os teus dominios

Que áreas do teu traballo son repetitivas, baseadas en regras e dependentes do contexto? Esas son candidatas a habilidades:

• Xeración de código
• Documentación
• Probas
• Revisión e validación
• Xestión do sistema de deseño
• Despregue e DevOps

Paso 2: Crea a túa primeira habilidade

Comeza cun SKILL.md sinxelo:

---
name: my-component
description: Generate and validate my-component
---  # My Component Skill  When user asks about my-component, apply these rules...

Paso 3: Engade workflows (ordes)

Crea as seis ordes básicas en workflows/:

Cada orde é un ficheiro Markdown con instrucións.

Paso 4: Establece referencias entre habilidades

As habilidades poden facer referencia a outras habilidades:

## Related Skills  This skill uses:
- image (for card images)
- button (for CTAs)
- heading (for titles)

Mapa estas dependencias. A xerarquía debería coincidir coa estrutura natural do teu dominio.

Paso 5: Crea subaxentes para tarefas complexas

Cando precises contexto illado ou execución en paralelo, crea un ficheiro de subaxente en ~/.claude/agents/:

---
name: header-builder
description: Build complete header components with navigation, logo, and search
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist. When building headers:
1. Check existing header patterns in the codebase
2. Use the nav, button, logo skills for sub-components
3. Ensure responsive design and accessibility

Construíndo a túa biblioteca de habilidades

Estrutura as túas habilidades seguindo Atomic Design:

Cada habilidade:

• Ten a súa propia configuración SKILL.md
• Ten workflows/ con ordes de barra inclinada
• Ten references/ con documentación
• Ten scripts/ para automatización
• Sabe que outras habilidades referencia

Isto crea un sistema consistente e escalable no que Claude detona automaticamente a habilidade axeitada en función do contexto.

O futuro é axencial

Brad Frost, creador de Atomic Design, leva tempo falando deste cambio: os sistemas de deseño deben converterse en infraestrutura lexible por máquinas porque os axentes de IA xa están a ensamblar interfaces usando os mesmos compoñentes que usan os equipos humanos.

Isto non é unha predición para 2030. Está a pasar agora mesmo.

Se o teu sistema de deseño non pode ser analizado por un axente, está a converterse en legado. Se o teu fluxo de desenvolvemento require que unha persoa lance un prompt para cada paso, non escala. Se as túas interaccións de IA comezan de cero cada vez, estás a desperdiciar coñecemento acumulado.

O modelo de teleprompter estaba ben cando a IA era unha novidade. Xa non vale cando a IA é infraestrutura.

Deixa de lanzar prompts. Comeza a deseñar.

Constrúe axentes. Dalles habilidades. Deixa que se coordinen.

O futuro pertence a quen arquitecta sistemas, non a quen escribe scripts.

Construíndo sistemas de deseño axenciais para o futuro do desenvolvemento web.

Lecturas adicionais

• The Design Is the Code A miña exploración do pensamento de autómatas celulares en sistemas de deseño
• Atomic Design by Brad Frost A metodoloxía detrás das xerarquías de compoñentes
• Designing Systems That Build Themselves De constructor a pensador de sistemas