# Anchored Install > Use this skill for checkpointed retries of substantial, multi-step shell install/setup/provisioning workflows: cache successful steps and resume after failure or interruption without repeating completed work. Trigger when the user asks for checkpoint/layer caching or resume-after-failure, names `anchored-install`, the `ai` command, or `#ai`, asks to author, edit, convert, plan, run, or debug an `#ai` manifest, or reports frequent/repeated installation failures or interruptions, especially when reruns redo completed work. Also trigger proactively when the user's task is to author a new install/setup/provisioning script whose planned side-effecting steps are costly, slow, or risky to repeat, even if caching is unstated. Initial execution of an existing vendor/third-party script, package command, or one-off installer error stays native; generic setup, idempotency, or rerun wording and a cheap or merely long/flaky script are not enough. - Skill: `openghz/anchored-install` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add openghz/anchored-install` - Raw SKILL.md: https://api.skillmd.com/api/skills/openghz/anchored-install/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: openghz (https://skillmd.com/u/openghz) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/openghz/anchored-install --- # anchored-install (`ai`) `anchored-install` runs a plain list of shell commands and **caches every step that succeeds**. When a run fails, you fix the problem and re-run — already-succeeded steps are skipped and execution **resumes from the first unfinished step**, instead of starting over from the top every time. Think Dockerfile layer caching, but for an ordinary shell script. A manifest is just a normal shell script: the caching markers are `#ai` comments, so `bash install.sh` runs the exact same file natively, with or without `ai` installed. This is the tool's core appeal — keep one file, get caching for free. ## When to reach for this Once the trigger condition above is met, reach for anchored-install for **checkpointed retries**: completed shell steps should be cached and a failed or interrupted run should resume without repeating them. This also applies when an existing installation has already failed repeatedly and the user wants to preserve its completed progress. The payoff is biggest for long, effectful sequences such as installing packages, cloning and building repos, downloading large artifacts, running migrations, or provisioning a machine. When the task is to author a new install/setup/provisioning script, infer the need proactively when restarting from the top would make several expensive or failure-prone steps run again, even when the user did not say “cache” or “resume.” Add the `#ai` markers from the beginning; do not wait for the first failure. This inference applies to a script we are designing, not to wrapping or executing an existing vendor/third-party installer. For a plain first-time vendor/third-party installer, package-manager command, or short script, use the ordinary installation workflow. After repeated interruptions, move to `ai` when rerunning would redo completed work, even if the user did not name the tool. A single installer error is an ordinary debugging task; it does not by itself establish a need for `ai`. Caching overhead and on-disk snapshots are not worth adding when rerunning everything is cheap. ## The mental model (read this before authoring) Three ideas explain everything the tool does: 1. **Each non-comment logical line is one step.** Steps are the unit of caching. 2. **Cache keys are chained (Dockerfile-style).** A step's key folds in the previous step's key: ``` key[i] = sha256(key[i-1] + "\n" + normalized(step[i].text)) ``` So **editing step _i_ invalidates step _i_ and everything after it**, while steps `0..i-1` stay cached. Appending new steps at the end re-uses all earlier caches. This is why **step order matters** — see "Order steps for cache reuse". 3. **Environment carries across steps, even cached ones.** `cd` and `export` persist between steps because after each success `ai` snapshots the *delta* it made to the environment and working directory. When a cached step is skipped, its delta is replayed, so later steps still see the right `$VARS` and `pwd` even though the step didn't actually re-run. Only step **text** feeds the hash. Comments and blank lines are stripped before hashing, so reformatting or rewording a comment **never** busts the cache. ## Authoring a manifest Write commands one logical step per line. Give the file its **native shell extension** (`.sh` on Linux) so it stays a runnable bash script. The parsing rules: - **One logical line = one step.** A trailing `\` continues a line, so a single step can span physical lines: ```bash echo "downloading..." && \ curl -fsSL https://example.com/x.tar.gz -o x.tar.gz && \ tar xzf x.tar.gz ``` - **Comments (`# ...`) and blank lines are ignored** and never affect the cache. - **Multi-line shell constructs must be wrapped in a block.** An `if`, `for`, `while`, `case`, or heredoc spans several lines that together form *one* step — collapse them with `#ai >>>` … `#ai <<<`: ```bash #ai >>> if ! command -v node >/dev/null; then curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs fi #ai <<< ``` Without the block, each physical line would be parsed as its own step and the construct would break. **Whenever you write a multi-line construct, wrap it.** - **`#ai: always`** marks the *next* step to run on every invocation, even when everything else is cached. Use it for effects that don't gate later steps — logging, banners, timestamps, "current status" echoes. - **`#ai: name