How do I install the Front Load Prompts skill?

Run npx skillmds@latest add beyond-all-reason/front-load-prompts in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Front Load Prompts safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Front Load Prompts?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Front Load Prompts free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Front Load Prompts?

beyond-all-reason (@beyond-all-reason) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Front Load Prompts by beyond-all-reason

Name: Front Load Prompts
Author: beyond-all-reason

Front Load Prompts

All interactive decisions in long-running setup scripts go in one batch at the top, before any work runs. Use this when adding a new prompt to `cmd_init`, `setup::init`, or any multi-minute recipe — it explains the "Step 0/N Configuration" pattern and why we don't sprinkle Y/n prompts through the steps.

File contents

Front-load prompts

setup::init does ~5 minutes of distrobox image build + ~90 minutes of repo clones + ~45 minutes of engine build. Then, on Windows, sync time. The contributor walks away during that time. Every interactive prompt belongs before the first long-running step, captured so a later step reads the answer instead of re-asking.

The Step 0 pattern

cmd_init's configuration phase (step "0/N Configuration") is a flat batch: detect what it can, ask every decision, then confirm_setup_plan rolls the lot up for one Y/n. Nothing below step 0 prompts.

The prompts are not hand-written read -rp calls in cmd_init — each decision is a self-registering module under scripts/setup/NN-<name>.sh, driven by ensure_module_by_name. That mechanism is its own convention; see the setup-module-registry skill. The rule this skill carries is the ordering: a module's prompt fires in step 0, its apply runs whenever it has to (immediately, or deferred to the end of cmd_init), but the question is always asked up front.

Running setup::init is itself the consent

confirm_setup_plan closes step 0 with a rollup — every decision the user made, plus the work ahead (repos to clone, whether the distrobox build is still pending, a sudo heads-up) — and a single Y/n. That is the one generic gate. Once the user confirms it, they have consented to the script running: no per-step "Install X? [Y/n]". If they want out, they Ctrl-C.

So any sub-tool with an interactive default needs its non-interactive flag — distrobox stop --yes, distrobox rm -f --yes, distrobox create --yes, apt install -y. A prompt that fires past step 0 is the bug.

Ask up front, act later

The load-bearing example is the symlink decision. The question ("symlink the selected components into the game dir after build?") is asked in step 0, when the user is paying attention, and persisted to .env. Step 6 ("Symlinks") just acts on the saved answer, or prints Skipping symlinks (declined at configuration step). Same shape for any "should I do X" decision: the prompt goes in step 0, the work goes wherever it has to.

Audit checklist when adding a step

Does the step have a read -rp or Y/n prompt? → it doesn't belong there. Make it a setup module (see setup-module-registry) so the prompt lands in step 0 and the answer persists to .env.
Does the step call a sub-tool with an interactive default? → add --yes / -y / --non-interactive.
Is the prompt conditional on detection that needs earlier setup (e.g. detect_game_dir)? → fine, but the prompt still goes in step 0 after the detection, not buried in a later step.

---name: front-load-promptsdescription: All interactive decisions in long-running setup scripts go in one batch at the top, before any work runs. Use this when adding a new prompt to `cmd_init`, `setup::init`, or any multi-minute recipe — it explains the "Step 0/N Configuration" pattern and why we don't sprinkle Y/n prompts through the steps.---# Front-load prompts`setup::init` does ~5 minutes of distrobox image build + ~90 minutes of repo clones + ~45 minutes of engine build. Then, on Windows, sync time. The contributor walks away during that time. **Every interactive prompt belongs before the first long-running step**, captured so a later step reads the answer instead of re-asking.## The Step 0 pattern`cmd_init`'s configuration phase (`step "0/N Configuration"`) is a flat batch: detect what it can, ask every decision, then `confirm_setup_plan` rolls the lot up for one Y/n. Nothing below step 0 prompts.The prompts are not hand-written `read -rp` calls in `cmd_init` — each decision is a self-registering module under `scripts/setup/NN-<name>.sh`, driven by `ensure_module_by_name`. That mechanism is its own convention; see the **setup-module-registry** skill. The rule *this* skill carries is the ordering: a module's prompt fires in step 0, its `apply` runs whenever it has to (immediately, or deferred to the end of `cmd_init`), but the question is always asked up front.## Running setup::init is itself the consent`confirm_setup_plan` closes step 0 with a rollup — every decision the user made, plus the work ahead (repos to clone, whether the distrobox build is still pending, a sudo heads-up) — and a single Y/n. That is the one generic gate. Once the user confirms it, **they have consented to the script running**: no per-step "Install X? [Y/n]". If they want out, they Ctrl-C.So any sub-tool with an interactive default needs its non-interactive flag — `distrobox stop --yes`, `distrobox rm -f --yes`, `distrobox create --yes`, `apt install -y`. A prompt that fires past step 0 is the bug.## Ask up front, act laterThe load-bearing example is the symlink decision. The question ("symlink the selected components into the game dir after build?") is asked in step 0, when the user is paying attention, and persisted to `.env`. Step 6 ("Symlinks") just acts on the saved answer, or prints `Skipping symlinks (declined at configuration step)`. Same shape for any "should I do X" decision: the prompt goes in step 0, the work goes wherever it has to.## Audit checklist when adding a step- Does the step have a `read -rp` or Y/n prompt? → it doesn't belong there. Make it a setup module (see **setup-module-registry**) so the prompt lands in step 0 and the answer persists to `.env`.- Does the step call a sub-tool with an interactive default? → add `--yes` / `-y` / `--non-interactive`.- Is the prompt conditional on detection that needs earlier setup (e.g. `detect_game_dir`)? → fine, but the prompt still goes in step 0 *after* the detection, not buried in a later step.

Frequently asked questions