diff --git a/.claude/skills/xce-build/SKILL.md b/.claude/skills/xce-build/SKILL.md
index fba78ce5..9847083f 100644
--- a/.claude/skills/xce-build/SKILL.md
+++ b/.claude/skills/xce-build/SKILL.md
@@ -27,11 +27,21 @@ nix develop ./src --command bash src/tools/xce-build.sh <component> <profile> <b
 
 e.g. for `/xce-build controller`: `nix develop ./src --command bash src/tools/xce-build.sh controller`. For `/xce-build xceadmin --incremental`: `nix develop ./src --command bash src/tools/xce-build.sh xceadmin --incremental`.
 
-## Always dispatch the build via the Agent tool
+## Run the build via Bash `run_in_background`, not an Agent-tool subagent
 
-Do not run the `nix develop … xce-build.sh` command inline in the current session's Bash tool. Instead, on every invocation of this skill, launch a subagent with the Agent tool, giving it a fully self-contained prompt: repo working directory, the exact resolved command (component/profile/build_dir already substituted — do not make the subagent re-parse ARGUMENTS itself), what the command does, and what to report back (build success/failure, compiler errors, the meson test Ok/Fail summary line, and confirmation the expected binaries were freshly rebuilt with fresh mtimes). Wait for it (do not background it — the build is synchronous and finishes in well under this session's turn budget) and relay its report.
+**Do not dispatch the build to an Agent-tool subagent** (confirmed broken 2026-09-03: a general-purpose subagent given this exact instruction redirected the build to a log file, announced "I've kicked off the build in the background... I'll report back once it finishes," and returned immediately — its own Agent-tool call then shows as `completed` with no build result. That "I'll report back" is not reliable: the parent has already regained control and cannot assume a second notification is coming. In this occurrence the harness *did* eventually deliver a second, fuller notification for the same subagent several minutes later, but a controller cannot bank on that — a near-identical pattern in an unrelated cross-session case never came back at all, per the OpenWolf cerebrum warning "A fork/subagent dispatched in a prior session that claimed 'build/tests in progress, will report back' is NOT reachable in a new session." A model instructed in plain English to "wait, don't background it" backgrounding it anyway is the actual failure mode — a differently-worded subagent prompt is not a reliable fix for that).
 
-This is deliberately a plain Agent-tool dispatch, not `context: fork` — that frontmatter field reproducibly failed to thread a non-empty ARGUMENTS payload into the forked subagent (see above), whereas an explicit, self-contained Agent prompt has no such dependency and is proven to work.
+Instead, run the resolved command directly with the **Bash tool's own `run_in_background: true`**, from the current session, and let the harness's own task-notification mechanism — not a subagent's self-report — tell you when it's done. This has been empirically proven reliable in this exact repo (2026-09-03: both a full `all debug` build and a `controller` ASAN rebuild were driven this way, and each genuinely blocked until real completion).
+
+```bash
+nix develop ./src --command bash src/tools/xce-build.sh <component> <profile> <build_dir> [--incremental] \
+  > <scratchpad>/xce-build-<component>-<profile>.log 2>&1; \
+  echo "EXIT_CODE=$?" >> <scratchpad>/xce-build-<component>-<profile>.log
+```
+
+Call this once with `run_in_background: true` (substitute the resolved component/profile/build_dir and a scratchpad log path first — do not make anything downstream re-parse ARGUMENTS). Then stop and wait; do not poll, sleep-loop, or call `ScheduleWakeup` — the harness delivers a `<task-notification>` the moment the process exits, exactly like any other backgrounded Bash command. When it arrives, read the log's **tail** (e.g. `tail -30`) plus a targeted `grep -nE "error:|FAILED|undefined reference|Traceback"` rather than the whole log, to get the meson test Ok/Fail summary line and any failures without pulling the full (often thousands-of-lines) compiler output into context. Then `ls -la` the expected output binaries to confirm fresh mtimes, the same verification this skill has always asked for — just performed directly instead of trusted from a subagent's claim.
+
+This is deliberately not `context: fork` either — that frontmatter field reproducibly failed to thread a non-empty ARGUMENTS payload into a forked subagent (see above). Running the resolved command directly via `Bash`/`run_in_background` sidesteps both failure modes: there is no subagent in the loop to either drop the ARGUMENTS payload or silently background-and-return.
 
 ## Installing the xceadmin wheel elsewhere