Menu
Use at start of work, after env changes (deps/branch/OS), or when something stops working. Runs init.sh health check; treats failures as blocking.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Use before claiming done/fixed/passing โ or before asserting something is absent: not installed, not available, no such function, couldn't find it. Default-FAIL runs both ways โ every claim needs an evidence path. A negative claim must carry its search scope and observation date; state calibrated uncertainty when evidence is missing.
Use whenever working in a project. Establishes state/scope/verification discipline. Auto-loaded at session start. Complements superpowers.
Use in C/C++ projects for clang-format. Changed-lines-only; never reformat unchanged code mid-feature. .clang-format from root or LLVM baseline.
Use in C/C++ projects when reviewing changes or hunting bugs. Runs clang-tidy/cppcheck/IWYU. Needs compile_commands.json. Changed lines only.
Use in C/C++ projects for build configure/errors, compile_commands.json generation, or selecting CMake/Meson/Make/Bazel commands.
Use when sessions run long, adding subagents, fetching large files, or planning context-heavy work. SELECT/WRITE/COMPRESS/ISOLATE discipline.
Based on SOC occupation classification
| name | init-verification |
| description | Use at start of work, after env changes (deps/branch/OS), or when something stops working. Runs init.sh health check; treats failures as blocking. |
Before writing any code, prove the environment is healthy. Anthropic's Nov 2025 harness guidance: the initializer agent runs init.sh, then the coding agent picks up โ health is verified BEFORE work begins.
git checkout to a different branchLocate init.sh in project root.
/anchor to scaffold one. Do not proceed.Run it.
bash init.sh
Capture stdout+stderr.
Interpret exit code.
| Exit | Meaning | Action |
|---|---|---|
| 0 | All checks passed | Proceed with work |
| 1 | One or more checks failed | Stop. Fix the reported issues before doing anything else. |
| other | Unexpected | Read output; either fix init.sh itself or report to user |
On failure: list the specific missing files/tools, propose fixes one at a time:
cmake not found) โ suggest install command appropriate to platform (brew install cmake on macOS)feature_list.json missing) โ suggest /anchorcompile_commands.json missing) โ suggest correct configure commandAfter fix: re-run init.sh. Repeat until exit 0. Then continue work.
Re-check inherited NEGATIVE capability conclusions.
A line in AGENTS.md shaped like searched <scope>, not found (as of <date>)
records what a past session observed. It is not a current fact. Re-check
each one. This step, by construction, only ever re-checks conclusions
already recorded as absent, so it always takes the discovery chain's
NOT_FOUND path โ the slower, full-ladder search, not the fast PATH hit โ and
that path measures ~1.6s for two tools (51-entry PATH):
bash ${CLAUDE_PLUGIN_ROOT}/scripts/cpp-tool-discovery.sh <tool>
For non-C/C++ ecosystems, the equivalent is command -v <tool> plus that
platform's known install locations โ command -v alone is the check that
produced the wrong conclusion in the first place.
Only negative conclusions get re-checked, and that asymmetry is deliberate:
| Conclusion | How it fails once stale | Needs a proactive re-check? |
|---|---|---|
| Negative ("clang-tidy not found") | Silently. The tool gets installed, the note never updates, and the capability is skipped for the rest of the project's life. This is the observed failure mode. | Yes |
| Positive ("clang-tidy at /usr/bin/clang-tidy") | Loudly. The next invocation is command not found. | No |
Residual blind spot: this step only reaches lines written in the mandated form above. A capability conclusion phrased freehand โ or written before v0.17.0 โ is invisible to it. A clean re-check means "the dated conclusions are current", never "the manual contains nothing stale".
The template provides scaffolding for:
gitThe user edits init.sh to add project-specific checks:
cmake -S . -B .build / npm install / cargo check)node --version, python --version)Keep init.sh fast โ under 30 seconds. Heavyweight checks (full test suite) belong in /verify, not init.
When init.sh reports OK, the agent's claim is "environment looks healthy as of ". Don't oversell โ env can drift mid-session if commands modify it.
When it fails, list the specific failed step, not "init failed" alone.
init.sh because "I think the env is fine" โ you don't know until you checkinit.sh to make a failing check pass without fixing the underlying issue โ maskinginit.sh once at session start, then assuming the env stays healthy 4 hours later โ re-run after meaningful environment changesWhen superpowers:using-git-worktrees sets up an isolated workspace, its Step 2 (Project Setup) is init.sh โ run it as the baseline instead of re-deriving ad-hoc npm install / cargo build; its Step 3 (Verify Clean Baseline) is the project's test command / /verify (the heavier pass init.sh deliberately defers). The git-tracked state trio travels with the branch checkout, so a worktree is already anchored โ don't re-run /anchor. But .harness-anchor/ is gitignored, so a fresh worktree starts with no prior verify/coverage/drift evidence: that is expected, not un-anchored โ it is recreated on demand when a sensor first writes to it.
When init.sh fails with a cryptic toolchain message (e.g., CMake "could not find compiler", npm ENOENT, cargo "linker not found") โ invoke the docs-lookup skill. Context7 is best for stable tool behavior; WebSearch surfaces recent platform-specific changes; calibrated uncertainty when neither helps.
Typical entry query: paste the exact error string in quotes + the tool name.
/anchor โ scaffolds the initial init.sh/verify โ heavier-weight full verification (different scope)feature-state-keeper โ init.sh failure is captured in session-handoff.md "Risks"