That path does not exist. ~/dev/.skills/ is absent entirely; the script lives at:
~/dev/skills/skills/web-shot/shot.sh
The usage block gives the wrong path four times, and the "Mechanism" section refers to ~/dev/.skills/web-shot/ as well. The brain entry headless-browser-via-k3s-playwright-job repeats it in two places (Shared skill at ~/dev/.skills/web-shot/ and its "See also"), so the stale path is now in two systems.
Why it is worth fixing rather than shrugging at
The skill exists precisely for agents that have no local browser, i.e. agents that will not be able to fall back to anything. When the documented path 404s, the likely outcome is not "look harder" — it is reinventing the Job by hand, which is what I just did: three failed attempts at module resolution inside mcr.microsoft.com/playwright, before finding the skill and having it work first try.
Two of the gotchas the skill already documents are exactly what I hit:
the npm playwright version must match the image tag
getting files out needs the sleep + kubectl cp window, because a finished Job's pod is gone
Both are written down. Neither was reachable from the path in the docs.
Fix
Correct the path in web-shot/SKILL.md (usage block ×4, Mechanism, and any "See also").
Prefer a path that survives relocation — the skill is invoked through the harness by name, so the docs could reference skills/web-shot/shot.sh relative to the checkout rather than an absolute ~/dev/... that depends on where the repo was cloned.
Update the brain entry headless-browser-via-k3s-playwright-job to match.
Aside, possibly worth a separate issue
install.sh symlinks skills into ~/.claude/skills/, ~/.config/crush/skills/ and per-repo .claude/skills/. web-shot is present in ~/.config/crush/skills/ but not in ~/.claude/skills/, so Skill(web-shot) fails in Claude Code with "Unknown skill" even though the skill is installed and the index lists it. Worth checking whether the Claude Code target is being skipped, or whether that install predates the skill.
`web-shot/SKILL.md` tells the caller to run:
```bash
~/dev/.skills/web-shot/shot.sh --port 8099
```
That path does not exist. `~/dev/.skills/` is absent entirely; the script lives at:
```
~/dev/skills/skills/web-shot/shot.sh
```
The usage block gives the wrong path four times, and the "Mechanism" section refers to `~/dev/.skills/web-shot/` as well. The brain entry `headless-browser-via-k3s-playwright-job` repeats it in two places (`Shared skill at ~/dev/.skills/web-shot/` and its "See also"), so the stale path is now in two systems.
## Why it is worth fixing rather than shrugging at
The skill exists precisely for agents that have no local browser, i.e. agents that will not be able to fall back to anything. When the documented path 404s, the likely outcome is not "look harder" — it is **reinventing the Job by hand**, which is what I just did: three failed attempts at module resolution inside `mcr.microsoft.com/playwright`, before finding the skill and having it work first try.
Two of the gotchas the skill already documents are exactly what I hit:
- the npm playwright version must match the image tag
- getting files out needs the `sleep` + `kubectl cp` window, because a finished Job's pod is gone
Both are written down. Neither was reachable from the path in the docs.
## Fix
- [ ] Correct the path in `web-shot/SKILL.md` (usage block ×4, Mechanism, and any "See also").
- [ ] Prefer a path that survives relocation — the skill is invoked through the harness by name, so the docs could reference `skills/web-shot/shot.sh` relative to the checkout rather than an absolute `~/dev/...` that depends on where the repo was cloned.
- [ ] Update the brain entry `headless-browser-via-k3s-playwright-job` to match.
## Aside, possibly worth a separate issue
`install.sh` symlinks skills into `~/.claude/skills/`, `~/.config/crush/skills/` and per-repo `.claude/skills/`. `web-shot` is present in `~/.config/crush/skills/` but **not** in `~/.claude/skills/`, so `Skill(web-shot)` fails in Claude Code with "Unknown skill" even though the skill is installed and the index lists it. Worth checking whether the Claude Code target is being skipped, or whether that install predates the skill.
Fixed in e7e5143, released as v0.8.3 — CI run #28conclusion: success.
Took the second checkbox rather than the first: correcting ~/dev/.skills/... to ~/dev/skills/skills/... would just re-arm the same trap for the next relocation, and the path differs per host anyway. The usage block now resolves the script from wherever the harness installed it:
SHOT=$(ls ~/.claude/plugins/marketplaces/*/skills/web-shot/shot.sh \
~/.agents/skills/web-shot/shot.sh 2>/dev/null | head -1 ||true)[ -n "$SHOT"]||{echo"web-shot not installed on this host: run install.sh or the plugin install" >&2;exit 1;}
Verified on koala: resolves to /home/mathias/.agents/skills/web-shot/shot.sh, executable. The no-match case returns empty with rc 0 under set -o pipefail (hence the || true), so the explicit guard line prints something actionable instead of running "" --port 8099.
grep -rn "dev/.skills" skills/ now returns nothing.
Brain entry headless-browser-via-k3s-playwright-job updated in three places: the Pattern section now carries the resolution snippet and names skills#26, the "See also" points at the repo, and gotcha 5 ("run ~/dev/.context/wire-skills.sh") was wholesale obsolete — that script and the per-skill ~/.claude/skills/<name> symlinks it created are retired, and leftovers from that era now make skills load twice and get reported by task doctor.
On the aside
web-shot missing from ~/.claude/skills/ is explained by that same retirement: install.sh deliberately no longer writes into ~/.claude/skills/ at all. Claude Code gets skills through the plugin, so Skill(web-shot) resolves as skills:web-shot. What you saw was a leftover pre-plugin install with no web-shot in it, not a skipped target. No separate issue needed — task doctor reports exactly this state now.
Fixed in `e7e5143`, released as **v0.8.3** — CI run [#28](https://git.d-ma.be/mathias/skills/actions/runs/4838) `conclusion: success`.
Took the second checkbox rather than the first: correcting `~/dev/.skills/...` to `~/dev/skills/skills/...` would just re-arm the same trap for the next relocation, and the path differs per host anyway. The usage block now resolves the script from wherever the harness installed it:
```sh
SHOT=$(ls ~/.claude/plugins/marketplaces/*/skills/web-shot/shot.sh \
~/.agents/skills/web-shot/shot.sh 2>/dev/null | head -1 || true)
[ -n "$SHOT" ] || { echo "web-shot not installed on this host: run install.sh or the plugin install" >&2; exit 1; }
```
Verified on koala: resolves to `/home/mathias/.agents/skills/web-shot/shot.sh`, executable. The no-match case returns empty with rc 0 under `set -o pipefail` (hence the `|| true`), so the explicit guard line prints something actionable instead of running `"" --port 8099`.
`grep -rn "dev/.skills" skills/` now returns nothing.
Brain entry `headless-browser-via-k3s-playwright-job` updated in three places: the Pattern section now carries the resolution snippet and names skills#26, the "See also" points at the repo, and gotcha 5 ("run `~/dev/.context/wire-skills.sh`") was wholesale obsolete — that script and the per-skill `~/.claude/skills/<name>` symlinks it created are retired, and leftovers from that era now make skills load twice and get reported by `task doctor`.
## On the aside
`web-shot` missing from `~/.claude/skills/` is explained by that same retirement: `install.sh` deliberately no longer writes into `~/.claude/skills/` at all. Claude Code gets skills through the plugin, so `Skill(web-shot)` resolves as `skills:web-shot`. What you saw was a leftover pre-plugin install with no `web-shot` in it, not a skipped target. No separate issue needed — `task doctor` reports exactly this state now.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
web-shot/SKILL.mdtells the caller to run:That path does not exist.
~/dev/.skills/is absent entirely; the script lives at:The usage block gives the wrong path four times, and the "Mechanism" section refers to
~/dev/.skills/web-shot/as well. The brain entryheadless-browser-via-k3s-playwright-jobrepeats it in two places (Shared skill at ~/dev/.skills/web-shot/and its "See also"), so the stale path is now in two systems.Why it is worth fixing rather than shrugging at
The skill exists precisely for agents that have no local browser, i.e. agents that will not be able to fall back to anything. When the documented path 404s, the likely outcome is not "look harder" — it is reinventing the Job by hand, which is what I just did: three failed attempts at module resolution inside
mcr.microsoft.com/playwright, before finding the skill and having it work first try.Two of the gotchas the skill already documents are exactly what I hit:
sleep+kubectl cpwindow, because a finished Job's pod is goneBoth are written down. Neither was reachable from the path in the docs.
Fix
web-shot/SKILL.md(usage block ×4, Mechanism, and any "See also").skills/web-shot/shot.shrelative to the checkout rather than an absolute~/dev/...that depends on where the repo was cloned.headless-browser-via-k3s-playwright-jobto match.Aside, possibly worth a separate issue
install.shsymlinks skills into~/.claude/skills/,~/.config/crush/skills/and per-repo.claude/skills/.web-shotis present in~/.config/crush/skills/but not in~/.claude/skills/, soSkill(web-shot)fails in Claude Code with "Unknown skill" even though the skill is installed and the index lists it. Worth checking whether the Claude Code target is being skipped, or whether that install predates the skill.Fixed in
e7e5143, released as v0.8.3 — CI run #28conclusion: success.Took the second checkbox rather than the first: correcting
~/dev/.skills/...to~/dev/skills/skills/...would just re-arm the same trap for the next relocation, and the path differs per host anyway. The usage block now resolves the script from wherever the harness installed it:Verified on koala: resolves to
/home/mathias/.agents/skills/web-shot/shot.sh, executable. The no-match case returns empty with rc 0 underset -o pipefail(hence the|| true), so the explicit guard line prints something actionable instead of running"" --port 8099.grep -rn "dev/.skills" skills/now returns nothing.Brain entry
headless-browser-via-k3s-playwright-jobupdated in three places: the Pattern section now carries the resolution snippet and names skills#26, the "See also" points at the repo, and gotcha 5 ("run~/dev/.context/wire-skills.sh") was wholesale obsolete — that script and the per-skill~/.claude/skills/<name>symlinks it created are retired, and leftovers from that era now make skills load twice and get reported bytask doctor.On the aside
web-shotmissing from~/.claude/skills/is explained by that same retirement:install.shdeliberately no longer writes into~/.claude/skills/at all. Claude Code gets skills through the plugin, soSkill(web-shot)resolves asskills:web-shot. What you saw was a leftover pre-plugin install with noweb-shotin it, not a skipped target. No separate issue needed —task doctorreports exactly this state now.