Problem
The shared skill workflow docs at skills/prevent/references/workflows.md and skills/generate-validation-notebook/SKILL.md reference scripts via:
```bash
python3 ${CLAUDE_PLUGIN_ROOT}/skills/prevent/scripts/sandbox/parse_profiles.py <profiles.yml>
```
`${CLAUDE_PLUGIN_ROOT}` is set only by Claude Code at runtime. Other editors use different variables:
| Editor |
Env var |
| Claude Code |
`${CLAUDE_PLUGIN_ROOT}` |
| Cursor |
`${CURSOR_PLUGIN_ROOT}` |
| Codex |
`${CODEX_PLUGIN_ROOT}` |
| opencode |
project-relative path (no env var) |
| Copilot |
(need to confirm) |
In non-Claude editors, `${CLAUDE_PLUGIN_ROOT}` expands to empty string, so the command becomes `python3 /skills/...` — tries to resolve from filesystem root, fails.
Why it "works" today
A capable LLM notices the path doesn't resolve, figures out where the skill is actually installed (e.g. `.opencode/skills/prevent/scripts/...`), and rewrites the path on the fly. This is how `generate-validation-notebook` has been shipping across editors since it was added. Works most of the time. Fails when the LLM loops trying wrong paths (observed in the wild during /mc-validate run testing).
Affected files
- `skills/prevent/references/workflows.md` — 5 invocations (Workflows 6 & 7 scripts)
- `skills/generate-validation-notebook/SKILL.md` — 3 invocations (`resolve_dbt_schema.py`, `generate_notebook_url.py`)
Proposed fix (to design)
Introduce a per-editor shim / wrapper so workflow docs reference a single portable path. Options:
- Wrapper script per skill: `skills//scripts/run.sh` that detects which editor variable is set and execs `python3 /...`. Workflow docs call the wrapper with script-name + args.
- Path resolution helper in shared lib: a tiny Python helper or markdown preamble that resolves the plugin root across editors.
- Normalize the env var at install time: each plugin's install script sets a canonical `MC_PLUGIN_ROOT`. Workflow docs use `${MC_PLUGIN_ROOT}`.
Option 3 is the cleanest but requires editing each install script. Option 1 localizes the mess to shell but is visible in the workflow docs. Option 2 still needs the LLM to run it in the right working dir.
Priority
Medium. The existing LLM-coping behavior works most of the time. Affects reliability/latency of skills on non-Claude editors, not correctness.
Follow-up from
PR #67 — `/mc-validate run` — where the issue was rediscovered. Scope was kept to Claude Code shape; this issue tracks making it work cleanly everywhere.
Problem
The shared skill workflow docs at
skills/prevent/references/workflows.mdandskills/generate-validation-notebook/SKILL.mdreference scripts via:```bash
python3 ${CLAUDE_PLUGIN_ROOT}/skills/prevent/scripts/sandbox/parse_profiles.py <profiles.yml>
```
`${CLAUDE_PLUGIN_ROOT}` is set only by Claude Code at runtime. Other editors use different variables:
In non-Claude editors, `${CLAUDE_PLUGIN_ROOT}` expands to empty string, so the command becomes `python3 /skills/...` — tries to resolve from filesystem root, fails.
Why it "works" today
A capable LLM notices the path doesn't resolve, figures out where the skill is actually installed (e.g. `.opencode/skills/prevent/scripts/...`), and rewrites the path on the fly. This is how `generate-validation-notebook` has been shipping across editors since it was added. Works most of the time. Fails when the LLM loops trying wrong paths (observed in the wild during /mc-validate run testing).
Affected files
Proposed fix (to design)
Introduce a per-editor shim / wrapper so workflow docs reference a single portable path. Options:
Option 3 is the cleanest but requires editing each install script. Option 1 localizes the mess to shell but is visible in the workflow docs. Option 2 still needs the LLM to run it in the right working dir.
Priority
Medium. The existing LLM-coping behavior works most of the time. Affects reliability/latency of skills on non-Claude editors, not correctness.
Follow-up from
PR #67 — `/mc-validate run` — where the issue was rediscovered. Scope was kept to Claude Code shape; this issue tracks making it work cleanly everywhere.