feat(skills): auto-load skills into system prompt + CLI install commands

[h4sht]

Summary

Skills now behave like Claude Code — installed skills are automatically loaded into the agent's system prompt and always available without needing the agent to explicitly call the `skill` tool.

Problem

Before this PR, skills were a cumbersome two-step process:

1. Install skills via `npx skills add` from the terminal
2. The agent had to explicitly call the `skill` tool by name to load each skill's content

This meant:

• No way to install skills from within the CLI (had to switch to terminal)
• Skills weren't automatically available — agent had to know to load them
• The `/skill:name` slash command injected raw skill YAML as user prompt text, mixing skill content with user requests

Solution

1. CLI Commands

Two new slash commands:

• `/skills install <owner/repo> [--skill ]` — Downloads a skill via `npx skills add` into `.agents/skills/`. Shows install output and refreshes the skill registry. Installed skills will be available in the next session (use `/new`).

• `/skills list` — Shows all currently installed skills with their names and descriptions.

2. System Prompt Auto-Injection

When a session starts, all loaded skills are injected directly into the agent's system prompt as a `# Pre-loaded Skills` section. The YAML frontmatter is stripped so the model only sees the actual instructions. The agent is told it does NOT need to call the `skill` tool.

3. Updated Agent Prompt

The base2 agent prompt now reflects that skills are pre-loaded and directs users to use `/skills install` slash commands instead of `npx skills add`.

Files Changed

File	Change
`cli/src/commands/command-registry.ts`	Added `/skills install` and `/skills list` commands with `execSync` for npx
`packages/agent-runtime/src/run-agent-step.ts`	Inject loaded skills into system prompt after generation
`agents/base2/base2.ts`	Updated skill instructions bullet to reflect auto-loading
`cli/src/data/slash-commands.ts`	Added `/skills` to slash command menu

Backward Compatibility

• The `skill` tool is preserved — it still works for dynamic loading if needed
• Existing `/skill:name` slash commands continue to work (no alias conflict)
• Skills installed via `npx skills add` are still picked up at session start

Known Limitations

• Newly installed skills require a session restart (`/new`) to appear in the system prompt
• `execSync` is used for installation (blocks UI briefly) — could be upgraded to async spawn in a follow-up
• Skills are injected for all non-child agents, not just the orchestrator

[codebuff-team]

Thanks for tackling this — auto-loading skills so the agent doesn't have to remember to call skill is the right direction and matches how Claude Code works.

A few things need fixing before this is portable:

1. Shell injection in command-registry.ts: installCmd is built by joining raw user input (repo, skillName, extraArgs) into a single string and passed to execSync, which runs it through /bin/sh -c. A repo argument like foo; rm -rf ~ or embedded backticks would execute arbitrary shell code. Use execFileSync('npx', ['skills', 'add', repo, ...]) (array args, no shell) instead of string concatenation + execSync.

2. Unconditional injection cost: run-agent-step.ts appends every loaded skill's full body into the system prompt on every agent step where !inheritParentSystemPrompt || !parentSystemPrompt. With several skills installed this could blow up token usage on every single turn for every top-level agent, with no size cap, dedup against already-loaded skills, or opt-out. Given this is a repo-wide behavioral/default change (not user-triggered), it deserves an explicit sizing/limit strategy and probably a feature flag rather than being always-on.

3. Frontmatter stripping regex (^---[\s\S]*?---\n*) only handles frontmatter at the very start; if a skill body contains a literal --- later this is fine since it's non-greedy anchored to ^, but worth a unit test to confirm behavior across the actual skill files in the repo.

4. No tests were added for either the new slash command parsing or the injection logic — this repo would expect coverage for a new user-facing command.

5. The 60s blocking execSync call freezing the UI during install is self-acknowledged as a limitation but is a real UX regression worth fixing rather than deferring.

Fix the injection issue first — that's the blocking concern — then address the prompt-bloat/opt-in question.