Cambiar tema

¿Cansado de escribir prompts a mano? Esta función de Claude Code triplicó mi eficiencia

Easton editorial illustration: task-routing switchboard

Una historia real

En octubre pasado tenía que refactorizar un proyecto React: una god class de más de 2.000 líneas que daba dolor de cabeza. Cada vez que pedía a Claude Code que optimizara el código, repetía las mismas instrucciones:

  • «Recuerda usar el modo estricto de TypeScript»
  • «Las llamadas API deben incluir manejo de errores»
  • «Los componentes deben seguir el principio de responsabilidad única»

Copiar y pegar esos requisitos llevaba al menos dos o tres minutos. Peor aún: tras una docena de intercambios, Claude Code a menudo «olvidaba» mis exigencias iniciales y volvía a escribir código que no cumplía las normas.

Hasta que encontré la función Skill en la documentación.

Tras una semana de prueba, empaqueté todas esas instrucciones repetitivas en varios archivos skill. Ahora basta con @skill react-refactor. Esa clase de 2.000 líneas, que estimaba en tres días de refactor, quedó lista en dos tardes.

×3
Ganancia de eficiencia
Frente a prompts manuales
20+
Mi biblioteca de Skills
Seis meses de acumulación
30 s
Tiempo ahorrado
En cada invocación
Source: Datos de uso real

Qué es un Skill, en pocas palabras

En resumen, un Skill equipa a Claude Code con un paquete de competencias.

Creas un archivo Markdown en .claude/skills/ y escribes tus prompts habituales, flujos de trabajo y convenciones de código. Cuando lo necesites, @skill nombre-del-skill lo invoca. Como equipar habilidades a un personaje de juego: skill de ataque para producir, skill defensivo para asegurar.

Un ejemplo mínimo:


---

title: "Experto en revisión de código React"
description: "Revisión de React centrada en calidad, rendimiento y buenas prácticas"

---

# Proceso de revisión React
Eres un experto en revisión de código React con amplia experiencia. Revisa según estos criterios:

## Puntos clave
1. **Diseño de componentes**
   - Principio de responsabilidad única
   - Completitud de los tipos Props
   - Pertinencia del desglose de componentes
2. **Rendimiento**
   - Re-renders innecesarios
   - Uso de useMemo/useCallback
   - Claves en listas
3. **Calidad de código**
   - Seguridad de tipos TypeScript
   - Error boundaries
   - Accesibilidad (a11y)

## Formato de salida
- Lista de problemas (por gravedad)
- Sugerencias de código concretas
- Prioridades P0/P1/P2

Guárdalo como .claude/skills/react-review.md; para revisar React, @skill react-review basta. Claude Code seguirá tus criterios al pie de la letra.

Por qué los prompts manuales ya no aguantan

Yo también fui «ingeniero de prompts»: decenas de plantillas cuidadas en Notion. Tras unos meses, aparecieron los límites:

Demasiada repetición

Copiar y pegar desde Notion, a veces ajustar palabras según el proyecto. Media hora al día solo en eso.

Versiones ingobernables

El prompt de hoy no es el de la semana pasada; ¿recuperar «la versión que funcionaba»? Imposible.

Colaboración prehistórica

Un compañero quiere tu mejor prompt: WeChat. Lo mejora: resincronización manual. Eficiencia de la Edad de Piedra.

La IA olvida

En conversaciones largas, Claude Code olvida tus exigencias iniciales. En la ronda 20, vuelven los mismos errores.

Los Skills lo resuelven de un golpe:

  • Versionado: Git, retroceso fácil
  • Compartible: un pull en el repositorio del equipo
  • Siempre activo: no caduca por conversaciones largas

"El valor central de los Skills es la reutilización y la coherencia. La ingeniería de prompts se convierte en un activo del proyecto mantenible y compartible."

Mi primer Skill: generador de API

En un proyecto e-commerce, el backend me envió documentación Swagger con más de 100 endpoints. Para cada uno, a mano había que escribir:

  1. Definiciones de tipos TypeScript
  2. Funciones axios
  3. Lógica de manejo de errores
  4. Gestión del estado loading

Estimación: unas 30 horas para 100 endpoints.

Invertí una hora en el skill api-generator:


---

title: "Generador de código API"
description: "Genera tipos TS y encapsulación axios desde la documentación API"
version: "1.3.0"

---

# Experto en generación de API
Eres un ingeniero full stack experto en integración front/back. Genera TypeScript de calidad a partir de la documentación API.

## Contenido generado
### 1. Tipos TypeScript
```typescript
// Parámetros de solicitud
interface GetUserRequest {
  userId: string;
  includeDetails?: boolean;
}
// Datos de respuesta
interface GetUserResponse {
  id: string;
  name: string;
  email: string;
  createdAt: string;
}

2. Funciones Axios

import request from '@/utils/request';
export const getUserAPI = async (
  params: GetUserRequest
): Promise<GetUserResponse> => {
  try {
    const response = await request.get<GetUserResponse>('/api/user', { params });
    return response.data;
  } catch (error) {
    console.error('Error al obtener información del usuario:', error);
    throw error;
  }
};

3. Hook React (opcional)

export const useGetUser = (userId: string) => {
  const [data, setData] = useState<GetUserResponse | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<Error | null>(null);
  useEffect(() => {
    const fetchData = async () => {
      setLoading(true);
      try {
        const result = await getUserAPI({ userId });
        setData(result);
      } catch (err) {
        setError(err as Error);
      } finally {
        setLoading(false);
      }
    };
    fetchData();
  }, [userId]);
  return { data, loading, error };
};

Convenciones de código

  • camelCase para nombres
  • Funciones API con sufijo API
  • Hooks con prefijo use
  • Manejo de errores en toda función async
  • JSDoc en tipos y exportaciones

Formato de salida

  1. Tipos primero
  2. Luego funciones API
  3. Hook si el endpoint es frecuente
  4. Ejemplo de uso al final

Un endpoint pasó de 30 minutos a 5. Los 100 endpoints en dos días. Los juniors generan con el mismo estándar: estilo muy uniforme en todo el proyecto.

## Uso avanzado: hacer cooperar los Skills

Un solo skill no siempre basta. El refactor suele seguir una cadena:

```bash
# Paso 1: analizar problemas
@skill code-analyzer src/legacy/UserService.ts
# Paso 2: plan de refactor
@skill refactor-planner
# Paso 3: tests antes del refactor
@skill test-generator
# Paso 4: ejecutar refactor
(manual o asistido por Claude Code)
# Paso 5: revisión final
@skill code-reviewer

Incluso scripté el flujo:

#!/bin/bash
# refactor-workflow.sh
echo "🔍 Paso 1/4: analizando problemas..."
claude-code @skill code-analyzer $1
read -p "Pulsa Enter para continuar..."
echo "📋 Paso 2/4: plan de refactor..."
claude-code @skill refactor-planner
read -p "Pulsa Enter para continuar..."
echo "🧪 Paso 3/4: generando tests..."
claude-code @skill test-generator
read -p "Tras confirmar los tests, pulsa Enter para continuar..."
echo "✅ Paso 4/4: revisión final..."
claude-code @skill code-reviewer

En una god class de 2.000 líneas: 7 clases con responsabilidades claras, cobertura de tests del 40 % al 85 %.

Compartir en equipo: los Skills como infraestructura

Gestionamos un repositorio Git team-skills:

team-skills/
├── frontend/
   ├── react-review.md          # Revisión React
   ├── vue-component-gen.md     # Generación de componentes Vue
   └── css-optimizer.md         # Optimización CSS
├── backend/
   ├── api-design.md            # Normas de diseño API
   ├── database-review.md       # Revisión de base de datos
   └── security-audit.md        # Auditoría de seguridad
└── common/
    ├── code-cleaner.md          # Limpieza de código
    ├── test-generator.md        # Generación de tests
    └── commit-msg.md            # Mensajes de commit Git

Enlace simbólico en cada proyecto local:

# Configuración única
git clone [email protected]:your-team/team-skills.git ~/.team-skills
ln -s ~/.team-skills/* .claude/skills/

Beneficios inmediatos:

  • Onboarding: biblioteca completa desde el día 1
  • Sincronización: git pull para la última versión
  • Estilo uniforme para todo el equipo

Un becario escribía código conforme al segundo día; antes, una semana de formación.

Skills + CLAUDE.md: la dupla ideal

En CLAUDE.md en la raíz, reglas globales:

# Contexto del proyecto
- Stack: React 18 + TypeScript 5.0 + Vite 4
- Lint: reglas Airbnb ESLint
- Commits: Conventional Commits
- Estado: Zustand (Redux prohibido)

## Convenciones importantes
- Tipos TypeScript completos en todos los componentes
- API unificada vía src/utils/request.ts
- Componentes en PascalCase (UserProfile.tsx)
- Utilidades en camelCase (formatDate.ts)

## Estructura de directorios
src/
├── components/    # Componentes compartidos
├── pages/        # Páginas
├── hooks/        # Hooks personalizados
├── utils/        # Utilidades
├── services/     # Servicios API
└── stores/       # Estado Zustand

El skill referencia esas reglas:


---

title: "Generador de componentes React"

---

# Instrucciones de generación
Respeta estrictamente stack, estructura y nomenclatura definidos en CLAUDE.md.
El componente debe:
- Usar TypeScript
- Cumplir ESLint del proyecto
- Ubicarse en el directorio correcto
- Seguir la gestión de estado acordada

El skill lee CLAUDE.md; el código generado encaja con el proyecto, incluso tras un clone.

Mis 5 Skills imprescindibles

Más de 20 skills tras seis meses; los más usados:

1. Generador de tests (test-gen.md)

Tras escribir funcionalidad, lo peor es completar tests. Analiza la lógica y genera tests unitarios, casos límite y errores. Cobertura del 40 % al 85 %, la mitad de tiempo en tests.

2. Generador de mensajes de commit (commit-msg.md)

Cada commit exige pensar el mensaje. Analiza el diff y propone mensajes Conventional Commits. Ejemplo:

feat(user-auth): añadir inicio de sesión OAuth2.0
- Integración con Google y GitHub
- Renovación de token JWT
- Middleware de permisos
Closes #123

Unas 30 líneas, uso diario: horas ahorradas.

3. Asistente de refactorización (refactor.md)

Cuando el código legacy necesita optimización y no sabes por dónde empezar:

  • Detecta code smells
  • Prioriza el refactor
  • Plan paso a paso
  • Mantiene el comportamiento

La god class de 2.000 líneas pasó por aquí.

4. Experto en auditoría de seguridad (security-audit.md)

SQL injection, XSS, fugas de secretos, permisos. Antes de producción: 3 vulnerabilidades potenciales.

5. Generador de documentación (doc-gen.md)

Doc API desde el código, Markdown desde comentarios, changelog. De 2 horas a 10 minutos; se acabó el «código actualizado, doc olvidada».

5 consejos para escribir buenos Skills

1. Frontmatter cuidado

title y description aparecen en la lista:


---

title: "Experto en revisión full stack"
description: "Revisión front/back: seguridad, rendimiento y mantenibilidad"
version: "2.1.0"
tags: ["revisión", "seguridad", "rendimiento"]

---

version para seguimiento; tags para clasificar.

2. Rol explícito

«Eres un experto…» ayuda a Claude Code mejor que un simple «revisa este código».

3. Ejemplos ✅ / ❌

### Riesgo de inyección SQL
❌ Peligroso:
```javascript
const query = `SELECT * FROM users WHERE id = ${userId}`;

✅ Seguro:

const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);

### 4. Formato de salida preciso

```markdown
## Formato de salida
### 🔴 Crítico (corregir)
- [archivo:línea] descripción
- Riesgo
- Corrección (ejemplo de código)
### 🟡 Recomendado
- [archivo:línea] descripción
- Motivo
- Propuesta de mejora

5. Reglas de manejo de errores

## Manejo de errores
- Error de sintaxis: indicar ubicación, no continuar la revisión
- Archivo inaccesible: pedir verificar la ruta
- Código > 5000 líneas: sugerir revisión por lotes

Preguntas frecuentes

¿Demasiados Skills, nombres olvidados?

Convención de nomenclatura:

  • review-*: revisión
  • gen-*: generación
  • util-*: utilidades
  • fix-*: corrección

Ejemplos: review-frontend.md, gen-api.md, util-commit.md

¿Salida demasiado larga?

Modo conciso en el skill:

Modo detallado por defecto. Con `--brief`:
- Lista de problemas (una línea cada uno)
- Gravedad
- Correcciones clave

¿Comportamiento distinto según el proyecto?

Solicitar contexto al inicio:

## Pasos previos
1. Leer package.json (versiones)
2. tsconfig.json
3. .eslintrc
4. README.md (arquitectura)

Palabras finales

Seis meses con Skills: al menos un 40 % más de eficiencia. Menos trabajo mental repetitivo; más tiempo para arquitectura y lógica de negocio.

Si aún escribes prompts a mano:

  1. Empieza hoy — un skill simple (revisión o tests)
  2. Refina tras cada uso
  3. Comparte en equipo
  4. Sigue la documentación oficial

El valor de un Skill no está en su complejidad, sino en el problema real que resuelve. Mi commit-msg tiene unas 30 líneas y lo uso a diario.

Organiza tus prompts repetitivos en Skills. En tres meses te lo agradecerás.

Recursos relacionados


FAQ

¿Qué diferencia hay entre Skill y Subagent?
Skill:
• Plantilla de prompt reutilizable
• Directorio .claude/skills/
• Invocación con @skill
• Ligero, para operaciones habituales

Subagent:
• Asistente de IA independiente
• Directorio .claude/agents/
• Herramientas y modelo propios
• Más potente para flujos complejos
¿Cómo hacer que un Skill lea la configuración del proyecto?
Referencia CLAUDE.md en el Skill:
'Respeta estrictamente stack, estructura y nomenclatura definidos en CLAUDE.md'

Claude Code lee la configuración en la raíz; el código generado sigue las normas del proyecto.
¿Qué debe incluir un archivo Skill?
Contenido recomendado:

1) Frontmatter (title, description, version)

2) Definición de rol («Eres un experto…»)

3) Descripción de la tarea

4) Formato de salida

5) Convenciones o ejemplos de código

6) Reglas de manejo de errores

Los ejemplos ✅/❌ mejoran la precisión.
¿Cómo gestionar una biblioteca Skill de equipo?
Enfoque:

1) Repositorio Git team-skills (front, back, común)

2) Enlace simbólico (ln -s) a .claude/skills/ en local

3) git pull para sincronizar

Estilo unificado; los nuevos llegan operativos.
¿Se pueden encadenar Skills en un flujo de trabajo?
Sí.

Ejemplo de refactor:
• @skill code-analyzer (análisis)
• → @skill refactor-planner (plan)
• → @skill test-generator (tests)
• → @skill code-reviewer (revisión)

Un script shell puede automatizar la cadena.

8 min de lectura · Publicado el: 23 nov 2025 · Actualizado el: 21 ago 2026

Comentarios

Inicia sesión con GitHub para dejar un comentario

Easton BlogEaston Blog