Pi workers launched via `mosaic [yolo] pi` never loaded any skill because buildPiSkillArgs emitted `--no-skills` whenever MOSAIC_PI_SKILL_MODE was unset (the default everywhere), so maintained `~/.config/mosaic/tools/` wrappers stayed invisible and workers improvised raw `tmux send-keys` / `tea` / `gh`. An explicit `--skill` overrides `--no-skills` for that path, so we now force-load a small fleet-critical set (default: `mosaic-tools`) on every Pi launch regardless of mode — no full-catalog context bloat. - launch.ts: add DEFAULT_PI_FORCE_SKILLS + forcedPiSkillArgs(); merge into every buildPiSkillArgs() return path (existsSync-guarded → no-op until the skill is synced). Override via MOSAIC_PI_FORCE_SKILLS (colon-separated; empty string disables). - launch.spec.ts: deterministic 4th-param injection + force-load coverage. - runtime/pi/RUNTIME.md: reconcile the "skills load natively" drift with the real default-off + force-load + MOSAIC_PI_SKILL_MODE behavior. - templates/agent/**: fix stale `~/.config/mosaic/rails/` → `tools/` (60 occurrences across 12 scaffold templates; `rails/` no longer exists). Companion skill `mosaic-tools` ships in mosaic/agent-skills. Follow-up (NOT auto-applied): live fleet needs `mosaic-sync-skills` + launcher upgrade to pick up the new skill on running sessions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QoYiBeKNh3BiYtAJS5Z587
7.1 KiB
Executable File
7.1 KiB
Executable File