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

This skill is a standing session posture over how future work is delivered, not a re-anchor/audit/correct loop. It audits 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. Never grow the count silently.

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: