Capstone: la skill /plan-week

Lo ensamblamos todo

Ahora tienes todas las piezas: una skill de creación (cap. 3), una voz de marca (cap. 4), un quality gate automático (cap. 5), y una publicación paralela (cap. 6). Cada ladrillo se construyó y probó por separado — eso es lo que hace el ensamblaje tranquilo. Los unimos en un solo comando que planifica una semana entera de contenido: /plan-week.

Mide el camino recorrido con Lea: en el capítulo 1, descubría que un agente puede leer sus archivos. Ahora, está a punto de escribir una frase y obtener siete días de contenido multiplataforma, en su voz, verificado por su barrera, programado en las franjas adecuadas. No es magia: es composición. Cada capítulo era una función; este capítulo escribe el programa principal.

La arquitectura antes del código

Antes de crear la skill, entiende su flujo — porque eres tú quien deberá depurarlo si algo se atasca. El comando encadena cinco fases: investigación del tema, generación de un plan escrito en un archivo, pausa de validación humana, ejecución paralela por subagentes, y registro en el journal. La pausa en medio no es una concesión: es el punto de arquitectura más importante del capítulo.

flowchart LR
  A["Tema"] --> B["Investigación"]
  B --> C["content-plan.md"]
  C --> D{"Validación humana"}
  D -->|"A corregir"| C
  D -->|"OK"| E["Subagentes en paralelo"]
  E --> F["Posts programados + journal"]

Fíjate dónde está colocada la validación: después de la producción del plan completo (el trabajo largo y tedioso ya está hecho), pero antes de toda acción irreversible (nada está aún publicado ni programado). Es la colocación óptima del control humano: relees un documento terminado, cómodamente, y tu decisión versa sobre algo concreto. Validar demasiado pronto (sobre una intención vaga) no controla nada; validar demasiado tarde (después de la publicación) ya no sirve de nada.

Crear la skill /plan-week

crea una skill "plan-week" que:
- acepte un tema, borradores, URLs o imágenes
- investigue el tema y escriba un plan semanal en content-plan.md (día, n° de post, tema, texto completo, visual sí/no)
- el texto debe ser el post completo bien formateado, no un resumen, adaptado por plataforma
- cree el visual una vez por día (reutilizado por los posts del día)
- me muestre el plan y pida validación
- tras la validación, use subagentes paralelos para programar cada post
- reutilice la voz, la config y el journal de la skill /post

hazme preguntas una a la vez hasta el 95% de confianza.

Dos líneas de este prompt merecen tu atención. «El texto debe ser el post completo, no un resumen»: sin esta precisión, obtendrías un plan de temas — bonito pero inutilizable, porque aún tendrías que redactarlo todo. «Reutiliza la voz, la config y el journal de la skill /post»: es la composición en acción. La nueva skill no reinventa nada, se apoya en los ladrillos existentes — de ahí el interés de haber centralizado la voz en brand-voice.md en el capítulo 4.

El archivo como interfaz de trabajo

Claude investiga el tema, genera content-plan.md y pide tu acuerdo. Esta elección — un archivo en lugar de un largo mensaje en la conversación — es una práctica a retener para todos tus futuros sistemas. Un archivo se relee tranquilamente, se edita directamente, se versiona en Git, y sobrevive a la conversación.

# Plan de contenido — semana del 17 de junio

## Lunes — Post 1 (LinkedIn)
Tema: por qué el «sin perfume» es un falso amigo
Visual: sí (infografía de ingredientes)
Texto:
> Creemos hacer bien eligiendo «sin perfume»...
> [post completo, listo para publicar]

## Lunes — Post 2 (Twitter)
...

Relees; si un borrador no te convence, editas directamente el archivo — no hace falta describir la modificación a Claude, corriges el texto tú misma como en cualquier documento — y luego dices «continúa». Claude retoma el archivo en su estado actual y lanza un subagente por post, en paralelo. El archivo es la interfaz; la conversación es solo el disparador.

Cuando se descarrila: depurar una orquestación

Con un sistema que encadena cinco fases, hay que saber localizar una avería. El método es siempre el mismo: identificar la fase que produjo el problema, y corregirla por separado. ¿El plan está fuera de tema? Es la fase de investigación — precisa el brief o las fuentes en la skill. ¿Los textos son buenos pero el tono se desvía? Es brand-voice.md lo que hay que enriquecer (capítulo 4). ¿Un post está bloqueado en la programación? Lee el mensaje del quality gate (capítulo 5). ¿Una sola red falla? Es el subagente o la API de esa plataforma (capítulo 6).

Notas el reflejo: cada ladrillo del curso es también una zona de diagnóstico. Esa es la ventaja decisiva de haber construido el sistema pieza por pieza en lugar de en bloque — sabes dónde mirar, y puedes probar cada pieza por separado con los comandos de los capítulos anteriores.

El patrón a retener: mejora la herramienta, no la salida

Sigues al mando: validas el plan antes de toda ejecución. La IA y la automatización gestionan el trabajo repetitivo. Y cuando la brecha entre lo que querías y lo que Claude produjo es grande, no te limites a corregir el archivo: díselo — y pídele actualizar la skill para que la próxima vez sea mejor.

Concretamente, después de cada ejecución de /plan-week, hazte la pregunta: «¿qué he corregido a mano en el plan?» Cada corrección manual recurrente es una regla que le falta a la skill. Tres semanas de este reflejo y tus correcciones manuales tienden a cero — es medible, y es el criterio objetivo de un sistema maduro.

Lo que este capstone te ha enseñado realmente

Más allá del marketing de Lea, acabas de ejecutar un esquema universal de automatización: descomponer un proceso de negocio en etapas, codificar cada etapa (skill), asegurar lo no negociable (hook), paralelizar lo independiente (subagentes), y colocar la validación humana en el punto de máxima palanca. Reemplaza «posts» por «facturas a reclamar», «tickets de soporte a clasificar» o «vigilancia competitiva a resumir»: el esquema se mantiene tal cual.

Queda una fragilidad: todo este saber vive en archivos, pero Claude empieza de cero en cada sesión y debe redescubrirlos. El último capítulo lo resuelve — y es el que transforma una bonita demo en un sistema duradero.