vitya
6b36b312fa
Adds the conversion infrastructure for the Hermes-rollout (Nous Research): - hermes/mapping.yaml — per-skill schema (mode: auto|manual|skip|pending, category, replace-rules, source override). Every skills/<name>/ has an explicit entry; the build fails on unmapped skills. - scripts/build-hermes.py — Python converter. Reads mapping.yaml; for auto applies replace-rules to SKILL.md and copies the rest verbatim; for manual copies hermes/skills/<source>/ as-is; for skip / pending records to dist-hermes/SKIPPED.md. - dist-hermes/ — pre-converted Hermes-flavour tree (committed; consumed by the recursive installer in [hermes-installer-skill]). Includes 4 universal skills: pulling-before-work, active-platform (with Linux+bash replacement rule), project-discipline, using-markitdown. Plus SKIPPED.md listing 8 skip + 10 pending entries. - README.md — adds "Build for Hermes" section, updates layout, mentions hermes/, dist-hermes/, build-hermes.py. Mapping is the source of truth for the audit table from .wiki/concepts/hermes-skills-rollout-design.md (Q1-Q8). Pending entries preserve the audit decision (intended mode/category) for the follow-up tasks: hermes-flavour-mcp-setups, hermes-installer-skill, hermes-mvp-coverage. Security carry-forward (extraheader-pattern, POSIX-absolute paths, semver bumps) — infrastructure ready (replace-rules + manual mode); concrete content lands in hermes-flavour-mcp-setups. Smoke-tests: idempotent re-run produces no diff; replace-rules verified on active-platform (Linux+bash); strict-mapping fail-fast verified on a synthetic unmapped skill (exit 1). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
86 lines
6.1 KiB
Markdown
86 lines
6.1 KiB
Markdown
---
|
|
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
|
|
|
|
**Linux + bash.** Use this until something in the session tells you to switch. Reason: Hermes runs on Linux factory machines. 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.
|