feat: add active-platform skill (Win/Linux/macOS switcher)

- skills/active-platform/SKILL.md: default = Windows/PowerShell; trigger
  phrases in RU+EN switch the active platform for the session; per-platform
  conventions (chaining, paths, env vars, install scripts) documented
- dist/active-platform.skill: built archive
- .wiki/source/active-platform-decision.md: rationale (skill chosen over
  global CLAUDE.md / project memory; user wanted a discoverable, iterable
  artifact)
- scripts/build.sh: fix PS arg-passing — single-quotes were leaking into
  -Names value, so multi-arg builds on Windows were rejected with
  "not found in skills/"

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.tasks/STATUS.md

@@ -3,6 +3,13 @@ _Updated: 2026-04-28_
 
 ## Done
 
+### active-platform skill
+- [x] Draft `skills/active-platform/SKILL.md` (RU+EN triggers, default=Windows/PowerShell, palette=Win/Linux/mac)
+- [x] Fixed `build.sh` PS arg-passing bug (single-quotes were leaking into `-Names` value)
+- [x] Build `dist/active-platform.skill` and install into `~/.claude/skills/`
+- [x] Document decision in `.wiki/source/active-platform-decision.md`
+- [x] Update `.wiki/SUMMARY.md`
+
 ### bootstrap-skills-migration
 - [x] Bootstrap repo (git, .wiki, .tasks, CLAUDE.md)
 - [x] Brainstorm and document repo layout (`.wiki/source/repo-layout.md`)
@@ -20,3 +27,5 @@ _Updated: 2026-04-28_
 - Consider a PowerShell-native `install.ps1` (current `install.sh` already works in git-bash, so low priority).
 - Revisit grouping/manifest if skill count grows past ~30.
 - Decide whether to write a smoke-test that round-trips `skills/<name>/` → `dist/<name>.skill` → unpack → diff (would catch archive-shape regressions).
+- Tune `active-platform` triggers based on real-world usage; add WSL handling if it comes up.
+- Consider running formal `skill-creator` eval loop on `active-platform` once we have ~5 real interactions to learn from.

.wiki/SUMMARY.md

@@ -7,3 +7,4 @@ The agent updates this file whenever source/ changes.
 
 - [repo-layout.md](source/repo-layout.md) — how the repo is organized: `skills/` sources, `dist/` builds, `scripts/` build & install
 - [build-notes.md](source/build-notes.md) — why `build.ps1` exists, ZIP layout, PowerShell 5.1 backslash gotcha
+- [active-platform-decision.md](source/active-platform-decision.md) — why we made `active-platform` a skill instead of a memory entry

.wiki/source/active-platform-decision.md

@@ -0,0 +1,33 @@
+# Decision: `active-platform` skill
+
+_2026-04-28._
+
+## Problem
+
+The user develops on multiple machines (Windows primary, Linux/macOS secondary). I was generating bash one-liners by default — wrong shell for their daily workstation. Need a way to make Windows/PowerShell the default and switch on a phrase.
+
+## Options weighed
+
+- **Project memory** — wrong scope (project-only, doesn't cross repos).
+- **Global `~/.claude/CLAUDE.md`** — right scope, simple, but the user explicitly preferred a skill: "поживём со скиллом" (let's live with a skill and iterate).
+- **New skill** ← chosen.
+
+The user's reasoning for the skill route: it's a discoverable, shareable artifact that lives next to their other 12 skills, and it can evolve with the same edit/build/install loop.
+
+## What the skill does
+
+Switches command/example generation between Windows / Linux / macOS based on session signals. Default = Windows + PowerShell. Trigger phrases in RU + EN (e.g. "мы на винде", "we're on Linux"). The rule applies only to **user-facing output** — tool calls still follow the harness's `Shell:` line.
+
+Full spec: [`skills/active-platform/SKILL.md`](../../skills/active-platform/SKILL.md).
+
+## Why this is a skill, not memory
+
+- **Discoverability:** appears in `available_skills` list, can be re-read or audited.
+- **Cross-repo:** installed into `~/.claude/skills/`, applies in every session regardless of project.
+- **Iterable:** lives in this repo's `skills/` so we can edit + reinstall as we learn what triggers and exceptions actually happen in practice.
+
+## Open questions to revisit
+
+- Are the trigger phrases comprehensive enough? Add real-world examples as they come up.
+- WSL handling — currently treated as Linux. Reconsider if user has WSL-specific needs.
+- macOS divergences (BSD coreutils, Homebrew) — minimal coverage now, expand if user actually uses macOS often.

scripts/build.sh

@@ -40,8 +40,8 @@ elif command -v powershell.exe >/dev/null 2>&1; then
   if [ "$#" -eq 0 ]; then
     powershell.exe -NoProfile -ExecutionPolicy Bypass -File "$(cygpath -w "$ps1" 2>/dev/null || echo "$ps1")"
   else
-    # Build a comma-separated PS argument list.
-    joined=$(printf ",'%s'" "$@")
+    # PS array via -File: comma-separated, no extra quoting (bash arg becomes one PS token).
+    joined=$(printf ",%s" "$@")
     joined="${joined:1}"
     powershell.exe -NoProfile -ExecutionPolicy Bypass -File "$(cygpath -w "$ps1" 2>/dev/null || echo "$ps1")" -Names "$joined"
   fi

skills/active-platform/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: active-platform
+description: 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:
+
+````markdown
+**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.