
Wizard
- 89k installs
- 192k repo stars
- Updated July 27, 2026
- mattpocock/skills
wizard is a Claude Code skill that generates an interactive bash script walking a human through a manual procedure - opening URLs, capturing values, and writing .env files and GitHub secrets.
About
wizard generates an interactive bash script that walks a human step by step through a manual procedure such as third-party service setup, a one-off migration, or an A-to-B state transition. The generated script opens each URL, says exactly what to click and copy, captures values with hidden entry for secrets, writes them to .env files and GitHub Actions secrets, confirms at every stage, and shows how much is left. The skill follows a 4-step process: scope the procedure from the repo (.env files, README, and every secrets.* reference in CI workflows), map each stage's exact UI journey without inventing steps, author one stage per step on top of the bundled template.sh library (never hand-editing the library itself), then verify with bash -n and shellcheck and trace values statically rather than running it. Wizards are ephemeral by default, committed only when the user wants a repeatable setup path in the repo. Developers reach for it when a setup or migration is tedious to do by hand and tedious to re-explain to an AI every time.
- Bundled template.sh solves the UX: progress with time remaining, confirmation gates, cross-platform URL opening (includi
- 4-step process: scope the procedure from the repo, map each stage's exact UI journey, author stages on the template, ver
- Scoping reads .env.example, README, docker-compose, and every secrets.*/vars.* reference in .github/workflows before ask
- Never invents UI steps: where the current dashboard path is unknown, it asks the user or checks the docs
- Verification is static: bash -n, shellcheck, and tracing every captured value to where it lands - never running the wiza
Wizard by the numbers
- 89,005 all-time installs (skills.sh)
- +24,279 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #6 of 560 CLI & Terminal skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
wizard capabilities & compatibility
- Use cases
- devops · ci cd · documentation
- Runs
- Runs locally
- Pricing
- Free
What wizard says it does
A **wizard** is a bash script that walks a human, step by step, through a manual procedure that's tedious to do by hand and tedious to re-explain to an AI every time.
Your job is only to scope the procedure and author its stages.
Don't run it end-to-end yourself — it opens browsers and blocks on human input.
npx skills add https://github.com/mattpocock/skills --skill wizardAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 89k |
|---|---|
| repo stars | ★ 192k |
| Security audit | 3 / 3 scanners passed |
| Last updated | July 27, 2026 |
| Repository | mattpocock/skills ↗ |
How do you make a tedious manual procedure - third-party setup, env and secret configuration, a one-off migration - fast, safe, and repeatable without re-explaining it to an AI every time?
Generate an interactive bash wizard that walks a human through third-party setup or a one-off migration, capturing values into .env files and GitHub Actions secrets.
Who is it for?
Developers who repeatedly walk themselves or teammates through multi-dashboard setup (API keys, .env values, CI secrets) or a delicate one-off migration and want a guided, confirm-at-every-step script.
Skip if: Skip it for procedures that can be fully automated with no human in the loop, or one-liners not worth a staged script; wizards exist precisely because a human must click, copy, and confirm.
When should I use this skill?
Invoke when a project needs third-party service setup, env/secret provisioning, a one-off migration, or any A-to-B state transition that a human must perform manually. User-triggered; model invocation is disabled.
What you get
An executable, syntax-checked bash wizard at a scratch or scripts/ path that opens each URL, captures every value, and writes .env entries and GitHub secrets.
- Executable bash wizard script authored on template.sh
- Populated .env entries and GitHub Actions secrets after the human runs it
By the numbers
- 4-step authoring process: scope the procedure, map each stage's journey, author the wizard, verify and hand off
Files
Wizard
A wizard is a bash script that walks a human, step by step, through a manual procedure that's tedious to do by hand and tedious to re-explain to an AI every time. It opens each URL, says exactly what to click and copy, captures the values, writes them where they belong (.env, GitHub secrets), confirms at every stage, and shows how much is left. It might configure third-party services, run a one-off migration, or move the project from one state to another.
The delightful UX is already solved by template.sh — progress with time-remaining, confirmation gates, cross-platform URL opening (including WSL), hidden secret entry, idempotent .env upserts, gh secret/gh variable writes, and a closing summary. Your job is only to scope the procedure and author its stages. The library above the STAGES marker is identical in every wizard; that consistency is the point — never hand-edit it.
A wizard is ephemeral by default — built for one run, saved to a scratch or scripts/ path, deleted when the job's done. Commit it only when the user wants a repeatable setup path that should live in the repo.
Process
1. Scope the procedure
Work out every manual step the human must take and every value that gets captured along the way. Read the repo first — don't ask cold:
- For setup:
.env,.env.example,.env.*,README,docker-compose*, framework config, and.github/workflows/*(everysecrets.*/vars.*reference is a value the wizard must produce). - For a migration or transition: the current state, the target state, and the irreversible actions between them.
Then show the user the ordered list of stages and the values each produces, and confirm — they may add, drop, or reorder.
Done when: every stage is named in order, and for each captured value you know (a) where the human gets it, (b) where it's written (.env, a GitHub secret, both, or nowhere — some stages are pure actions), and (c) whether it's secret (hidden entry) or public.
2. Map each stage's journey
For each stage, write the precise path a human follows: which URL to open, what to do there, where a value is shown, which variable it fills — e.g. "Dashboard → Developers → API keys → Reveal test key → copy". Where you don't actually know the current UI or the exact command, say so and ask the user or check the docs — never invent steps that may not exist.
Done when: every stage traces to concrete instructions a stranger could follow.
3. Author the wizard
Copy template.sh to the target path. Replace the example stage with one stage per step, in dependency order. Use the library helpers — stage, say/step, open_url, ask/ask_secret, write_env, set_secret/set_var, pause/confirm — and set TOTAL_STAGES and TOTAL_MINUTES to honest estimates (this drives the time-remaining display).
Hold the bar the template sets: open the URL before asking for its value, use ask_secret for anything secret, write_env every persisted value, set_secret only the values CI actually needs, and confirm before any irreversible action. Each stage clears the screen so only the current step is visible — keep a stage to one focused task so nothing the human needs scrolls away. Don't touch the library above the marker.
4. Verify and hand off
bash -n <script>; runshellcheckif available.chmod +x <script>.- Don't run it end-to-end yourself — it opens browsers and blocks on human input. Trace it statically instead: every value from step 1 is captured and lands where step 1 said, and every
set_secretname exactly matches asecrets.*reference in CI. - Tell the user how to run it. If it's a repeatable setup path, commit it and link it from the README so the next person runs the script instead of asking an AI.
#!/usr/bin/env bash
#
# A wizard — walks a human through a manual procedure step by step.
# Generated by the /wizard skill.
#
# Everything above the "STAGES" marker is the wizard library: do not hand-edit
# it. Author the per-step stages below the marker.
set -euo pipefail
# ──────────────────────────────────────────────────────────────────────────
# Wizard library — delightful, consistent UX. Identical across every wizard.
# ──────────────────────────────────────────────────────────────────────────
if [[ -t 1 ]] && command -v tput >/dev/null 2>&1 && [[ "$(tput colors 2>/dev/null || echo 0)" -ge 8 ]]; then
BOLD=$(tput bold); DIM=$(tput dim); RESET=$(tput sgr0)
BLUE=$(tput setaf 4); GREEN=$(tput setaf 2); YELLOW=$(tput setaf 3); RED=$(tput setaf 1)
else
BOLD=""; DIM=""; RESET=""; BLUE=""; GREEN=""; YELLOW=""; RED=""
fi
# Author sets these two at the top of the stages section.
TOTAL_STAGES=0
TOTAL_MINUTES=0
_STAGE_INDEX=0
_MINUTES_ELAPSED=0
ENV_FILE="${ENV_FILE:-.env}"
WRITTEN_ENV=() # KEYs written to ENV_FILE this run
WRITTEN_SECRET=() # secret NAMEs set this run
SKIPPED=() # things we couldn't do (e.g. gh missing)
# _clear — wipe the terminal so only the current step is on screen. No-op when
# output isn't a terminal, so piped logs stay readable.
_clear() {
[[ -t 1 ]] || return 0
if command -v tput >/dev/null 2>&1; then tput clear; else printf '\033[2J\033[3J\033[H'; fi
}
# banner "Title" — opening frame: what this wizard does and how long it takes.
banner() {
_clear
printf '\n%s%s %s%s\n' "$BOLD" "$BLUE" "$1" "$RESET"
printf '%s %s stages · about %s minutes%s\n\n' \
"$DIM" "$TOTAL_STAGES" "$TOTAL_MINUTES" "$RESET"
printf '%s You drive the browser; this wizard tells you exactly what to do and\n' "$DIM"
printf ' captures the values you copy back. Stop any time with Ctrl-C and re-run\n'
printf ' later — it remembers values already saved.%s\n' "$RESET"
pause "Ready to start?"
}
# stage "Name" <minutes> — clear the screen, then announce a stage and show
# progress + time remaining. Clearing keeps only the current step on screen.
stage() {
_clear
_STAGE_INDEX=$((_STAGE_INDEX + 1))
local remaining=$((TOTAL_MINUTES - _MINUTES_ELAPSED))
(( remaining < 0 )) && remaining=0
_MINUTES_ELAPSED=$((_MINUTES_ELAPSED + ${2:-0}))
printf '\n%s%s▸ Stage %s/%s · %s%s %s(~%s min left)%s\n' \
"$BOLD" "$BLUE" "$_STAGE_INDEX" "$TOTAL_STAGES" "$1" "$RESET" "$DIM" "$remaining" "$RESET"
}
# say "..." — a plain instruction line.
say() { printf ' %s\n' "$1"; }
# step "..." — a numbered-feeling action the human takes in the browser.
step() { printf ' %s•%s %s\n' "$BLUE" "$RESET" "$1"; }
note() { printf ' %s%s%s\n' "$DIM" "$1" "$RESET"; }
warn() { printf ' %s⚠ %s%s\n' "$YELLOW" "$1" "$RESET"; }
# open_url URL — open in the human's browser, cross-platform incl. WSL.
open_url() {
local url="$1"
printf ' %s↗ opening%s %s\n' "$GREEN" "$RESET" "$url"
{ if command -v wslview >/dev/null 2>&1; then wslview "$url"
elif command -v explorer.exe >/dev/null 2>&1; then explorer.exe "$url"
elif command -v xdg-open >/dev/null 2>&1; then xdg-open "$url"
elif command -v open >/dev/null 2>&1; then open "$url"
else warn "couldn't open a browser — visit it manually: $url"; fi
} >/dev/null 2>&1 || warn "couldn't open a browser — visit it manually: $url"
}
# pause "msg" — wait for the human to confirm they've done the manual part.
pause() {
printf ' %s%s%s ' "$DIM" "${1:-Press Enter to continue}" "$RESET"
read -r _ || true
}
# confirm "question" — y/N gate; returns success on yes.
confirm() {
local reply=""
printf ' %s? %s [y/N] ' "$YELLOW" "$1"
read -r reply || true
[[ "$reply" =~ ^[Yy] ]]
}
# _existing KEY — current value of KEY in ENV_FILE, if any.
_existing() {
[[ -f "$ENV_FILE" ]] || return 1
local line; line=$(grep -E "^${1}=" "$ENV_FILE" | tail -n1) || return 1
printf '%s' "${line#*=}"
}
# ask KEY "Prompt" — read a value into $KEY. Offers the existing .env value as
# a default on re-runs (Enter keeps it). Visible input (non-secret).
ask() {
local key="$1" prompt="$2" current input
current=$(_existing "$key" || true)
if [[ -n "$current" ]]; then
printf ' %s%s%s %s[Enter keeps current]%s ' "$BOLD" "$prompt" "$RESET" "$DIM" "$RESET"
else
printf ' %s%s%s ' "$BOLD" "$prompt" "$RESET"
fi
read -r input || true
[[ -z "$input" && -n "$current" ]] && input="$current"
printf -v "$key" '%s' "$input"
}
# ask_secret KEY "Prompt" — like ask, but input is hidden.
ask_secret() {
local key="$1" prompt="$2" current input
current=$(_existing "$key" || true)
if [[ -n "$current" ]]; then
printf ' %s%s%s %s[Enter keeps current]%s ' "$BOLD" "$prompt" "$RESET" "$DIM" "$RESET"
else
printf ' %s%s%s ' "$BOLD" "$prompt" "$RESET"
fi
read -rs input || true
printf '\n'
[[ -z "$input" && -n "$current" ]] && input="$current"
printf -v "$key" '%s' "$input"
}
# write_env KEY VALUE — upsert KEY=VALUE into ENV_FILE (creates it; replaces
# any existing line). Idempotent.
write_env() {
local key="$1" value="$2" tmp
touch "$ENV_FILE"
tmp=$(mktemp)
grep -vE "^${key}=" "$ENV_FILE" > "$tmp" || true
printf '%s=%s\n' "$key" "$value" >> "$tmp"
mv "$tmp" "$ENV_FILE"
WRITTEN_ENV+=("$key")
printf ' %s✓ wrote%s %s → %s\n' "$GREEN" "$RESET" "$key" "$ENV_FILE"
}
# set_secret NAME VALUE — set a GitHub Actions repo secret via gh. Falls back
# to a warning (and records it) if gh is unavailable or unauthenticated.
set_secret() {
local name="$1" value="$2"
if command -v gh >/dev/null 2>&1 && gh auth status >/dev/null 2>&1; then
if printf '%s' "$value" | gh secret set "$name" >/dev/null 2>&1; then
WRITTEN_SECRET+=("$name")
printf ' %s✓ set%s GitHub secret %s\n' "$GREEN" "$RESET" "$name"
return
fi
fi
SKIPPED+=("GitHub secret $name (set it manually: gh secret set $name)")
warn "skipped GitHub secret $name — gh not ready; set it later"
}
# set_var NAME VALUE — set a GitHub Actions repo variable (non-secret).
set_var() {
local name="$1" value="$2"
if command -v gh >/dev/null 2>&1 && gh auth status >/dev/null 2>&1; then
if gh variable set "$name" --body "$value" >/dev/null 2>&1; then
printf ' %s✓ set%s GitHub variable %s\n' "$GREEN" "$RESET" "$name"
return
fi
fi
SKIPPED+=("GitHub variable $name")
warn "skipped GitHub variable $name — gh not ready; set it later"
}
# finish — clear, then a closing summary of everything configured.
finish() {
_clear
printf '\n%s%s ✓ Setup complete%s\n' "$BOLD" "$GREEN" "$RESET"
(( ${#WRITTEN_ENV[@]} )) && note "wrote ${#WRITTEN_ENV[@]} value(s) to $ENV_FILE: ${WRITTEN_ENV[*]}"
(( ${#WRITTEN_SECRET[@]} )) && note "set ${#WRITTEN_SECRET[@]} GitHub secret(s): ${WRITTEN_SECRET[*]}"
if (( ${#SKIPPED[@]} )); then
printf '\n'; warn "still to do by hand:"
for s in "${SKIPPED[@]}"; do note " - $s"; done
fi
printf '\n'
}
# ──────────────────────────────────────────────────────────────────────────
# STAGES — author this section. One stage() per step the human takes.
# Replace the example below. Set the two totals to match the stages you write.
# ──────────────────────────────────────────────────────────────────────────
TOTAL_STAGES=1
TOTAL_MINUTES=5
banner "Stripe setup"
# ── Example stage: replace with your real steps ───────────────────────────
stage "Stripe — API keys" 5
say "We'll grab your Stripe test keys and store them for local dev + CI."
open_url "https://dashboard.stripe.com/test/apikeys"
step "On the API keys page, copy the Publishable key (starts pk_test_)."
ask STRIPE_PUBLISHABLE_KEY "Paste the publishable key:"
step "Click 'Reveal test key' on the Secret key row, then copy it."
ask_secret STRIPE_SECRET_KEY "Paste the secret key:"
write_env STRIPE_PUBLISHABLE_KEY "$STRIPE_PUBLISHABLE_KEY"
write_env STRIPE_SECRET_KEY "$STRIPE_SECRET_KEY"
set_secret STRIPE_SECRET_KEY "$STRIPE_SECRET_KEY" # CI needs this one
# ──────────────────────────────────────────────────────────────────────────
finish
Related skills
How it compares
Use instead of ad-hoc README setup instructions or dictating dashboard steps in chat; the generated script encodes the whole journey with confirmation gates and idempotent writes.
FAQ
What does the wizard skill generate?
A bash script built on a bundled template.sh library that guides a human through a manual procedure stage by stage: it opens each URL, says what to click and copy, captures values (hidden entry for secrets), writes .env files and GitHub secrets via gh, and confirms each step.
When should I use wizard instead of automating the setup directly?
When the procedure requires a human in browser dashboards - creating API keys, third-party accounts, irreversible migrations. The wizard makes the tedious manual path fast and repeatable instead of re-explaining it to an AI every time.
Does the skill run the generated wizard itself?
No. It verifies statically with bash -n and shellcheck and traces that every captured value lands where the scoping said, and that every set_secret name matches a secrets.* reference in CI. Running it end-to-end is left to the human, since it opens browsers and blocks on input.
Is Wizard safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.