Windows skill reference docs assume mktemp/POSIX paths despite shell = powershell

[ayushcodes10]

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 for mktemp (PowerShell equivalent is roughly New-TemporaryFile or [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.

[maheen8q]

I reproduced this locally. The Windows platform is configured with shell = "powershell", but the shared references/*.md files are rendered separately from the core body, so the existing POSIX→PowerShell translation doesn't get applied to them.

I also confirmed the mktemp pattern in add-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 mktemp translation, or using Windows-specific reference variants for the affected sections?

[ayushcodes10]

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 mktemp translation itself seems tractable: capture-into-a-variable is the only shape that needs a new rule (New-TemporaryFile or [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.