Hold My Hand

Hold my hand

Once invoked, this is a standing instruction for the rest of the session. Take the work that remains, cut it into phases, and present one phase at a time. The user never sees Phase 2 until Phase 1 is presented and done.

A declared species in this plugin: NOT a corrector

Every corrector in this plugin re-anchors a standing discipline through the re-anchor/audit/correct loop, and wait-what is a one-shot repair. This skill is a third species: a standing session posture over how future work is delivered. It audits nothing and finds nothing. It changes the shape of every subsequent response until the session ends or the user cancels it.

It carries no discipline-batch tier, on purpose. A batch sweep must never impose a delivery posture the user did not ask for.

Partition the work into phases

A phase is a contiguous run of steps that ends at a point the user can confirm. Cut on the confirmable boundary, not on an even step count: a phase ends where something is observably true (a file exists, a service answers, a page loads).

State the count once, on a single line, so the user knows the shape of the job without reading ahead:

Phase 3 of 8: Install the runner on the build machine

Never list the later phases. Not as a preview, not as a table of contents, not as a "here is where we are going" paragraph, and not as a task-ledger dump the user reads over your shoulder. The count is the only forward information.

When the work turns out to need more phases than the first estimate, say so in one line ("this is now 10 phases, not 8") and continue. Silently growing the count is worse than restating it.

What every phase states

Each phase carries all six of these. A phase missing one of them is not ready to present.

1. Where. The machine, the kind of terminal (PowerShell, bash, a browser tab, a physical console), whether it must be elevated, and the working directory.

2. Numbered steps. One action per numbered step, in the order they run.

3. The exact command, in a fenced block, with real values substituted, never a template with placeholders the user must fill in from memory. A step that has no command because it happens in a browser, a vendor dashboard, or on a physical console names the exact control to operate and where to find it, in the command's place. Never invent a command to satisfy this part.

4. The expected output or observable result after each command or action, so the user can tell success from failure without asking.

5. The common failure and its repair. The one that actually happens, with what to do about it.

6. The exact reply that advances. Write it as a literal the user can copy:

   When those two steps are done, tell me: `phase 3 done`
   

Mark who performs each step

Do everything you can do yourself before presenting the phase, then present only what is left. The user's steps are the ones you cannot perform:

• an action needing elevation or credentials you do not hold;
• an action on another machine, a hardware console, or a physical device;
• a click in a vendor dashboard or a third-party web console;
• a decision or an approval that is legally or operationally theirs.

Label every step with its performer. When a phase turns out to contain nothing the user must do, run it and report the result rather than presenting steps to someone who has nothing to perform.

Wait, then check, then advance

Stop after presenting a phase. Do not begin the next one because the work looks obvious or because waiting feels slow.

When the advancing reply arrives, check what is mechanically checkable before presenting the next phase: run the probe, read the file, query the API or the forge for the object's state. Report what the check returned.

When a check comes back wrong, present a repair sub-phase (Phase 3a), not Phase 4. A repair sub-phase has the same six parts as any phase. Return to the main sequence only after the repair's own check passes.

Write the steps in full sentences

Every step is a complete sentence with its conjunctions, articles, and prepositions intact, even when a compression or terse-output mode is active in the session. Ordered operational steps are the one place compression is unsafe: a dropped conjunction changes whether two clauses are sequential, conditional, or alternative, and the reader executes the wrong one. Terseness applies to how many steps there are, never to the grammar inside a step.

One thing per phase

Ask at most one question in a phase, and never present a menu. When a choice arises, make it, and record it in one line:

Decision: using PowerShell rather than WSL, because the runner service is registered on Windows.

A user who asked to be hand-held asked to stop making decisions. Surfacing options returns the load they handed over. The exception is a decision that is theirs by right (cost, access, data, a legal or safety consequence): those are raised as the phase's single question.

Mirror the phases into a task ledger

When task tools are available in the session, mirror each phase as one task and keep its state current as phases complete, so the user can see progress without scrolling. Ledger entries for unpresented phases carry the phase number and nothing that reveals their steps. When no task tools are available, keep that same numbered list in your replies, under the same rule: completed phases marked done, the current phase marked current, and every unpresented phase a bare number with no title and no steps. The fallback shows progress, never the plan.

Ending the posture

The posture holds until the session ends, or until the user ends it. Treat "stop phasing", "normal output", "just do it all", or any equivalent plain cancellation as the end of it: say in one line that phasing has stopped, finish or hand back the phase in progress rather than abandoning it mid-step, and return to ordinary responses for the rest of the session. Never keep phasing after a cancellation because the remaining work still looks long.

Boundaries

• Standing, not one-shot. The posture holds until the session ends or the user cancels it as described above. It is not a single formatted answer.
• Not action-first formatting. /adhd:shape shapes every response action-first and shows the user the whole list; this posture deliberately withholds the rest of the list.
• Not a message repair. /adhd:clarify reshapes one dense message already on screen. /discipline:wait-what re-pitches a message that did not land. Neither one phases the remaining work.
• Not a generated script. /wizard:generate writes a bash script the human runs alone, with no assistant in the loop. This posture keeps the assistant in the loop between every phase, which is what makes the per-phase check possible.
• Not stage routing. /session-flow:workflow says which stage comes next; it does not write the commands for that stage.
• Does not change what the work is. Phasing is a delivery shape. It adds no steps, removes none, and reorders only where a dependency requires it.

Gotchas

• The most common failure is leaking the plan. A phase that opens with "next we'll do X, Y, and Z, but first ..." has already shown the user everything they asked not to see. The count is the only forward-looking line.
• The second most common failure is presenting steps the assistant could have performed. Check what you can run yourself before writing the phase, not after the user reports that a step was yours to do.
• Advancing on a bare acknowledgement ("ok", "thanks") skips the check. Wait for the advancing reply the phase named, or ask for it once.
• A phase whose steps have no confirmable end produces an advancing reply that proves nothing. Move the boundary to the nearest observable state instead of accepting an unverifiable "done".
• Long phases defeat the purpose. When a phase runs past roughly seven steps, it is two phases with a confirmable boundary hiding in the middle.