writing-plans (obra/superpowers)

Name: writing-plans (obra/superpowers) review
Item: writing-plans (obra/superpowers)
Rating: 25.3
Author: Agent Skills

Convierte una especificación o requisitos en un plan de implementación paso a paso antes de tocar código.

writing-plans: convierte una especificación breve de una función en un plan TDD paso a paso (control 1.6, con skill 4.4, prompt de una frase 4.2) a cambio de 1.35 veces los tokens; un prompt de una frase con el mismo formato puntúa casi igual

RecomendadaSegura

Codex CLI · gpt-6-astra

25.3 / 30

Mejora frente a sin skill: +2.87 · Recomendada · 18 ejecuciones

Recomendada: el total 25.3/30 es al menos 22, la calidad de salida 4.4 es al menos 3.5 y la mejora +2.87 es al menos +1.0.

SOTA

Aprobada

Probada con Codex.

Cubre Codex, Claude Code

Codex CLI 0.166 (nivel SOTA): 18 ejecuciones puntuadas. Una pasada aquí también cubre Claude Code según nuestra regla de niveles; no dice nada sobre el segundo nivel.

Puntuaciones

Cada dimensión va de 0 a 5 y las seis suman el total sobre 30. 5 es mejor en todas las dimensiones. Coste 5 significa barato y rápido. Instalación 5 significa fácil.

Fiabilidad de activación: 5.0
Mejora frente a sin skill: 4.9
Calidad de salida: 4.4
Coste en tokens y tiempo: 3.0
Instalación y portabilidad: 4.0
Seguridad: 4.0

Revisión de seguridad

Segura

Escaneo estático: 0 CRITICAL / 0 HIGH / 0 MEDIUM. Revisión manual: Segura de ejecutar en un sandbox sin red (sin hallazgos). Un escaneo limpio no demuestra que una skill sea segura.

Instalar

npx skills@latest add obra/superpowers --skill writing-plans

Origen

Commit fijado: 2ce8aa15d05bd57213e6f746f953aafb7ded7a8b

Probada: 2026-11-02

Qué probamos

Planifica fechas de vencimiento para una CLI — spec.md describe una función para esta pequeña CLI de tareas. Escribe el plan de implementación en plan.md en esta carpeta. No escribas código en el proyecto, solo el plan.
Planifica una exportación CSV — spec.md describe una función para este módulo de informes. Escribe el plan de implementación en plan.md en esta carpeta. No escribas código en el proyecto, solo el plan.
Planifica la limitación de tasa de una API — spec.md describe una función para esta API de notas. Escribe el plan de implementación en plan.md en esta carpeta. No escribas código en el proyecto, solo el plan.

Ventajas

Eleva la puntuación media de 1.56 a 4.43 frente a sin skill (+2.87).
La skill se activó sin nombrarla: se leyó el archivo de la skill en 6/6 ejecuciones con skill.

Inconvenientes

Salvedad de la prueba: cambiamos tres comprobaciones tras ver las primeras puntuaciones y volvimos a puntuar las 18 ejecuciones con las nuevas reglas: la comprobación de marcadores de posición ya no coincide con la palabra TODO, que es el nombre del producto en una tarea; los patrones de «primero el test que falla» y de «salida esperada» aceptan la redacción «Expect failure»; se bajaron los umbrales de commit y de casillas. Antes del cambio, la skill puntuaba 2.98 y el prompt de una frase 4.04; después, 4.43 y 4.21. El control se mantuvo cerca de 1.5 en ambos casos.
n=2 por tarea y rama; las diferencias de menos de aproximadamente 1 punto son ruido.

Reseña

Codex CLI 0.166 (gpt-6-astra, razonamiento bajo) en un PC de pruebas Windows dedicado, un proyecto temporal nuevo y HOME/TMPDIR/cachés temporales en cada ejecución, skill instalada (grupo con skill), ausente (control) o ausente 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, escrituras en /tmp bloqueadas. Los prompts nunca mencionan la skill (salvo la redacción indicada abajo). Tres proyectos Python pequeños (CLI de tareas, módulo de informes, API de notas), cada uno con un spec.md. El prompt solo pide un plan de implementación en plan.md y prohíbe escribir código. No describe el formato del plan. El prompt de una frase describe todo el formato: pasos pequeños de 2-5 minutos, rutas exactas, primero el test que falla con el código completo, comando exacto con la salida esperada, implementación mínima, commit de git, sin marcadores de posición.

Comparación de tres ramas

Rama	Puntuación media (0-5)	Tokens por ejecución
Sin la skill	1.56	88k
Prompt de una frase	4.21	127k
Con la skill	4.43	119k

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

Aviso: Cambiamos tres comprobaciones después de ver las primeras puntuaciones y volvimos a puntuar las 18 ejecuciones con las nuevas reglas: la comprobación de marcadores de posición ya no coincide con la palabra TODO, que es el nombre del producto en una tarea; los patrones de test fallido primero y de salida esperada aceptan la fórmula «Expect failure»; los umbrales de commit y de casillas se rebajaron. Antes del cambio, la skill puntuaba 2.98 y el prompt de una frase 4.04; después, 4.43 y 4.21. El control se mantuvo cerca de 1.5 en ambos casos.

Veredicto: Recomendada (25.3 / 30). Fuente: obra/superpowers, skills/writing-plans, fijada en el commit 2ce8aa1. Instalación: npx skills@latest add obra/superpowers --skill writing-plans. Licencia: MIT (LICENSE del repositorio).

Qué es

La skill writing-plans (obra/superpowers): convierte una especificación en un plan de implementación en pasos manejables: rutas de archivo exactas, primero un test que falla, el comando exacto con el resultado esperado, implementación mínima, un paso de commit por tarea, pasos con casillas, sin marcadores TBD.

Cómo lo probamos

Codex CLI 0.166 (gpt-6-astra, razonamiento bajo) en un PC de pruebas Windows dedicado, 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 proyectos Python pequeños (CLI de tareas, módulo de informes, API de notas), cada uno con un spec.md. El prompt solo pide un plan de implementación en plan.md y prohíbe escribir código. No describe el formato del plan. La frase única describe todo el formato: pasos manejables de 2-5 minutos, rutas exactas, primero un test que falla con código completo, comando exacto con salida esperada, implementación mínima, commit de git, sin marcadores de posición.

Planificar fechas de vencimiento para una CLI — spec.md describe una función para esta pequeña CLI de tareas. Escribe el plan de implementación en plan.md en esta carpeta. No escribas código en el proyecto, solo el plan.
Planificar una exportación CSV — spec.md describe una función para este módulo de informes. Escribe el plan de implementación en plan.md en esta carpeta. No escribas código en el proyecto, solo el plan.
Planificar un límite de peticiones para la API — spec.md describe una función para esta API de notas. Escribe el plan de implementación en plan.md en esta carpeta. No escribas código en el proyecto, solo el plan.

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: "Escribe el plan como tareas manejables (cada paso de 2-5 minutos): rutas de archivo exactas, primero el test que falla con código completo, el comando exacto con su salida esperada, la implementación mínima con código completo y luego un paso de commit de git; sin marcadores como TBD o 'añadir validación'."

Tarea	Puntuación control	Una frase	Con la skill	Tokens control	Tokens de una frase	Tokens con la skill	Skill leída
t1-todo-due	1.51	4.21	4.28	94k	132k	111k	2/2
t2-csv-export	1.71	4.47	4.8	84k	129k	122k	2/2
t3-rate-limit	1.45	3.95	4.21	85k	120k	122k	2/2

Puntuación media: 1.56 sin vs 4.43 con la skill (delta +2.87). Tokens por ejecución: 88k vs 119k (1.34x); tiempo 66s vs 102s. Grupo de una frase: 4.21 (la ganancia de la skill sobre la frase única: +0.22; la ganancia de la frase única sobre sin skill: +2.65); tokens de la frase única 127k por ejecución, así que la skill cuesta 0.93x la frase única.

Qué ocurrió

Control 1.56, skill 4.43, una frase 4.21 (n=6 cada uno). Los planes del control son esquemas en prosa cortos (46-71 líneas): sin pasos de test-que-falla-primero, sin salida esperada y sin pasos de commit en ninguna de las 6 ejecuciones, y un comando de ejecución cada uno.
Los planes de la skill tienen 110-142 líneas en formato de casillas con un paso de test que falla, un paso de ejecución marcado 'Esperar fallo' o 'Esperar que todos los tests pasen', y un commit a nivel de tarea en la tarea CSV. Aun así tienen lagunas: 4 de 6 ejecuciones no tienen paso de commit de git, y los bloques de código aparecen en 2-3 pasos en lugar de en todos.
Los planes de una frase tienen unas 350 líneas con código completo en cada paso y todos los commits y comandos requeridos, pero sin casillas en 6/6 (un formato específico de la skill) y en 3 de 6 ejecuciones con menos de 4 comandos de ejecución, porque usaron redacción de PowerShell.
Tokens: skill 119k, una frase 127k, control 88k por ejecución (1.35x el control). La skill se leyó en 6/6 ejecuciones de tratamiento.

Puntuaciones por dimensión

Dimensión	Puntuación	Motivo
1_output_quality	4.43	Puntuación media 4.43/5 con la skill (comprobaciones programáticas, véase la tabla por tarea).
2_lift_vs_no_skill	4.87	+2.87 puntos frente a 1.56 sin la skill (n=2 por tarea; menos de ~1 punto es ruido).
3_trigger	5.0	Archivo de la skill leído en 6/6 ejecuciones de tratamiento.
4_instructions_portability	4	SKILL.md en el formato de superpowers; remite a otras skills de superpowers para la ejecución.
5_efficiency	3	1.34x tokens (119k vs 88k por ejecución) y 1.54x tiempo (102s vs 66s).
6_safety_hygiene	4	Solo prosa; consulta security.md.

Límites de esta prueba

Comprobaciones basadas en reglas sobre el texto de plan.md: recuentos de rutas, comandos, commits, casillas y bloques de código. No se juzgó la calidad del plan ni si realmente funcionaría.
Cambié las comprobaciones después de ver la primera puntuación y volví a puntuar todas las ejecuciones con las mismas reglas nuevas: (1) la comprobación de 'sin marcadores' coincidía con la palabra TODO, que es el nombre del producto en la tarea de la CLI de tareas (se eliminó TODO del patrón); (2) los patrones de 'test que falla primero' y 'salida esperada' se ampliaron para aceptar 'Esperar fallo' y 'Esperar que todos los tests pasen'; (3) el umbral de commits bajó de 3 a 2 (los planes de la skill tienen dos tareas) y el de casillas de 12 a 8. Antes de este cambio la skill puntuaba 2.98 y la frase única 4.04; después, 4.43 y 4.21. El control se mantuvo en 1.4-1.6 en ambos casos.
La comprobación de casillas cuenta un formato que usa la skill y que la frase única nunca pidió, lo que favorece a la skill.
n=2 por celda; fixtures pequeños.
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: 0 CRITICAL / 0 HIGH / 0 MEDIUM. Veredicto: segura de ejecutar (sandbox sin red). Un escaneo limpio no demuestra que una skill sea segura.

Conclusión

Sin ayuda, Codex escribe un esquema suelto; con la skill escribe pasos TDD reales. Un párrafo que nombre el mismo formato rinde casi igual y produce código más completo por paso, así que la skill es sobre todo un paquete cómodo de ese párrafo.

Transcripción

Registro de ejecuciones: writing-plans (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.)
Columnas: tarea, grupo-ejecución, puntuación (0-5), tokens, segundos, comprobaciones superadas, archivos de la skill que abrió el agente.

t1-todo-due control-1: puntuación 1.38, tokens 102848, s 60.8, comprobaciones 3/10, no abrió nada
t1-todo-due control-2: puntuación 1.64, tokens 86724, s 67.6, comprobaciones 3/10, no abrió nada
t1-todo-due oneliner-1: puntuación 4.47, tokens 133771, s 130.1, comprobaciones 9/10, no abrió nada
t1-todo-due oneliner-2: puntuación 3.95, tokens 131546, s 112.8, comprobaciones 8/10, no abrió nada
t1-todo-due treatment-1: puntuación 4.34, tokens 123893, s 104.1, comprobaciones 8/10, abrió writing-plans
t1-todo-due treatment-2: puntuación 4.21, tokens 99712, s 99.6, comprobaciones 8/10, abrió writing-plans
t2-csv-export control-1: puntuación 1.71, tokens 85021, s 70.6, comprobaciones 4/10, no abrió nada
t2-csv-export control-2: puntuación 1.71, tokens 84700, s 64.8, comprobaciones 4/10, no abrió nada
t2-csv-export oneliner-1: puntuación 4.47, tokens 129967, s 119.6, comprobaciones 9/10, no abrió nada

18 ejecuciones, 3 artefactos

Resultado de ejemplo

SOTA · With the skill: plan.md (t1-todo-due, run 1, Codex)

# Todo Due Dates Implementation Plan > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking. **Goal:** Add optional due dates, chronological listing, and an overdue-only CI check without migrating existing data. **Architecture:** Keep the existing JSON dictionary storage and implement date validation, ordering, and rendering in `todo/cli.py`. Capture the local date once per list invocation and pass it to a pure overdue predicate. Preserve the existing `main(argv=None)` entry point and argparse error handling. **Tech Stack:** Python standard library: argparse, datetime, json, unittest, unittest.mock, tempfile; no new dependencies. **Spec:** `spec.md` (read alongside this plan). ## Global Constraints - `todo add "title" --due 2026-03-01` stores an optional ISO due date with the item. - `todo list` prints overdue items first (marked `!`), then by due date, then undated items. - `todo list --overdue` prints only overdue items; exit code 1 if there are any (so CI can use it). - Invalid dates are rejected with a clear message and exit code 2. - Items already stored without a due date must keep working (no migration step for the user). ## Decisions for details not specified - Accept exactly `YYYY-MM-DD` with a real Gregorian calendar date; reject whitespace, compact dates, timestamps, and unpadded components. - An item is overdue only when unfinished and its due date is strictly before the current local date. Due today is not overdue. - Sort overdue items by ascending due date, then remaining dated items by ascending due date, then undated items. Preserve insertion order within equal keys. Completed items remain visible in ordinary listings but are never overdue. - Preserve `[ ] title` and `[x] title` for undated items. Append ` (due YYYY-MM-DD)` for dated items and prefix overdue lines with `! `, e.g. `! [ ] rent (due 2026-03-01)`. - Ordinary listing returns 0, even with overdue items. Overdue-only listing returns 0 with no output when none qualify. Listing never rewrites storage. - Store dates as strings under `due`; omit the key when not supplied. Treat an absent key or `null` as undated. Arbitrary corrupt JSON or malformed dates manually inserted into storage are outside this feature. ## Review Focus 1. Calendar boundaries: leap day is accepted only in leap years; impossible dates fail before storage changes (Task 1). 2. ISO-looking variants: compact dates, timestamps, whitespace, and unpadded dates are rejected (Task 1). 3. Midnight/today boundary: due today is not overdue; use one captured local date per listing (Task 2). 4. Completed items with past dates: remain visible without `!` and are excluded from overdue filtering (Tasks 2–3). 5. Legacy and tied items: missing/null dates work, ties retain insertion order, and listing leaves the JSON file untouched (Tasks 2–3). ## File Map - Modify `todo/cli.py`: add argument validation, optional date persistence, overdue predicate, sorting, rendering, and filter exit status. - Create `tests/test_cli.py`: isolated CLI tests u [... excerpt: first 3200 of 11517 characters]

Ver Pro