Mathieu Benoit
4f85a4f225
Ajouter une entrée commence par des décisions qu'aucun gabarit n'imposait : quel menu parent, motif A ou B, quoi faire en cas d'échec, ce qui est détruit, ce qui touche à une donnée client. La commande les demande avant d'écrire, planifie avec superpowers quand le plugin est là, et pose sa spécification dans tasks/, non versionné. Son frontmatter fixe l'effort à max, seule valeur de l'énumération ; ultracode est un épinglage de session que l'utilisateur tape, non un réglage de gabarit. Vérifié : les deux gabarits déployés dans un HOME jetable, relus « à jour » par l'écran de contexte. --- EN --- Adding an entry starts with decisions no template forced: which parent menu, pattern A or B, what to do on failure, what gets destroyed, what touches customer data. The command asks them before writing, plans with superpowers when the plugin is there, and lays its specification in tasks/, which is not versioned. Its frontmatter sets effort to max, the only value in the enumeration; ultracode is a session pin the user types, not a template setting. Checked: both templates deployed into a throwaway HOME, read back as up to date by the context screen. Assisted-by: Claude Opus 5
5.2 KiB
| name | description | disable-model-invocation | effort | allowed-tools | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| todo_plan_max | Plan a todo.py command at maximum effort: questions first, superpowers when installed, then the specification /todo_add_command implements. | true | max |
|
Context
- Existing menus: !
grep -n "def prompt_execute" script/todo/todo.py - Menu sections in todo.json: !
python3 -c "import json;print(*json.load(open('script/todo/todo.json')),sep='\n')" - Installed plugins: !
claude plugin list - Last commits on the menu: !
git log --oneline -8 -- script/todo/
Task
Plan ONE command for the script/todo/todo.py menu, at the effort tier this
file pins. Planning is the whole job: this command produces a specification
and writes no menu code. /todo_add_command implements what comes out.
The effort tier
The effort: max above applies to this invocation and to it alone.
Two other levers exist, and they are the user's to pull, not yours. /effort ultracode PINS ultracode for the rest of the session — every substantive task
then goes through the Workflow tool, and an interactive terminal releases the
pin with /effort high. The bare keyword ultracode in a typed prompt opts in
that ONE turn. Say which of the two would serve, and let the user type it;
never claim a pin that is not shown as on.
Invoking this command is itself an explicit opt-in to multi-agent orchestration, so the Workflow tool is available here without any further ask. Reach for it when the plan genuinely has independent dimensions to explore in parallel — several candidate designs, or a survey of how the existing menus already solve the problem. A single obvious entry does not need one, and a workflow spawned for it burns tokens the user is paying for.
1. Ask before planning
Ask with the question tool, never as prose the user has to answer in a paragraph. Ask ONLY what changes the plan — a question whose every answer leads to the same design is noise, and four is the ceiling per round.
What usually forks the design, in this repository:
- Which menu. Git, Code, Database, Config, Network, Process, Test, Update, Run, Doc, Security — the parent decides who finds the entry.
- Pattern A or B. A hard-coded method when the entry prompts, branches or
reads state; a
todo.jsonentry when it is one bash command or one make target. Guessing wrong costs a rewrite, not an edit. - What it does on failure. An entry that stops at the first error, one that carries on and reports at the end, and one that asks before each step are three different features wearing one name.
- Whether it destroys anything. A command that drops a database, deletes a VM or overwrites a file needs a confirmation prompt and a name typed in full; the repository already writes them that way.
- Whether it touches customer data. Only
private/may hold it. If the answer is yes, the plan says where the data lives and what never leaves it.
Take the answers as given. When one contradicts what the code does, say so in a sentence and plan what was asked for.
2. Plan with superpowers when it is installed
Read the context block above. When superpowers appears among the installed
plugins, use it: its brainstorming skill for the design, its subagent-driven
development and code-review skills for the shape of the work, its systematic
debugging skill when the entry wraps something that already misbehaves.
When it is absent, say so in one line and plan without it — plan mode, the
repository's own conventions, and the menus already written. Do not install it
from here: TODO › Execute › GPT code › Plugins Claude Code carries the
ERPLibre list and the install is the user's decision, not a side effect of
asking for a plan.
3. Read what already exists
A menu of this size has almost always solved the problem next door. Before
designing anything, find the two or three closest entries and read them —
grep -n "def prompt_execute" script/todo/todo.py for the parents, then the
private methods under them. Copy the shape that is there: the same
confirmation prompt, the same t() keys, the same way of running a command.
An entry that behaves like its neighbours needs no explaining.
4. What the plan contains
Write it to tasks/todo.md — tasks/ is not versioned, which is why the
convention sends working material there — as checkable items, and state:
- the parent menu and the position of the entry in it;
- pattern A or B, and why the other was rejected;
- the exact i18n keys, with their French and English text, both mandatory;
- for pattern A, the method name and its signature; for pattern B, the
todo.jsonsection and the command line; - what the entry prints on success and on failure, and every confirmation it asks for;
- how to verify it: the syntax checks, the unit test to add under
test/, and what to run by hand. A real machine goes tolong_test/, never totest/, which stays runnable in seconds.
Then stop and hand it over. The plan is checked before code is written — that
is the whole point of planning at this tier. When it is approved,
/todo_add_command implements it.