command-center/agent/managed-skills/correct-stale-todo-before-next-turn/SKILL.md

name, description

name	description
correct-stale-todo-before-next-turn	Recover from marking a todo done on an inferred outcome instead of the verified one: rm the wrong entry, re-append with the true state, and state the correction before continuing.

When this applies

You reported a task as finished (or told the user an outcome) from the expected result of a script or plan, while the evidence you had already fetched in the same turn says otherwise. Common shape: a chain script documents rm -f FILE "on success", you read the docs, announce the file gone — and the same output also contains ls -l FILE (file present) plus the gate line ... kept (recordings incomplete).

Never let the script's intent outrank the captured output. An error you noticed yourself is fixed mechanically, not narrated later: the tool record and the transcript are both verifiable, so a wrong done is corrected on the next turn, in the same message as the next real action.

Procedure

1. Re-read your own claim against the evidence you already have (the exact ls -l, df, log tail line, rc file). Quote the contradicting line to yourself before deciding.
2. todo op:rm task:<the wrong entry, exact string> — do not re-append over a done item, and do not edit it in place with a new phase.
3. todo op:append the same work with its true state in the text, so the list itself carries the reason: Purge X (still on disk: the chain's gate kept it because <evidence>; <script> removes it when <condition>).
4. State the correction in one line to the user, naming the evidence that was already in your own message. Do not restate the whole prior turn and do not re-explain the plan.
5. Only then continue with the next real action — pair the correction with a tool call, never with a bare message.

Traps this prevents

• A done item silently becomes the record of an action nobody took; the next agent trusts the list instead of the host.
• "Documented behaviour" substituted for "observed behaviour": the script's comment says what happens on success, not whether success happened. Read the gate line, the rc file, or the ls before claiming the effect.
• Stacking the next mistake on top: a purge or follow-up step launched because the predecessor was believed complete.