La habilidad /prototype

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

Qué hace

prototype escribe código desechable que responde una pregunta: si este modelo de estados se siente bien, o cómo debería verse esta pantalla. La pregunta va primero y decide la forma de todo lo que sigue; un prototipo que responde la pregunta equivocada es puro desperdicio, por bueno que se vea.

Desechable es una restricción sobre cómo se escribe el código, no una promesa de destruirlo. Sin pruebas, sin manejo de errores más allá de lo que lo hace correr, sin abstracciones, sin persistencia, porque nada de eso ayuda a aprender lo único que intentas aprender. Lo que sobrevive es la respuesta, integrada al código real, y el prototipo mismo, aparcado en una rama fuera de main como evidencia de dónde salió la respuesta.

Cuándo recurrir a ella

Escribe /prototype, o el agente la usará automáticamente cuando la tarea encaje.

Recurre a ella en cuanto choques con una pregunta que no puedes resolver hablando: una máquina de estados cuyos casos borde no caben en tu cabeza, una pantalla que no puedes imaginar hasta ver tres versiones lado a lado. Las sesiones de interrogatorio se inflan con exactamente estas preguntas: el agente reformula, tú adivinas y el alcance crece hasta llenar la incertidumbre. Deja de interrogar, construye la versión desechable, mírala y responde en una línea. Si en cambio algo ya construido se porta mal y quieres saber por qué, usa diagnosing-bugs; prototipar explora qué construir, no por qué lo construido está roto.

También llegarás aquí sin elegirlo. wayfinder archiva tickets de decisión prototype en su mapa, y trabajar uno es esta habilidad.

Dos ramas

La pregunta elige la rama, y las ramas producen artefactos muy distintos:

• «¿Esta lógica / modelo de estados se siente bien?»: un único archivo HTML compartible. Una página autocontenida, sin build ni servidor, que alguien abre con doble clic. Lleva un panel de estado etiquetado que se vuelve a renderizar tras cada clic, botones de juego libre para toquetear el modelo en cualquier orden y recorridos guiados por pestañas (un escenario por pestaña, cada uno con los botones ordenados que hay que pulsar debajo). Todo está etiquetado en lenguaje del dominio, para que puedas pasarlo a un diseñador, un PM o un experto del dominio y dejar que sientan el modelo ellos mismos. La lógica tras la página es un módulo puro pequeño (un reductor, una máquina, un conjunto de funciones) separado del DOM para que la versión validada se traslade directa al código real.
• «¿Cómo debería verse esto?»: varias variaciones de UI radicalmente distintas en una ruta, conmutables desde una barra flotante inferior y un parámetro URL ?variant=. Las variantes deben discrepar en estructura, no en color; tres grillas de tarjetas retocadas son papel tapiz, no un prototipo. Se renderizan dentro de una página real siempre que sea posible, contra datos reales y densidad real, porque una variante juzgada en el vacío siempre se ve bien.

Ambas mantienen el estado en memoria, arrancan sin requerir pensar y te muestran el estado completo tras cada paso. En cuanto te encuentres endureciendo una (añadiendo una prueba, conectando la base de datos real, generalizando para un caso que quizá quieras después), dejaste de prototipar.

El prototipo es una fuente primaria

Un prototipo terminado deja dos cosas, y van a lugares distintos.

La respuesta (el veredicto más la pregunta que resolvió) se captura de forma duradera: un mensaje de commit, un ADR, la incidencia de implementación. Eso es lo que la rama principal conserva, integrado al código real.

El prototipo es la evidencia ejecutable de dónde salió la respuesta, y no se borra. Tampoco pertenece a main: ahí no hay nada que mantener y se pudre rápido. Así que se publica en una rama desechable prototype/<name> fuera de main, sin fusionar nunca, con un puntero de contexto a esa rama dejado en la incidencia de implementación. Main queda limpio; la exploración queda ubicable y reejecutable por quien retome el trabajo después.

Preguntas comunes

Espera, ¿no se suponía que el prototipo se borra? Ya no. Antes sí: constrúyelo, quédate con la respuesta, tira el código. La objeción más aguda nunca fue la velocidad: fue quién retoma el trabajo la próxima sesión y con qué trabaja. Un resumen en prosa de un prototipo pierde lo que lo hizo convincente. Así que el prototipo ahora se trata como fuente primaria: aterriza en una rama prototype/<name> fuera de main y la incidencia de implementación la señala. Lo que cambió es dónde vive el código, no la disciplina; sigue sin fusionarse nunca a main.

Antes construía una app de terminal. ¿Dónde quedó? La rama de lógica ahora emite un único archivo HTML compartible. Una app de terminal solo la puede manejar alguien con el repositorio clonado y un runtime instalado, lo que excluye justo a las personas cuya opinión necesita el prototipo: el diseñador, el PM, el experto del dominio que sabe qué se supone que significa el modelo de estados. Un único archivo autocontenido que se abre con doble clic y sobrevive a ser enviado por correo lo puede manejar cualquiera. El módulo puro de lógica debajo no cambió, y sigue siendo la parte que se traslada al código real.

Un agente me dijo que hiciera /prototype cuando debería haber estado implementando. Conocido, y es un problema de nombres. prototype es una palabra genérica y atractiva que para un agente que no conoce el flujo se lee como «el obvio siguiente paso» una vez que existen tickets, así que se recomienda por nombre aun donde el diseño quedó totalmente cerrado en conversación. Si ya sabes qué construir, el siguiente paso es /implement, por ticket. Recurre a un prototipo solo cuando una pregunta concreta de diseño sigue genuinamente abierta y hablando no se va a resolver.

¿Debería prototipar toda la aplicación antes de construir sus funcionalidades de producción (digamos, para mostrarla a prospectos)? Ese es otro artefacto con el nombre de esta habilidad. Un prototipo aquí abarca una pregunta, y «¿qué es toda la app?» no es una. Un prototipo de la app completa no tiene punto de parada natural, así que se convierte en la app de producción por impulso: el pase de limpieza nunca ocurre, y código escrito bajo reglas de prototipo (sin pruebas, sin manejo de errores) termina frente a usuarios. Si necesitas una demo de ventas, constrúyela deliberadamente como demo y deja explícito que nada de eso es producción. Si necesitas resolver una duda de diseño, recórtala a esa duda.

¿Cómo lo ejecuto en su propia sesión? Un prototipo vive en su propio directorio y genera mucho contexto que no quieres en el hilo que hizo la pregunta, así que ejecútalo en otro lado y trae de vuelta solo la respuesta. handoff es el puente en ambas direcciones.

¿No es esta la forma más rápida posible de quemar tokens? Puede serlo, si prototipas preguntas que podrías haber resuelto hablando, o dejas que un prototipo se extienda por toda una funcionalidad. La comparación que importa no es tokens contra cero; es tokens contra construir el modelo de estados equivocado y descubrirlo después de que ya tiene llamadores en producción. Mantén la pregunta estrecha y la ejecución corta, y el gasto se mantiene proporcional.

Funciona si

• Puedes decir en una frase qué pregunta existe para responder el prototipo, y está escrita arriba de la demo, no solo en tu cabeza.
• Alguien que no lee código puede manejar la demo de lógica. Abre el archivo, pulsa los botones en una pestaña de recorrido y describe lo que ve con sus palabras.
• Alguien dice «espera, eso no debería ser posible» o «ah, yo asumía X». Eso es un error en la idea, que es todo el punto.
• Las variantes de UI discrepan en diseño e jerarquía de información, no solo en color y textos, y el feedback que recibes es «el encabezado de B con la barra lateral de C».
• Se responde en una sentada. Si sigues construyéndolo un día después, la pregunta era demasiado grande; divídela.
• Cuando termina, main contiene la decisión y nada del prototipo, y la incidencia de implementación apunta a la rama que aún lo guarda.

Dónde encaja

prototype es una habilidad independiente para usar en cualquier momento: entras para resolver una duda de diseño, luego sales, y también es maquinaria que otra habilidad ejecuta.

Su mayor consumidora es wayfinder. Un mapa de wayfinder está hecho de tickets de decisión, y prototype es uno de los cuatro tipos que puede ser un ticket: el que se usa cuando la pregunta bloqueadora es «cómo debería verse» o «cómo debería comportarse», que ninguna discusión resuelve. Wayfinder eleva la fidelidad de una discusión nebulosa haciendo algo concreto a lo cual reaccionar, y esta habilidad es cómo se construye esa cosa concreta. Un ticket de prototipo se resuelve con la respuesta, y el prototipo queda enlazado desde el mapa como recurso.

Las otras vecinas están antes y después de eso. grill-me y grill-with-docs responden preguntas interrogables; las no interrogables vienen aquí, y la respuesta de una línea vuelve a la entrevista. Después, un modelo de estados validado o una dirección de UI se vuelve entrada ya acordada para to-spec, que puede incrustar el fragmento rico en decisiones que produjo el prototipo en vez de describirlo en prosa. Para cualquier otra cosa, ask-matt te dirige por todo el conjunto.