القائمة
Use whenever working in a project. Establishes state/scope/verification discipline. Auto-loaded at session start. Complements superpowers.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 at start of work, after env changes (deps/branch/OS), or when something stops working. Runs init.sh health check; treats failures as blocking.
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 | using-harness-anchor |
| description | Use whenever working in a project. Establishes state/scope/verification discipline. Auto-loaded at session start. Complements superpowers. |
You have the harness-anchor runtime layer, companion to superpowers (process methodology): it anchors state persistence, scope boundaries, verification gates, and C/C++ engineering.
Windows session (Git-Bash): plugin scripts already handle path and JSON-engine portability — do not hand-"fix" MSYS paths or shell out to PowerShell. C/C++ caveat: TSan/LSan are unavailable on this platform; read the cpp-sanitizers skill's Windows platform notes before trusting sanitizer coverage.
On apparent conflict, prefer superpowers' process and use harness-anchor to anchor state/evidence around it.
If they exist in the project root, read in this order:
AGENTS.md or CLAUDE.md — operating manualfeature_list.json — active feature + scope + done criteriaPROJECT-TOC.md — file-level index, one line per filegolden-rules.md — project taste / anti-pattern rules to honorsession-handoff.md — what previous session leftIf none exist, the project is un-anchored. Suggest the user run /anchor to scaffold.
project-indexing — need to find files; PROJECT-TOC.md before Globfeature-state-keeper — feature work starts/finishes; updates feature_list.json + progress.mdinit-verification — at start of work; run init.sh health checkself-correction-loop — after edits that fail lint/build; iterate with evidenceanti-hallucination-gates — before claiming "done"; Default-FAIL evidence contracttest-coverage-design — what to test / is coverage real before "done"; dispatches coverage-analystcapturing-golden-rules — a mistake recurs / a review comment is really a convention; encode it in golden-rules.mdcontext-budget-discipline — context fills up; SELECT/WRITE/COMPRESS/ISOLATEdocs-lookup — unfamiliar tools/APIs/errors; Context7 → WebSearch → calibrated-uncertainty chaincpp-build-systems — CMake/Meson/Make/Bazel projectcpp-static-analysis — clang-tidy / cppcheck / IWYUcpp-formatting — clang-formatcpp-sanitizers — ASan / UBSan / TSan / valgrindin-progress. The same rule runs in reverse: a claim that something is missing (tool not installed, no such function) must state what you searched and when — searched <scope>, not found (as of <date>). Express uncertainty: "I am uncertain whether X passes because ."feature_list.json / progress.md / session-handoff.md./verify · /test-plan · /gc; the parent runs them after workers integrate.docs-lookup. Never guess at unfamiliar tools/APIs/errors.Interop seams with superpowers (contract in the named skill): parallel/subagent dispatch → feature-state-keeper; worktree setup → init-verification; sensor-finding triage → self-correction-loop (+ receiving-code-review).
Commands never auto-trigger (unlike skills). Surfacing the right one — with a one-line why — is your job.
/anchor — project un-anchored (no feature_list.json): scaffolds the state files./cpp-init — C/C++ project with no .clang-format/.clang-tidy (right after /anchor): drops C/C++ config + sanitizer build./index-project — PROJECT-TOC.md absent or stale, or before a broad file search: (re)builds the index./verify — before claiming a feature passes or flipping status to pass: build + lint + tests in a fresh-context subagent (--fix = bounded ≤2-cycle auto-fix)./test-plan — after implementing, before marking pass: fresh-context coverage-gap analysis. Complements /verify./gc — after a batch of generated code, before /session-end: fresh-context drift/entropy scan vs golden-rules.md + slop heuristics. Read-only (not git gc)./sanitize — after a C/C++ source change, or before merging C/C++: ASan+UBSan run (TSan separately) with an evidence log./status — "where am I / what's the state": read-only snapshot, writes nothing./session-end — at a stopping point: writes handoff, appends progress.md, offers over-budget state archival + a commit.