prototype (mattpocock/skills)

Reseña

Codex CLI 0.166 (gpt-6-astra, razonamiento bajo) en una máquina de prueba Mac, con un proyecto temporal nuevo y HOME/TMPDIR/cachés temporales en cada ejecución, la skill instalada (grupo con skill), sin ella (control) o sin ella pero con el requisito central de la skill comprimido en una frase añadida al prompt (grupo del prompt de una frase), 2 ejecuciones por grupo y tarea, red desactivada y escrituras en /tmp bloqueadas. Los prompts nunca mencionan la skill (salvo la formulación indicada más abajo). Tres tareas: modelar un ciclo de vida de suscripción con fallos de pago (cuestión de estados), comparar opciones para una sección de precios estática (cuestión de aspecto; el contenido real de los planes debe mantenerse) y dejar que el usuario pruebe reglas de acumulación de descuentos antes de programar (cuestión de lógica; guardar en prototype/). Las comprobaciones de reglas incluyen HTML autocontenido, cinco estados mostrados, botones por evento, escenarios guiados, marcado como prototipo, ningún archivo de test y, para la tarea de precios, al menos tres variantes, un parámetro de URL ?variant= y un conmutador flotante fijo.

Comparación de tres ramas

Medido con Codex CLI en 18 ejecuciones, puntuado con comprobaciones basadas en reglas y sin juez LLM. Total 27.2 / 30, veredicto Recomendada.

Veredicto: Recomendada (27.2 / 30). Fuente: mattpocock/skills, skills/engineering/prototype, fijada en el commit 4ae2317. Instalación: npx skills@latest add mattpocock/skills --skill prototype. Licencia: MIT (LICENSE del repositorio).

Qué es

La skill prototype de mattpocock/skills: crea un prototipo desechable que responde a una pregunta de diseño. Las preguntas de lógica o estado reciben un único archivo HTML con un panel de estado, botones de juego libre y recorridos guiados; las preguntas de aspecto reciben varias variantes radicalmente distintas en una misma ruta, conmutadas con un parámetro de URL y una barra flotante inferior. Reglas: marcado claramente como desechable, trivial de ejecutar, sin persistencia, sin pulido, sin tests. SKILL.md más LOGIC.md y UI.md, unas 2,600 palabras en total; solo Markdown.

Cómo lo probamos

Codex CLI 0.166 (gpt-6-astra, razonamiento bajo) en un Mac de pruebas, un proyecto temporal nuevo y HOME/TMPDIR/cachés temporales por ejecución, skill instalada (tratamiento) o ausente (control) o ausente con el requisito central de la skill comprimido en una frase añadida al final del prompt (grupo de una frase), 2 ejecuciones por grupo y tarea, red desactivada, escrituras en /tmp bloqueadas. Los prompts nunca mencionan la skill (salvo la formulación indicada abajo).

Tres tareas: modelar un ciclo de vida de suscripción con fallos de pago (pregunta de estado), comparar opciones para una sección de precios estática (pregunta de aspecto, el contenido real de los planes debe mantenerse) y dejar que el usuario pruebe reglas de acumulación de descuentos antes de programar (pregunta de lógica, guardar en prototype/). Las comprobaciones de reglas incluyen HTML autocontenido, cinco estados mostrados, botones por evento, escenarios guiados, marcado como prototipo, sin archivos de test y, para la tarea de precios, al menos tres variantes, un parámetro de URL ?variant= y un conmutador flotante fijo.

1. Prototipar un modelo de estados de suscripción — No sé si nuestro ciclo de vida de suscripción tiene sentido cuando fallan los pagos. Estados: trial, active, past_due, paused, canceled. Eventos: termina el trial, el pago se realiza, el pago falla, el usuario pausa, el usuario reanuda, el usuario cancela, el usuario reactiva. Reglas: dos fallos…
2. Prototipar variantes de la página de precios — En pricing.html de este pequeño sitio estático (tres planes) no tengo claro cómo presentar los planes. Haz varias opciones de diseño distintas de esa sección que pueda comparar en el navegador; el contenido real de precios debe mantenerse. Sin paso de build.
3. Prototipar reglas de acumulación de descuentos — ¿La acumulación de descuentos se siente bien? Reglas hasta ahora: el cupón SAVE10 es un 10% de descuento, el cupón HALF es un 50%, los pedidos de más de $50 envían gratis, los miembros del programa de fidelidad tienen un 5% extra. No consigo decidir en qué orden se aplican ni cuáles pueden acumularse. Quiero probar casos y ver qué…

La puntuación es programática (tests ocultos / detección de problemas sembrados / comprobaciones de restricciones / renderizado + OCR cuando corresponde), 0–5 por ejecución. Ningún juez LLM decidió ninguna puntuación.

Resultados

La frase única que recibió el tercer grupo: "Crea un prototipo desechable que responda a una pregunta concreta: para preguntas de lógica o estado, un único archivo HTML autocontenido con un enunciado visible de la pregunta, un panel legible del estado actual que se vuelva a renderizar tras cada clic, un botón por acción y escenarios de recorrido guiado (camino feliz, caso límite, una acción ilegal); para preguntas de aspecto, tres variantes radicalmente distintas en una página, conmutadas por un parámetro de URL ?variant= y una barra flotante inferior. Sin tests, sin pulido."

Puntuación media: 3.71 sin vs 4.95 con la skill (delta +1.23). Tokens por ejecución: 133k vs 136k (1.02x); tiempo 186s vs 149s. Grupo de una frase: 4.72 (la ganancia de la skill sobre la frase única: +0.23; la ganancia de la frase única sobre sin skill: +1.01); tokens de la frase única 89k por ejecución, así que la skill cuesta 1.52x la frase única.

Qué ocurrió

• Puntuación media 3.71 para el control, 4.72 para la versión de una frase, 4.95 para la skill. La skill está +1.24 sobre el control y +0.23 sobre la frase única con 136k tokens por ejecución frente a 133k (1.02x) del control y 89k de la frase única (1.5x).
• La tarea de aspecto muestra el efecto: la skill produjo tres variantes con un conmutador flotante inferior y variantes conmutables por URL en ambas ejecuciones (5.0 y 5.0 según nuestras comprobaciones); el control puntuó 4.0 y 1.0: sin barra flotante en ninguna ejecución, tres diseños con un conmutador y un parámetro de URL en una ejecución y no en la otra, y en una ejecución faltaba el precio de un plan en la página.
• En las dos tareas de lógica, el control ya construyó HTML interactivo (4.4-4.8 en el modelo de suscripción, 4.0 en la acumulación de descuentos); la skill añade los escenarios de recorrido y la etiqueta de prototipo: los escenarios aparecen en 4 de 4 ejecuciones con skill frente a 2 de 4 del control.
• La versión de una frase rindió igual en la tarea de precios; perdió un poco en las tareas de lógica por no marcar siempre el archivo como prototipo (2 de 4 ejecuciones).

Puntuaciones por dimensión

Límites de esta prueba

• Comprobaciones basadas en reglas de características (variantes, barra flotante, escenarios); la calidad de los diseños y si el prototipo responde a la pregunta no fueron juzgadas por una persona.
• La puntuación se corrigió dos veces durante el análisis: las variantes pueden vivir en archivos CSS/JS separados, y un conmutador de diseño cuenta como variante; la primera pasada los subcontó, así que no se usan los números anteriores.
• El consejo de la skill de hacer commit del prototipo en una rama desechable y dejar un puntero en un issue no puede probarse en una carpeta temporal.
• n = 2 por grupo y tarea: las diferencias de menos de ~1 punto son ruido.
• La puntuación basada en reglas mide lo que las comprobaciones pueden ver; no puede juzgar el gusto ni si el resultado es el mejor posible.

Seguridad

Consulta security.md. Escaneo: 1 CRITICAL / 1 HIGH / 0 MEDIUM. Veredicto: segura de ejecutar (sandbox sin red). Un escaneo limpio no demuestra que una skill sea segura.

Conclusión

La skill hace claramente que Codex construya el tipo de prototipo que describe (variantes conmutables por URL, barra flotante, escenarios guiados) donde una petición simple no lo consigue, sin coste extra de tokens. Un resumen de una frase consigue la mayor parte del mismo comportamiento, pero la skill añade los detalles del recorrido de lógica y del etiquetado como prototipo.