Crank Wizard

A wizard is a small Go program that walks a human, step by step, through a procedure that's tedious to do by hand and tedious to re-explain every time: provisioning infrastructure, capturing credentials, walking a third-party dashboard, running a one-off cutover. The human does the steps only they can do; the wizard opens the pages, hands over the values to paste, verifies results with real commands, and saves progress so a quit at step 4 resumes at step 4.

A wizard is committed and repeatable: it lives at wizards/<name>/ in the target repo, a Go module of its own, and runs on macOS and Windows from the repo root with go -C wizards/<name> run .. At startup the runtime moves to the nearest ancestor holding .git, so the checks it shells out, the env file it writes, and its saved progress all land at the repo root however it was launched. Every wizard is two halves: runtime.go, the immutable library, byte-identical in every wizard, and steps.go, the only file you author. template/steps.go is the exemplar: a complete demo wizard that exercises every helper.

Process

1. Grill briefly

The task description says what the wizard walks through; your questions exist only to catch edge cases and pin the full behavior. The blind spots, asked only when the description leaves them open:

• Audience: who runs this, on which OSes? Both macOS and Windows must work; a non-portable shell command branches on runtime.GOOS.
• Lifecycle: repeatable and committed (the default), or genuinely one-run?
• Abort and resume: a step re-runs from its start after a quit — flag any step where that repeat is unsafe.
• Partial completion: when a push or check fails midway, what must the human finish by hand?
• Secrets: which captured values are secret (hidden entry, kept out of saved progress), and where does each land — the env file, a CI secret, both, or nowhere?

Put the open ones to the user as one numbered round; ask one follow-up round only when an answer opens a real fork.