Dormammu

Dormammu Protocol — bargain until it is actually correct

IRON RULE — read this first

When /dormammu is invoked, this protocol is an IRON RULE for the task and must be followed at all costs, no matter what. You do not get to skip the loop, cut it short, or declare the work done to save time or effort. No premature "done". No unverified claims. No "this probably works." You keep bargaining — implement, attack your own work, revert, retry — until the result is proven correct by actually running the verification. Quitting early, hand-waving, or calling a first draft final is forbidden.

This binds how rigorously and relentlessly you work. It strengthens correctness, safety, and honesty — it never licenses overriding them. The only honest way to stop short is the guardrails below: if you are genuinely blocked by something only the user can resolve, or the request itself is flawed, you say so plainly. You never fake completion.

This is meant to be backed by /goal, but you do not run /goal yourself. /goal is a user-only UI command — the Skill tool cannot invoke it, and trying to will just error. So in Phase 1 you compose the exact /goal command and hand it to the user to paste. If they paste it, /goal arms a session Stop hook: a wall the harness puts up that refuses to let the turn end until the condition holds, and clears the moment it does — "do not stop early" stops being willpower and becomes a wall. If they do not paste it, you still follow this protocol to the letter; the rule binds you either way. Either way, never call /goal via the Skill tool. Dormammu and /goal are the same idea from two directions: /goal can make the loop impossible to escape, and this protocol makes the loop productive whether or not the wall is up.

A disciplined loop for serious work. The point is to refuse premature "done": keep auditing and reverting until the solution genuinely survives scrutiny and verification, not just until a first draft compiles or a checklist is ticked.

Honest scope. This does not suspend judgement or run forever. It is a structured habit: define the target, build, attack your own work, fix or revert, and only stop on evidence. If the loop is genuinely converged (or truly blocked and needs the user), say so plainly instead of looping for its own sake.

Forbidden (the whole reason this skill exists)

• No static checklists. Finishing a to-do list is not proof the goal is met.
• No premature closure. A first draft that "looks right" is not final.
• No blind assumptions. Do not assume your logic, queries, or integrations are correct, optimal, or bug-free until you have checked.

The loop

Phase 1 — Define the absolute end-state, then hand the user a /goal

First, state what a 100% correct, robust, optimized outcome actually looks like — the final functional state and its hard requirements (correctness, edge cases, complexity targets, integration contracts). Not the steps; the target.

Then compress that target into a single, concrete, externally checkable success condition and give the user a ready-to-paste /goal command for it. Do not run it yourself and do not call it via the Skill tool — /goal is a user-only UI command and attempting to invoke it just errors. Present it for the user to copy, exactly like this:

/goal <the verifiable success condition>

Tell the user in one line that pasting it locks the session until the work is genuinely done, and that it is optional — you will proceed either way.

Then keep going immediately. Do not wait for them to paste it — start Phase 2 now. If they paste it, the harness holds the turn open until the condition is true and clears it for them. If they do not, you hold yourself to the same bar. Phase 1 is done once you have stated the end-state and handed over the /goal line.

Make the condition objective and testable, not vague — phrase it as something a Stop hook can actually judge as true or false. Good: "pytest tests/ passes with 0 failures AND the new endpoint returns 200 for the empty-list case." Bad: "the code is good." This arms the Stop hook: from here on the harness will not let the turn end until that condition holds, and it auto-clears the instant it does. Phase 1 is not finished until the /goal is set.

If the user already set a /goal when invoking dormammu, adopt it as the target and sharpen it into a testable condition rather than registering a competing one.

Phase 2 — Implement (the first bargain)

Write your best real solution. Pay deliberate attention to time/space complexity, architecture, state management, and the integration points / API contracts.

Phase 3 — Critical fidelity check (self-audit)

Stop and attack your own output against the Phase 1 end-state. Mentally (and where possible, actually) execute it:

• What inputs break it? Empty, huge, malformed, concurrent, adversarial?
• Where does it fail under load or at boundaries (off-by-one, nulls, races)?
• Are the API/data contracts solid? Any logical flaw in the data flow?
• Is there a simpler or more efficient form that is still correct? Prefer real evidence over assertion: run the tests, run the code, check the output. (Pair with the superpowers:verification-before-completion and systematic-debugging skills when available.)

Phase 4 — Temporal revert (the bargain line — fires constantly, not rarely)

The instant you backtrack in ANY way, the very first thing you output — before any other text, code, or tool call — MUST be this exact line, verbatim, on its own line:

Dormammu, I've come to bargain.

Then, on the next line, one sentence on why the previous attempt failed. Then change approach and loop back to Phase 2.

"Backtrack" is broad. Read this list — if ANY of these happen, it counts, and the line fires first:

• a test, build, lint, type-check, or any verification fails and you are about to try something different;
• you undo, rewrite, or replace an edit you just made;
• you change approach / strategy for something you already attempted;
• an assumption turned out wrong (an API, a type, a path, a value, how something behaves) and you adjust because of it;
• you hit an error or unexpected output and pivot;
• you catch a flaw, edge case, or inefficiency in your own work and redo that part;
• you abandon a half-built path and start that piece over.

Inline "oh, that failed, let me fix it" corrections count too — that IS a backtrack. Do not silently patch over a failure: print the line first, every single time, no matter how small the course-correction. Fixing without the line is the one thing this skill forbids. Forward progress (writing new code that has not failed yet) does not need the line — only moments where something you did is being walked back.

When in doubt about whether something counts, print the line. Over-printing is fine; silent backtracking is not.

Phase 5 — Break the loop (only when the work is actually verified)

You do not get to declare "done" on vibes. The exit test is the Phase 1 success condition, proven true by actually running the verification and confirming it passes. Only then present the final solution and state briefly what you verified and how.

If the user pasted the /goal, the harness makes this literal: the Stop hook holds your turn open until the condition is objectively true and then auto-clears, so the goal clearing is your green light — if you think you are done but it has not cleared, you are not done. If no /goal was armed, hold yourself to the exact same bar anyway; the standard does not drop just because the wall is not up.

Convergence guardrails (so the loop stays honest)

• If two successive attempts fail the same way, step back and question the Phase 1 framing — the requirement or approach may be wrong, not just the code.
• If you are genuinely blocked by something only the user can resolve (a decision, access, an external dependency), stop the loop and say exactly what you need.
• Don't manufacture flaws to keep looping. "Converged" is a valid, honest end — back it with the verification you ran.
• The /goal escape hatch is for the user, not for you. If the work turns out to be genuinely impossible, the requirement is wrong, or you are truly blocked, surface that plainly and let the user decide to run /goal clear. You never clear the goal yourself to escape the loop, and you never tell the user to clear a goal you simply succeeded at — a met goal auto-clears on its own.