stepbystep

name	stepbystep
description	Convert the current session's research, summary, plan, or partially completed work into an interactive one-step-at-a-time instruction mode. Use when the user says stepbystep, sbs, step-by-step mode, asks to be walked through a process with checkpoints, or wants to test each step, give feedback, move forward, go back, regress, revise, or exit.

StepByStep

Overview

StepByStep turns accumulated context into a guided progression. The assistant acts like a session-local instructor: it gives one concrete step, waits for the user's result or feedback, evaluates the checkpoint, then advances, revises, or regresses.

This package also provides /stepbystep and /sbs command definitions where the host agent supports custom commands. Treat plain stepbystep, sbs, @stepbystep, /stepbystep, /sbs, and natural-language variants as activation phrases for this skill.

Activation

Use this skill when the user wants to:

• Turn existing research or a summary into an executable path.
• Work through a procedure one checkpoint at a time.
• Take a small test after each step before moving on.
• Give feedback, ask for correction, move to the next step, or go back.
• Resume a previous guided sequence in the same conversation.

Session Protocol

On activation:

1. Identify the working goal from the current conversation and any provided summary, research, files, or plan.
2. If the goal is ambiguous, ask one concise clarifying question. Otherwise state the goal and continue.
3. Build a private route map of the likely steps, but only expose a compact progress line and the current step unless the user asks for the full map.
4. Present exactly one step with a test/checkpoint.
5. Stop and wait for the user's result, feedback, or navigation command.

Use this response shape:

SBS <current>/<total>: <step title>
Goal: <one-line goal>
Do: <specific action for the user or assistant>
Test: <how success will be checked>
Reply with: pass, next, back, regress, revise, skip, done, or your result.

Keep each step small enough that the user can complete or evaluate it in one turn. Avoid dumping future steps unless asked.

Navigation

Interpret user replies as follows:

• pass or next: mark the checkpoint accepted and advance.
• back: return to the previous step without changing the route map unless the user asks.
• regress: move to the last known stable checkpoint and propose a repair or alternate path.
• revise: update the current step using the user's feedback and ask them to try again.
• skip: mark the step skipped, note the risk, and continue.
• done or exit: stop StepByStep mode and summarize the final state.
• Any other reply: treat it as test output or feedback; evaluate it against the checkpoint, then decide whether to pass, revise, or ask one focused question.

Evaluation Rules

• Be strict about whether the stated test passed. Do not advance on vague confirmation if concrete evidence is needed.
• When evidence is missing, ask for the smallest useful artifact: output, screenshot, error text, decision, or yes/no confirmation.
• For coding work, run or suggest the narrowest relevant verification before advancing when tools are available.
• For research or writing work, check that claims, sources, and acceptance criteria match the current goal before advancing.
• Preserve session state in the conversation. Do not create tracking files unless the user explicitly asks.

Boundaries

• Do not spawn subagents unless the user explicitly asks for multi-agent or delegated work.
• Do not execute destructive actions as a "step" unless the user has clearly requested that action.
• If the user asks to stop StepByStep mode, return to normal assistant behavior.