Repository navigation
Windows skill reference docs assume mktemp/POSIX paths despite shell = powershell #3600
Description
Follow up from #3439 / PR #3442.
The Windows platform declares shell = "powershell" in tools/skillgen/platforms.toml, and the repo already has a dedicated, deliberately strict POSIX to PowerShell translator for the core skill body (tools/skillgen/gen.py, the _PY_INVOKE_POSIX/_PY_INVOKE_PS_OPEN etc. block). That translator only runs on the core monolith, not on the per-platform references/*.md files.
As a result, graphify/skills/windows/references/add-watch.md and graphify/skills/windows/references/query.md still contain literal mktemp /tmp/graphify_*.XXXXXX bash commands inside fenced code blocks, which don't exist on a native Windows shell. A Windows host following these reference docs (add, watch, query, path, explain) gets a command it can't run.
Fixing this properly needs a decision on approach, not a one line patch:
- Extend the existing strict translator to also run over
references/*.md, adding a translation formktemp(PowerShell equivalent is roughlyNew-TemporaryFileor[System.IO.Path]::GetTempFileName(), but the "capture the printed path into a variable" idiom differs from bash's$(mktemp ...)and needs its own translation rule), or - Give windows its own reference fragment variant for the handful of sections that use
mktemp, or - Some other approach the maintainers prefer.
Flagged by the graphify review bot on PR #3442 (graphify/skills/windows/references/add-watch.md:15, escalate/medium), confirmed real by grepping — the same pattern also appears in references/query.md (6 more occurrences), which the original finding didn't call out.
Activity
maheen8q commentedon Sep 16, 2026
I reproduced this locally. The Windows platform is configured with
shell = "powershell", but the sharedreferences/*.mdfiles are rendered separately from the core body, so the existing POSIX→PowerShell translation doesn't get applied to them.I also confirmed the
mktemppattern inadd-watch.md; I'll check the other references as well.Before implementing, would maintainers prefer extending the existing translator to reference fragments, including a dedicated
mktemptranslation, or using Windows-specific reference variants for the affected sections?ayushcodes10 commentedon Sep 16, 2026
Thanks for picking this up and confirming it @maheen8q — not a maintainer myself, just sharing the reasoning from when I filed this, for whatever it's worth to whoever decides.
I'd lean toward extending the existing translator over Windows specific reference variants, mainly because of a property it already has: it's deliberately strict (
_POWERSHELL_BANNED_TOKENS, the "any bash line it does not recognize raises at render time" invariant in its own docstring), specifically so a future core edit can't silently ship untranslated bash to the Windows variant. A separate Windows-only copy of the affected reference sections loses that guarantee — nothing forces the Windows copy to be updated when the shared fragment changes, so it can quietly drift out of sync in exactly the way the translator was built to prevent.The
mktemptranslation itself seems tractable: capture-into-a-variable is the only shape that needs a new rule (New-TemporaryFileor[System.IO.Path]::GetTempFileName()in place of$(mktemp ...)), the reference fragments only use it in that one idiom throughout.Good luck with it — happy to review if useful once you have something up.
fix(skillgen): translate Windows reference docs to PowerShell