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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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.
| 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"