writing-plans (obra/superpowers)

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

Transforme une spécification ou des exigences en plan d'implémentation étape par étape avant d'écrire du code.

writing-plans : transforme une courte spec de fonctionnalité en plan TDD étape par étape (contrôle 1.6, skill 4.4, une phrase 4.2) pour 1.35 fois les tokens ; un prompt d'une phrase avec le même format obtient presque le même score

RecommandéSûr

Codex CLI · gpt-6-astra

25.3 / 30

Gain par rapport à sans skill : +2.87 · Recommandé · 18 exécutions

Recommandé : total 25.3/30 d'au moins 22, qualité de sortie 4.4 d'au moins 3.5 et gain +2.87 d'au moins +1.0.

SOTA

Réussi

Testé avec Codex.

Couvre Codex, Claude Code

Codex CLI 0.166 (palier SOTA) : 18 exécutions notées. Une réussite ici couvre aussi Claude Code selon notre règle de palier ; elle ne dit rien du second palier.

Scores

Chaque dimension va de 0 à 5 et les six forment le total sur 30. 5 est la meilleure note dans chaque dimension. Coût 5 signifie bon marché et rapide. Installation 5 signifie facile.

Fiabilité du déclenchement: 5.0
Gain par rapport à sans skill: 4.9
Qualité de sortie: 4.4
Coût en tokens et en temps: 3.0
Installation et portabilité: 4.0
Sécurité: 4.0

Revue de sécurité

Sûr

Scan statique : 0 CRITIQUE / 0 ÉLEVÉ / 0 MOYEN. Revue manuelle : sûr à exécuter dans un bac à sable sans réseau (aucun problème détecté). Un scan propre ne prouve pas qu'un skill est sûr.

Installer

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

Source

Commit épinglé: 2ce8aa15d05bd57213e6f746f953aafb7ded7a8b

Testé: 2026-11-02

Ce que nous avons testé

Planifier des échéances pour un CLI — spec.md décrit une fonctionnalité pour ce petit CLI todo. Écrivez son plan d'implémentation dans plan.md dans ce dossier. N'écrivez aucun code dans le projet, le plan uniquement.
Planifier un export CSV — spec.md décrit une fonctionnalité pour ce module de rapport. Écrivez son plan d'implémentation dans plan.md dans ce dossier. N'écrivez aucun code dans le projet, le plan uniquement.
Planifier la limitation de débit d'une API — spec.md décrit une fonctionnalité pour cette API de notes. Écrivez son plan d'implémentation dans plan.md dans ce dossier. N'écrivez aucun code dans le projet, le plan uniquement.

Points forts

Fait passer le score moyen de 1.56 à 4.43 par rapport à sans skill (+2.87).
Le skill a été détecté sans être nommé : son fichier a été lu dans 6/6 exécutions avec skill.

Points faibles

Réserve de test : nous avons modifié trois contrôles après avoir vu les premiers scores, puis re-noté les 18 exécutions selon les nouvelles règles : le contrôle des placeholders ne correspond plus au mot TODO, qui est le nom du produit dans une tâche ; les motifs « premier test en échec » et « sortie attendue » acceptent la formulation « Expect failure » ; les seuils de commits et de cases à cocher ont été abaissés. Avant le changement, le skill obtenait 2.98 et le prompt d'une phrase 4.04 ; après, 4.43 et 4.21. Le contrôle est resté autour de 1.5 dans les deux cas.
n=2 par tâche et par bras ; les écarts inférieurs à environ 1 point sont du bruit.

Avis

Codex CLI 0.166 (gpt-6-astra, low reasoning) sur un PC Windows de test dédié, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (traitement) ou absent (contrôle) ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt d'une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée ci-dessous). Trois petits projets Python (CLI todo, module de rapport, API de notes), chacun avec un spec.md. Le prompt demande seulement un plan d'implémentation dans plan.md et interdit d'écrire du code. Il ne décrit pas le format du plan. Le groupe « une phrase » décrit tout le format : des étapes de 2 à 5 minutes, des chemins exacts, un test en échec d'abord avec le code complet, la commande exacte avec la sortie attendue, une implémentation minimale, un commit git, aucun placeholder.

Comparaison à trois bras

Bras	Score moyen (0-5)	Tokens par exécution
Sans le skill	1.56	88k
Prompt d'une phrase	4.21	127k
Avec le skill	4.43	119k

Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 25.3 / 30, verdict Recommandé.

Divulgation : nous avons modifié trois contrôles après avoir vu les premiers scores, puis re-noté les 18 exécutions selon les nouvelles règles : le contrôle des placeholders ne correspond plus au mot TODO, qui est le nom du produit dans une tâche ; les motifs « premier test en échec » et « sortie attendue » acceptent la formulation « Expect failure » ; les seuils de commits et de cases à cocher ont été abaissés. Avant le changement, le skill obtenait 2.98 et le prompt d'une phrase 4.04 ; après, 4.43 et 4.21. Le contrôle est resté autour de 1.5 dans les deux cas.

Verdict : recommandé (25.3 / 30). Source : obra/superpowers, skills/writing-plans, épinglé au commit 2ce8aa1. Installation : npx skills@latest add obra/superpowers --skill writing-plans. Licence : MIT (LICENSE du dépôt).

Présentation

Le skill writing-plans (obra/superpowers) : transformer une spec en un plan d'implémentation découpé en petites étapes : chemins de fichiers exacts, un test qui échoue d'abord, la commande exacte à lancer avec le résultat attendu, une implémentation minimale, une étape de commit par tâche, des étapes à cocher, aucun placeholder du type TBD.

Notre méthode de test

Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur un PC de test Windows dédié, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (groupe traité) ou absent (groupe témoin), ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée ci-dessous).

Trois petits projets Python (CLI de todo, module de rapport, API de notes), chacun avec un spec.md. Le prompt demande seulement un plan d'implémentation dans plan.md et interdit d'écrire du code. Il ne décrit pas le format du plan. Le prompt d'une phrase décrit tout le format : des étapes courtes de 2 à 5 minutes, des chemins exacts, un test qui échoue d'abord avec le code complet, la commande exacte avec la sortie attendue, une implémentation minimale, un commit git, aucun placeholder.

Planifier des dates d'échéance pour une CLI — spec.md décrit une fonctionnalité pour cette petite CLI de todo. Écris son plan d'implémentation dans plan.md, dans ce dossier. N'écris aucun code dans le projet, uniquement le plan.
Planifier un export CSV — spec.md décrit une fonctionnalité pour ce module de rapport. Écris son plan d'implémentation dans plan.md, dans ce dossier. N'écris aucun code dans le projet, uniquement le plan.
Planifier une limitation de débit d'API — spec.md décrit une fonctionnalité pour cette API de notes. Écris son plan d'implémentation dans plan.md, dans ce dossier. N'écris aucun code dans le projet, uniquement le plan.

Le scoring est programmatique (tests cachés / rappel des anomalies introduites / vérifications de contraintes / rendu + OCR le cas échéant), 0–5 par exécution. Aucun juge LLM n'a décidé d'un seul score.

Résultats

Le prompt d'une phrase donné au troisième groupe : « Écris le plan sous forme de tâches courtes (chaque étape de 2 à 5 minutes) : chemins de fichiers exacts, le test qui échoue d'abord avec le code complet, la commande exacte avec sa sortie attendue, l'implémentation minimale avec le code complet, puis une étape de commit git ; aucun placeholder comme TBD ou « add validation ». »

Tâche	Score témoin	Une phrase	Avec le skill	Tokens témoins	Tokens (une phrase)	Tokens avec le skill	Skill lu
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

Score moyen : 1.56 sans contre 4.43 avec le skill (delta +2.87). Tokens par exécution : 88k contre 119k (1.34x) ; temps 66s contre 102s. Groupe « une phrase » : 4.21 (gain du skill sur le prompt d'une phrase : +0.22 ; gain du prompt d'une phrase sur l'absence de skill : +2.65) ; 127k tokens par exécution pour le prompt d'une phrase, donc le skill coûte 0.93x ce prompt.

Ce qui s'est passé

Témoin 1.56, skill 4.43, une phrase 4.21 (n=6 chacun). Les plans du témoin sont de courts canevas en prose (46-71 lignes) : aucune étape de test qui échoue d'abord, aucune sortie attendue et aucune étape de commit dans les 6 exécutions, et une seule commande à lancer chacune.
Les plans avec le skill font 110-142 lignes dans un format à cases à cocher, avec une étape de test qui échoue, une étape d'exécution marquée « Expect failure » ou « Expect all tests to pass », et un commit au niveau de la tâche dans la tâche CSV. Ils ont encore des manques : 4 des 6 exécutions n'ont aucune étape de commit git, et des blocs de code apparaissent dans 2-3 étapes plutôt que dans chacune.
Les plans avec le prompt d'une phrase font environ 350 lignes avec du code complet à chaque étape et tous les commits et commandes requis, mais sans cases à cocher dans 6/6 (un format propre au skill) et, dans 3 des 6 exécutions, moins de 4 commandes à lancer, car ils employaient une formulation PowerShell.
Tokens : 119k pour le skill, 127k pour le prompt d'une phrase, 88k pour le témoin par exécution (1.35x le témoin). Le skill a été lu dans 6/6 exécutions avec le skill.

Scores par dimension

Dimension	Score	Pourquoi
1_output_quality	4.43	Score moyen de 4.43/5 avec le skill (vérifications programmatiques, voir le tableau par tâche).
2_lift_vs_no_skill	4.87	+2.87 points contre 1.56 sans le skill (n=2 par tâche ; en dessous d'environ 1 point, c'est du bruit).
3_trigger	5.0	Fichier du skill lu dans 6/6 exécutions avec le skill.
4_instructions_portability	4	SKILL.md au format superpowers ; renvoie à d'autres skills superpowers pour l'exécution.
5_efficiency	3	1.34x de tokens (119k contre 88k par exécution) et 1.54x de temps (102s contre 66s).
6_safety_hygiene	4	Uniquement de la prose ; voir security.md.

Limites de ce test

Vérifications basées sur des règles portant sur le texte de plan.md : comptage des chemins, commandes, commits, cases à cocher et blocs de code. La qualité du plan, sa capacité à vraiment fonctionner, n'a pas été jugée.
J'ai modifié les vérifications après avoir vu le premier scoring et renoté chaque exécution selon les mêmes nouvelles règles : (1) la vérification « aucun placeholder » trouvait le mot TODO, qui est le nom du produit dans la tâche de CLI de todo (TODO retiré du motif) ; (2) les motifs « test qui échoue d'abord » et « sortie attendue » ont été élargis pour accepter « Expect failure » et « Expect all tests to pass » ; (3) le seuil de commits est passé de 3 à 2 (les plans du skill ont deux tâches) et le seuil de cases à cocher de 12 à 8. Avant ce changement, le skill obtenait 2.98 et le prompt d'une phrase 4.04 ; après, 4.43 et 4.21. Le témoin est resté entre 1.4 et 1.6 dans les deux cas.
La vérification des cases à cocher compte un format que le skill utilise et que le prompt d'une phrase ne demandait jamais, ce qui favorise le skill.
n=2 par cellule ; petits projets de test.
n = 2 par groupe et par tâche : les différences inférieures à environ 1 point relèvent du bruit.
Le scoring basé sur des règles mesure ce que les vérifications peuvent voir ; il ne peut juger du goût ni du caractère optimal d'un résultat.

Sécurité

Voir security.md. Scan : 0 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict : sûr à exécuter (sandbox sans réseau). Un scan propre ne prouve pas qu'un skill est sûr.

En résumé

Sans aide, Codex écrit un canevas approximatif ; avec le skill, il écrit de vraies étapes TDD. Un paragraphe nommant le même format fait presque aussi bien et produit du code plus complet à chaque étape : le skill est donc surtout un paquet pratique de ce paragraphe.

Transcription

Journal d'exécution : writing-plans (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.)
Colonnes : tâche, groupe-exécution, score (0-5), tokens, secondes, vérifications réussies, fichiers de la skill ouverts par l'agent.

t1-todo-due control-1: score 1.38, tokens 102848, s 60.8, vérifications 3/10, rien ouvert
t1-todo-due control-2: score 1.64, tokens 86724, s 67.6, vérifications 3/10, rien ouvert
t1-todo-due oneliner-1: score 4.47, tokens 133771, s 130.1, vérifications 9/10, rien ouvert
t1-todo-due oneliner-2: score 3.95, tokens 131546, s 112.8, vérifications 8/10, rien ouvert
t1-todo-due treatment-1: score 4.34, tokens 123893, s 104.1, vérifications 8/10, ouvert writing-plans
t1-todo-due treatment-2: score 4.21, tokens 99712, s 99.6, vérifications 8/10, ouvert writing-plans
t2-csv-export control-1: score 1.71, tokens 85021, s 70.6, vérifications 4/10, rien ouvert
t2-csv-export control-2: score 1.71, tokens 84700, s 64.8, vérifications 4/10, rien ouvert
t2-csv-export oneliner-1: score 4.47, tokens 129967, s 119.6, vérifications 9/10, rien ouvert

18 exécutions, 3 artefacts

Exemple de sortie

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]

Voir Pro