pi-multi-agent-skillSAFE
Minimal, lightweight multi-agent skill + CLI for pi. No extension, no new tools. Run agents in parallel or in the background, then wait for, steer, stop or resume them. Works from any harness or agent that has a shell.
Overview
From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.
A minimal, lightweight multi-agent skill and CLI for pi. It needs no extension and adds no tools. Your agent starts other agents, runs them in parallel or in the background, and waits for, steers, stops or resumes them. Any harness or agent that has a shell can use it.
It aims to be minimal while keeping subagents as useful as an extension and tool based approach. A subagent extension adds its tool definitions to every request, while this skill adds only a few dozen tokens of description to your agent's context until it decides to delegate.
Install
Install the skill as a pi package from npm:
pi install npm:pi-multi-agent-skill
Or install directly from GitHub:
pi install git:github.com/milanglacier/pi-multi-agent-skill
You can also install the skill with the open skills CLI:
npx skills install milanglacier/pi-multi-agent-skill --global --agent pi
The CLI copies the skill to ~/.agents/skills/multi-agent, which pi reads. You can also link it into pi's skills directory yourself:
ln -s "$PWD/skills/multi-agent" ~/.pi/agent/skills/multi-agent
Requirements: pi and Python 3.9 or later. Nothing else to install.
Features
- Small token cost. A subagent extension adds its tool definitions to
every request, whether or not your agent delegates anything. With this skill, your agent's context holds only the skill's description, a few dozen tokens, until it decides to delegate. Then it loads SKILL.md, which is about 1.2K tokens and is all it needs for a fully working multi-agent setup. The details of each command stay in separate references that it reads only when needed.
- Everything a subagent tool does, without the tool. Your agent gets the
same controls a dedicated extension would give it: start agents, wait for them, steer one with a correction, abort it and keep what it has so far, resume a finished job with a follow-up task, and see wh
0805e4297ca9OBSERVED · 2026-10-13Install
Commands as the repository documents them. They are shown, not run.
uv run --with pytest --with pytest-xdist pytest -n auto tests
uvx ruff check .
uvx ruff format --check .
Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned | |
| codex | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: multi-agent description: Start other pi agents and delegate work to them. Use it when a task benefits from a multi-agent workflow, such as splitting work across agents, running it in parallel or in the background, or keeping a side task out of your own context. --- # Multi-agent This skill starts other agents and manages each one as a named job. An agent does not see your conversation unless you start it with `--fork`, and you see only its final message. `SKILL_DIR` below is the directory that contains this SKILL.md. Every command has the form: ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" <command> ... ``` ## Pick a profile A profile sets an agent's system prompt, model, thinking level and tools. Run this once per session to see the available profiles: ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" profiles ``` There are two built-in profiles. `general-purpose` (the default) has your tools and settings. `Explore` is a read-only search agent. Pass a profile with `--profile NAME`. ## Run an agent For a short single task, run it in the foreground. The command blocks until the agent finishes and prints its result: ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" run --profile Explore "Where is the retry policy for HTTP calls defined?" ``` Pass a prompt longer than one line through `-` and a heredoc: ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" run --name auth-review - <<'EOF' Read src/auth/ and list every place that ... EOF ``` Write prompts that are self-contained: give the goal, the relevant paths and what the answer should contain. When the task builds on your conversation so far, add `--fork` instead: the agent starts from a copy of it. For a long task, or several tasks in parallel: - If your harness has a tool that runs a shell command in the background, run the foreground `run` command with it. The job then stops when your session ends. The command prints `multi-agent: started job NAME` first; use that name for `steer` and `abort`. If the tool can wake you on each output line, turn that off and wait for the command to exit. If the tool has its own timeout, see "Timeouts" below. - Otherwise, or when the work must continue after your session ends, add `--background`. The command prints the job name and returns at once. A background job runs until it finishes or reaches its timeout (one hour by default). Tell the user the job's name. - Never put the command in the background with `&`; use `--background`. Run only as many jobs at once as the task needs. ## Timeouts - A foreground `run` or `resume` has no timeout unless you pass `--timeout S`. It stops when the agent finishes or when the command ends, for example when your tool call is cancelled or your session ends. - A `--background` job stops after one hour unless you pass `--timeout S`. `--timeout 0` removes the limit. - When a background tool of your harness runs the foreground command and the tool has its own timeout, pass a shorter `--timeout`, leaving a grace period so the job stops the agent and records its result before the tool kills it. If you disable the tool's timeout instead, the job runs until the agent finishes or your session ends. ## Wait for a result ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" wait NAME --timeout 120 ``` Exit code 2 means the job is still running; run the same command again in a new tool call. Wait for one job per tool call and do not chain several `wait` commands in one call: a message that steers you arrives only after your current tool call returns. The output is the agent's final message followed by a `--- multi-agent ---` footer. The footer is for you. Report the agent's findings to the user in your own words. Exit code 0 means the job ended with status `done`; 1 means it ended another way (`failed`, `aborted`, `timeout`, `killed`, `died`), and the output says why. ## Correct or continue a job ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" steer NAME "Skip the tests directory" python3 "$SKILL_DIR/scripts/multi_agent.py" abort NAME python3 "$SKILL_DIR/scripts/multi_agent.py" kill NAME python3 "$SKILL_DIR/scripts/multi_agent.py" resume NAME "Now check the callers too" ``` - `steer` adds a message that the agent reads before its next step. - `abort` stops the agent and keeps its last message as the result. - `kill` stops a job that does not respond to `abort`. - `resume` continues a finished job's conversation with a new prompt. `kill --all` stops every running job of the current project. Use it only when the user asks. ## Inspect jobs ```bash python3 "$SKILL_DIR/scripts/multi_agent.py" list python3 "$SKILL_DIR/scripts/multi_agent.py" status NAME python3 "$SKILL_DIR/scripts/multi_agent.py" peek NAME ``` `peek` shows the job's recent tool calls. ## References The `references/` directory next to this file has the details. Read a file only when you need it: - `commands.md`: every command and option, output formats and exit codes. - `lifecycle.md`: statuses, how a run stops, foreground and background lifetime, timeouts, dialogs and nesting. - `profiles.md`: writing a profile, where profiles are looked up, and how the model, tools and system prompt are chosen. - `state.md`: where jobs and conversations are stored, and the agent's environment. - `troubleshooting.md`: error messages and what to do about them.
Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | WARN |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- declared (3 observation(s))
- Network
- declared (2 observation(s))
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (2)
lines = text.lstrip("").splitlines()CLAUDE.md
Gates applied: no_behavioural_pass.
0805e4297ca9full audit observations/trust-audit/skill/milanglacier__pi-multi-agent-skill.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-13 | 0805e4297ca9 | SAFE | B | 89 | first audit |
Questions
What does the pi-multi-agent-skill skill do?
Minimal, lightweight multi-agent skill + CLI for pi. No extension, no new tools. Run agents in parallel or in the background, then wait for, steer, stop or resume them. Works from any harness or agent that has a shell.
Is pi-multi-agent-skill safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can pi-multi-agent-skill access on my machine?
The audit observed that it reaches the network and reads or writes files. Each of those is consistent with what it says it does. Secrets in the source: none found.
Which assistants does pi-multi-agent-skill work with?
Its documentation mentions claude-code and codex. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (0805e4297ca9), read on 2026-10-13. The repository is watched, and a new audit runs when it changes — this is the first audit.