Found in the adversarial review of #120.
Steps 1-2 use $MECHS_ROOT for the shared checkouts, but the variable is unset in the shell, so the commands expand to / and fail
Where: .claude/skills/update-xmech-page/SKILL.md:77
The default path in roots.py lives only inside Python. The skill's shell commands (git -C "$MECHS_ROOT/<Mech>" fetch, git clone … "$MECHS_ROOT/$m") assume MECHS_ROOT is set to the shared checkouts, and the skill never says to set it. Step 3 then reassigns MECHS_ROOT to $SNAP/mechs, which makes the variable ambiguous: an exported value from step 3 would point steps 1-2 at the snapshot itself.
Failure scenario. In a fresh shell, step 2 as written runs git clone -q --shared --no-checkout "/CellStructureMech" … and fails with 'repository does not exist'. Or MECHS_ROOT is still exported as $SNAP/mechs from an earlier attempt, and the clone tries to clone the snapshot into itself.
Evidence. echo ${MECHS_ROOT-unset} prints unset, in both the tool shell and bash -lc, and no rc file sets it. Scratch run with MECHS_ROOT unset: git clone -q --shared --no-checkout "$MECHS_ROOT/$m" … gives fatal: repository '/CellStructureMech' does not exist, exit=128. roots.py:22-24 defines the default only in Python.
Verifier (confirmed, low). The finding reproduces as stated. Steps 1-2 of the skill expand $MECHS_ROOT, which is never set in any shell on this machine, and the skill never says to set it. As written, the commands expand to /<Mech> and fail with exit 128. Step 3's wording "With MECHS_ROOT=$SNAP/mechs:" gives the same name a second meaning, the snapshot, so the variable is ambiguous. If someone exports it there and then reruns steps 1-2, they point at the snapshot instead of the shared checkouts. That second scenario is plausible but depends on a rerun in the same shell.
A related gap makes it slightly worse: culturebotai-claw is not under the Mechs directory at all (it is in KG-Hub/KG-Microbe/). So step 1's $MECHS_ROOT/<Mech> pattern fails for CLAW even when MECHS_ROOT is set to the default.
Severity stays low. Both failures happen at once, loudly and with no side effects: no writes into the shared checkouts, no wrong numbers. An agent can recover by running python3 scripts/fleet/roots.py, which prints the resolved MECHS_ROOT and is mentioned in _fleet/README.md, which the skill says to read first. The cost is friction and an unclear procedure, not a wrong page. The suggested fix holds: a separate source variable such as SRC=${MECHS_ROOT:-/Users/marcin/Documents/VIMSS/ontology/Mechs} for steps 1-2, MECHS_ROOT kept only as the per-command prefix, and the CLAW checkout path stated explicitly.
Suggested fix. Use a separate variable for the source checkouts, e.g. SRC=${MECHS_ROOT:-/Users/marcin/Documents/VIMSS/ontology/Mechs} (or read it from python3 -c 'import roots; print(roots.MECHS_ROOT)'). Keep MECHS_ROOT only for the per-command MECHS_ROOT=$SNAP/mechs prefix in steps 3-4.
Found in the adversarial review of #120.
Steps 1-2 use $MECHS_ROOT for the shared checkouts, but the variable is unset in the shell, so the commands expand to / and fail
Where:
.claude/skills/update-xmech-page/SKILL.md:77The default path in roots.py lives only inside Python. The skill's shell commands (
git -C "$MECHS_ROOT/<Mech>" fetch,git clone … "$MECHS_ROOT/$m") assume MECHS_ROOT is set to the shared checkouts, and the skill never says to set it. Step 3 then reassigns MECHS_ROOT to$SNAP/mechs, which makes the variable ambiguous: an exported value from step 3 would point steps 1-2 at the snapshot itself.Failure scenario. In a fresh shell, step 2 as written runs
git clone -q --shared --no-checkout "/CellStructureMech" …and fails with 'repository does not exist'. Or MECHS_ROOT is still exported as$SNAP/mechsfrom an earlier attempt, and the clone tries to clone the snapshot into itself.Evidence.
echo ${MECHS_ROOT-unset}printsunset, in both the tool shell andbash -lc, and no rc file sets it. Scratch run with MECHS_ROOT unset:git clone -q --shared --no-checkout "$MECHS_ROOT/$m" …givesfatal: repository '/CellStructureMech' does not exist, exit=128. roots.py:22-24 defines the default only in Python.Verifier (confirmed, low). The finding reproduces as stated. Steps 1-2 of the skill expand
$MECHS_ROOT, which is never set in any shell on this machine, and the skill never says to set it. As written, the commands expand to/<Mech>and fail with exit 128. Step 3's wording "WithMECHS_ROOT=$SNAP/mechs:" gives the same name a second meaning, the snapshot, so the variable is ambiguous. If someone exports it there and then reruns steps 1-2, they point at the snapshot instead of the shared checkouts. That second scenario is plausible but depends on a rerun in the same shell.A related gap makes it slightly worse: culturebotai-claw is not under the Mechs directory at all (it is in KG-Hub/KG-Microbe/). So step 1's
$MECHS_ROOT/<Mech>pattern fails for CLAW even when MECHS_ROOT is set to the default.Severity stays low. Both failures happen at once, loudly and with no side effects: no writes into the shared checkouts, no wrong numbers. An agent can recover by running
python3 scripts/fleet/roots.py, which prints the resolved MECHS_ROOT and is mentioned in _fleet/README.md, which the skill says to read first. The cost is friction and an unclear procedure, not a wrong page. The suggested fix holds: a separate source variable such asSRC=${MECHS_ROOT:-/Users/marcin/Documents/VIMSS/ontology/Mechs}for steps 1-2, MECHS_ROOT kept only as the per-command prefix, and the CLAW checkout path stated explicitly.Suggested fix. Use a separate variable for the source checkouts, e.g.
SRC=${MECHS_ROOT:-/Users/marcin/Documents/VIMSS/ontology/Mechs}(or read it frompython3 -c 'import roots; print(roots.MECHS_ROOT)'). Keep MECHS_ROOT only for the per-commandMECHS_ROOT=$SNAP/mechsprefix in steps 3-4.