factory/skills/active-platform/SKILL.md

name, description

name

description

active-platform

Switches command, path, and example generation to the user's currently active development platform — Windows / Linux / macOS. Use this whenever you produce shell commands, install steps, README quick-start sections, or any output the user will paste into a terminal — even if they don't say "shell" or "command" explicitly. The default active platform is Windows / PowerShell because that's the user's primary workstation. Recognize and obey trigger phrases like "мы на винде", "мы на линуксе", "мы на маке", "we're on Windows", "we're on Linux", "we're on macOS", and close variants — they switch the active platform for the rest of the session. Also activate this skill anytime the user mentions a different machine, a remote box, or asks "how would I run this on X".

active-platform

Keep generated commands in the shell the user actually has open. The user works on multiple machines (Windows primary, Linux/Mac secondary). Translating shell idioms in their head wastes attention; this skill removes that friction.

Default active platform

Windows + PowerShell. Use this until something in the session tells you to switch. Reason: the user's primary workstation is Windows. This default is global, not per-project.

Trigger phrases

Recognize anywhere in user input — beginning, middle, in passing — and update the active platform immediately. Match liberally: case-insensitive, mixed Cyrillic/Latin, missing punctuation should still trigger.

Switch to →	Russian	English
Windows	"мы на винде", "я на винде", "мы на windows", "переключись на винду", "сейчас под виндой"	"we're on Windows", "I'm on Windows", "switch to Windows", "on a Windows box"
Linux	"мы на линуксе", "я на линуксе", "мы на linux", "переключись на линукс", "сейчас под линуксом"	"we're on Linux", "I'm on Linux", "switch to Linux", "on a Linux box"
macOS	"мы на маке", "я на маке", "мы на макоси", "переключись на мак", "сейчас под маком"	"we're on macOS", "we're on a Mac", "I'm on a Mac", "switch to macOS"

After matching, briefly confirm the switch in one short line ("ок, теперь под линукс" / "got it, switching to Linux") so the user knows the change took. Don't lecture — one line is enough.

What to apply the active platform to

This rule governs what you show the user — chat command snippets, README quick-start sections, install instructions, any line they'll copy and paste. It does not govern your own tool calls: those follow the harness's Shell: line, which is what actually runs in this environment. The two are decoupled on purpose — the harness might be running git-bash on a Windows machine, but you should still hand the user PowerShell commands because that's their daily shell.

Per-platform conventions

Windows / PowerShell

• Shell: PowerShell. Show pwsh (PowerShell 7) when offering install instructions; assume powershell (5.1) is the floor for compatibility notes.
• Chaining: ; for sequential. PS 5.1 has no &&/|| — use if ($?) { B } for "B only if A succeeded". Don't write A && B for Windows users on the assumption it works.
• Paths: backslashes in user-facing examples (C:\Users\…, ~\.claude\skills\). Forward slashes only inside code that runs in bash/git-bash.
• Env vars: $env:NAME = "value" for set, $env:NAME for read. Not export.
• Common idioms: Invoke-WebRequest (iwr), Test-Path, New-Item, Get-ChildItem (ls), Get-Content (cat), Remove-Item (rm).
• Install scripts: in repos with both variants, prefer the .ps1. Example: pwsh scripts/install.ps1, not bash scripts/install.sh.
• Stop-parsing: for arguments containing -/@ that PS would mis-parse, use --%.

Linux / bash

• Shell: bash. POSIX-friendly syntax.
• Chaining: &&, ||, | work as expected.
• Paths: forward slashes (~/.claude/skills/, /var/log/...).
• Env vars: export NAME=value.
• Install scripts: bash scripts/install.sh.
• Coreutils: GNU flavor — sed -i 's/x/y/', readlink -f, cp -a.

macOS / zsh

zsh is the default shell since Catalina. Mostly the same as Linux, with a few divergences worth flagging when relevant:

• Package manager: brew install … (Homebrew).
• BSD coreutils: sed -i '' 's/x/y/' (the empty '' after -i is required), greadlink instead of readlink -f, no cp -a.
• Paths: ~/Library/... rather than XDG-style.

Cross-platform docs (READMEs in repos that target multiple OSes)

When writing user-facing docs in a repo that is explicitly cross-platform — like this claude-skills repo — show both PowerShell and bash variants. List the active platform's variant first, the other second. Tag each fenced block clearly:

**Windows (PowerShell):**
```powershell
pwsh scripts/install.ps1
```

**Linux / macOS (bash):**
```bash
bash scripts/install.sh
```

This is a docs-level decision, independent of the active platform — both blocks ship together.

Per-question overrides (don't change the session)

If the user asks about a specific other machine in a single question — e.g. "how would I run this on the prod box, which is Ubuntu", "что это будет на маке" — answer that one in the named platform's shell, but do not flip the session-wide active platform. The trigger phrases above are deliberately phrased as "we're on …" / "мы на …" because they imply the workstation we're now using together, not "tell me what this looks like elsewhere".

Ambiguity policy

• No signal in the conversation → use the default (Windows).
• Conflicting signals (e.g., user said "we're on Linux" earlier, but now asks an OS-specific question that contradicts) → trust the most recent explicit trigger; if still unclear, ask one short question.
• Unknown platform names ("BSD?", "WSL?") → treat WSL as Linux; for anything genuinely unfamiliar, ask.