La habilidad /wizard

Fuente: The /wizard Skill — traducción comunitaria no oficial al español.

Qué hace

wizard genera un script bash interactivo que guía a un humano, paso a paso, por un procedimiento manual: conectar servicios de terceros, ejecutar una migración única, mover un proyecto del estado A al estado B. Abre cada URL, dice qué hacer clic y copiar, captura lo que vuelve, y lo escribe en archivos .env y secretos de GitHub Actions.

El agente escribe el script; nunca lo ejecuta. Tú lo haces, en tu propia máquina. Así que un asistente no es una lista de instrucciones que sigues; es un programa que conduce el procedimiento y guarda el estado, y tu parte es hacer clic, pegar y pulsar Enter.

Cuándo usarla

Puedes escribir /wizard, y el agente también puede usarla por su cuenta. Cuando choca con un paso que tienes que dar tú (una clave que no puede crear, un panel en el que no puede hacer clic), te construye un asistente en lugar de escribir las instrucciones en el chat, donde se desplazan y se pierden.

Úsala cuando lo siguiente que te bloquea es un viaje por un panel:

Situación	Qué hace el asistente
Un dev nuevo necesita seis servicios configurados antes de que la app arranque	Abre cada panel en orden, captura las claves, las escribe en .env y CI
Una migración única necesita interruptores activados en un orden específico	Secuencia los pasos irreversibles tras puertas de confirmación
Un proyecto tiene que moverse del estado A al estado B una vez	Guía la transición e informa lo que no pudo hacer
Estás a punto de escribir esos pasos en un README	Escribe una versión ejecutable en su lugar, que no se pudre tan silenciosamente

No la uses para decidir qué construir; para eso, grill-with-docs y to-spec son las herramientas.

Requisitos previos

Ninguno para generar uno. El asistente que escribe corre en bash, y usa gh cuando una etapa fija un secreto o variable de GitHub. Si gh falta o no está autenticado, esa etapa se convierte en advertencia y el resumen de cierre te dice qué fijar a mano, en lugar de fallar la ejecución.

Etapas

Una etapa es una tarea enfocada en una pantalla. El script limpia la terminal entre etapas, así que una etapa que desborda la pantalla pierde la parte que se desplazó. Redactas las etapas en orden de dependencia y fijas TOTAL_STAGES, que conduce la visualización del progreso.

La definición ocurre antes de escribir una línea. La habilidad lee el repositorio en lugar de preguntar en frío: .env*, docker-compose*, configuración del framework, y cada referencia secrets.* / vars.* en .github/workflows/: cada una de ellas es un valor que el asistente tiene que producir. Luego te muestra la lista ordenada de etapas para confirmar, y solo después mapea cada etapa a la ruta exacta que sigue un humano (“Panel → Developers → API keys → Reveal test key → copiar”). Donde no conoce la UI actual, te pregunta o revisa la documentación en lugar de inventar clics.

Para cada valor capturado, la definición acuerda dónde cae:

Destino	Cuándo
Solo .env	El desarrollo local lo necesita, CI no
Secreto de GitHub	CI lo lee, y es sensible
Variable de GitHub	CI lo lee, y es público
.env y secreto	Desarrollo local y CI lo necesitan
Ninguno	La etapa es una acción pura: un interruptor activado, un plan mejorado

La plantilla ya resuelve la UX

La plantilla incluye toda la experiencia: progreso con tiempo restante, puertas de confirmación, apertura de URL multiplataforma incluyendo WSL, entrada oculta para secretos, upserts idempotentes en .env, escrituras con gh secret / gh variable, y un resumen de cierre de todo lo que tuvo que saltar. Todo lo que está sobre el marcador STAGES es una librería fija, idéntica en cada asistente y nunca editada a mano. La consistencia es el sentido. Tu trabajo es solo definir el procedimiento y redactar sus etapas.

El agente que escribe un asistente nunca lo ejecuta de principio a fin, porque abre navegadores y espera entrada humana. Lo verifica estáticamente en su lugar: bash -n, shellcheck donde esté disponible, y un rastreo de que cada valor cae donde la definición dijo, con cada nombre set_secret igualando una referencia real secrets.* en CI. Ajusta tus expectativas en consecuencia: la primera ejecución es tuya, y esa ejecución es la prueba.

Efímero por defecto

Lo que tienes	Qué hacer con el script
Una migración única, una configuración personal, una transición que nunca repetirás	Guárdalo en una ruta temporal o scripts/, ejecútalo, bórralo
Una ruta de configuración que la siguiente persona del repositorio también necesitará	Publícalo con commit y enlázalo desde el README, para que ejecuten el script en lugar de volver a preguntar a un agente

Preguntas comunes

¿Mis claves API terminan en el contexto del modelo?

No. El agente escribe un script; no lo ejecuta. Tú ejecutas el script, y captura la clave con entrada oculta de terminal y la escribe directo a .env o gh secret. El asistente es un CLI, y el modelo no está conectado a él. Una advertencia: eso vale para valores que el asistente captura en tiempo de ejecución. Si pegas una clave en el chat mientras defines el procedimiento, está en el contexto como cualquier otro texto pegado.

¿Puedo volver atrás y corregir un valor que escribí mal?

No a mitad de ejecución. No hay botón de atrás: las etapas corren hacia adelante, y una respuesta errónea en la etapa 3 significa Ctrl-C y re-ejecutar. Re-ejecutar es barato por diseño: cualquier valor ya escrito en .env se ofrece de vuelta como predeterminado, así que pulsas Enter en las etapas correctas y reescribes solo la errónea. Esto surgió en la semana de lanzamiento y no se ha cerrado desde entonces: “loved it! One thing though, is there a way to go back and correct what you’ve entered?”

Hay un error abierto relacionado. Las flechas en un prompt ask insertan ^[[D / ^[[C] en lugar de mover el cursor, porque el prompt usa read -r en lugar de Readline (issue #741). Retroceso funciona; flechas no. Borra hasta el error en lugar de mover el cursor dentro de él.

¿Sabe lo que ya tengo configurado?

En parte, y menos de lo que las reacciones del lanzamiento asumieron. Lee el repositorio antes de preguntar (tus archivos .env, docker-compose, configuración del framework, las referencias secrets.* en CI), así que define el alcance a valores genuinamente faltantes en lugar de partir de cero como un README. Lo que no hace es comprobar el servicio de terceros. Si una clave existe en tu .env el asistente la ofrece de vuelta y Enter la conserva; si ya creaste la cuenta de Stripe pero nunca guardaste la clave, el asistente igual te envía al panel por ella.

¿Dónde queda en el flujo, tras el interrogatorio y la spec?

En ningún punto en particular. Es independiente, no un paso de cadena. La suposición común es /grill-with-docs → /to-spec → /wizard, y esa secuencia está bien, pero el disparador es que aparezca un procedimiento manual, lo que puede ocurrir en cualquier punto: antes de empezar, a mitad de construcción, o mucho después de publicar. También funciona como herramienta de descubrimiento: la definición revela los prerrequisitos ocultos de una tarea, como las tres claves API en las que no habías pensado, antes de comprometerte con el trabajo.

¿Funciona fuera de Claude Code?

El artefacto sí, incondicionalmente: es un script bash plano y no le importa qué harness lo generó. La habilidad misma es invocada por el modelo, así que está listada en todas partes: escribe /wizard en Claude Code o $wizard en Codex, o solo describe la configuración en la que estás atascado. Ser invocada por el modelo también la mantiene fuera de #693, donde las superficies de escritorio y web de Claude quitan las habilidades invocadas por el usuario del listado del modelo y las reportan como no instaladas.

¿No era antes invocada por el usuario?

Lo era. Ahora es invocada por el modelo, así que el agente la usa sin que se lo pidas cuando choca con un paso que tienes que dar tú. Nada de lo que podías hacer antes dejó de funcionar: la invocación por modelo añade el alcance del agente, nunca quita el tuyo, así que /wizard se comporta exactamente como antes. Lo que cambió es el modo de fallo que jubila: el agente chocando con un muro de credenciales a mitad de construcción y volcando seis pasos numerados en el chat para que los sigas a mano.

Estaba en in-progress/: ¿dónde está ahora?

En engineering/, desde v1.2. Se graduó del cubo beta y ahora se publica en el plugin, así que llega con el resto del conjunto promovido en lugar de necesitar instalación individual. Su comportamiento no cambió al graduarse.

Funciona si

• Se te muestra una lista ordenada de etapas, y los valores que produce cada una, y se te pide confirmar, antes de que exista ningún script.
• Cada URL se abre antes de pedirte el valor de esa página. Nunca se te pide pegar algo que no te hayan enviado a buscar.
• Los secretos se escriben a ciegas. Nada sensible se refleja en tu historial.
• Cada etapa cabe en una pantalla. Nada que aún necesites se ha desplazado.
• Ctrl-C y re-ejecutar retoma donde lo dejaste, ofreciendo los valores ya guardados como predeterminados.
• La pantalla final lista lo que escribió, y por separado lista lo que no pudo hacer y tienes que terminar a mano.

Dónde encaja

wizard es una habilidad independiente para usar cuando quieras, en la línea donde la automatización se detiene y un humano tiene que hacer clic. Su vecino más cercano es setup-matt-pocock-skills, porque ambas existen para poner un repositorio en estado de trabajo: esa configura este conjunto de habilidades, mientras wizard genera una ruta de configuración para todo lo demás. También se combina con implement: cuando una construcción publica una funcionalidad que necesita credenciales o un corte manual, un asistente es como se hace la mitad humana. Cuando no sepas qué habilidad encaja en el momento, ask-matt te dirige.