[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-74982":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":15,"starSnapshotCount":15,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},74982,"pi-subagents","nicobailon\u002Fpi-subagents","nicobailon","Pi extension for async subagent delegation with truncation, artifacts, and session sharing",null,"TypeScript",2132,283,6,44,0,39,332,787,117,106.36,false,"main",true,[],"2026-06-12 04:01:16","\u003Cp>\n  \u003Cimg src=\"https:\u002F\u002Fraw.githubusercontent.com\u002Fnicobailon\u002Fpi-subagents\u002Fmain\u002Fbanner.png\" alt=\"pi-subagents\" width=\"1100\">\n\u003C\u002Fp>\n\n# pi-subagents\n\n`pi-subagents` lets Pi delegate work to focused child agents. Use it for code review, scouting, implementation, parallel audits, saved workflows, background jobs, and anything else that benefits from a second or third set of model eyes.\n\nhttps:\u002F\u002Fgithub.com\u002Fuser-attachments\u002Fassets\u002F702554ec-faaf-4635-80aa-fb5d6e292fd1\n\n## Installation\n\n```bash\npi install npm:pi-subagents\n```\n\nThat is the only required step. You can add optional pieces later.\n\n## Try this first\n\nYou do not need to create agents, write config, or learn slash commands. After installing, ask Pi for delegation in plain language:\n\n```text\nUse reviewer to review this diff.\n```\n\n```text\nAsk oracle for a second opinion on my current plan.\n```\n\n```text\nUse scout to understand this code based on our discussion then ask me clarification questions.\n```\n\n```text\nRun parallel reviewers: one for correctness, one for tests, and one for unnecessary complexity.\n```\n\nThat is enough to start.\n\n## What happens\n\nPi is the parent session. A subagent is a focused child Pi session with its own job.\n\nWhen you ask for a subagent, Pi starts the child, gives it the task, and brings the result back. Foreground runs stream in the conversation. Background runs keep working and can be checked later.\n\nInstalling the extension does not start an automatic reviewer in the background. It gives Pi a delegation tool. If you want every implementation reviewed, say that in your prompt or put it in your project instructions:\n\n```text\nWhen you finish implementing, run a reviewer subagent before summarizing.\n```\n\n## Good first prompts\n\nThese cover most day-to-day use:\n\n```text\nAsk oracle for a second opinion on my current plan. Challenge assumptions and tell me what I might be missing.\n```\n\n```text\nUse oracle to help solve this hard bug. Have it inspect the code and propose the best next move before we edit anything.\n```\n\n```text\nRun parallel reviewers on this diff. I want one focused on correctness, one on tests, and one on unnecessary complexity.\n```\n\n```text\nHave worker implement this approved plan. Afterward, run parallel reviewers, summarize their feedback, and apply the fixes that make sense.\n```\n\n```text\nRun a review loop on this change until reviewers stop finding fixes worth doing, with a max of 3 rounds.\n```\n\n```text\nUse scout to understand the auth flow, then have planner turn that into an implementation plan.\n```\n\nThose are ordinary Pi requests. Pi decides whether to call `subagent`, which agent to use, and whether a chain or parallel run makes sense.\n\n## Common workflows\n\n| Want | Ask naturally |\n|------|---------------|\n| Get a second opinion | “Ask oracle to review this plan and challenge assumptions.” |\n| Solve a hard problem | “Use oracle to investigate this bug before we edit.” |\n| Review a diff | “Use reviewer to review this diff.” |\n| Run parallel reviewers | “Run reviewers for correctness, tests, and cleanup.” |\n| Implement then review | “Implement this, then review it.” |\n| Review until clean | “Run a review loop on this change with a max of 3 rounds.” |\n| Execute a plan carefully | “Have worker implement this approved plan, then run reviewers and apply the feedback.” |\n| Scout before planning | “Use scout to inspect the auth flow before planning.” |\n| Run in the background | “Run this in the background.” |\n| Browse agents | “Show me the available subagents.” |\n| Use a saved workflow | “Run the review chain on this branch.” |\n| See running work | “Show active async runs.” |\n| Check setup | “Check whether subagents are configured correctly.” |\n\nThe extension ships with builtin agents you can use immediately.\n\n## Builtin agents in plain English\n\n| Agent | Use it when you want... |\n|-------|--------------------------|\n| `scout` | Fast local codebase recon: relevant files, entry points, data flow, risks, and where another agent should start. |\n| `researcher` | Web\u002Fdocs research with sources: official docs, specs, benchmarks, recent changes, and a concise research brief. |\n| `planner` | A concrete implementation plan from existing context. It should read and plan, not edit code. |\n| `worker` | Implementation work, including approved oracle handoffs. It edits files, validates, and escalates unapproved decisions instead of guessing. |\n| `reviewer` | Code review and small fixes. It checks the implementation against the task\u002Fplan, tests, edge cases, and simplicity. |\n| `context-builder` | A stronger setup pass before planning: gathers code context and writes handoff material such as `context.md` and `meta-prompt.md`. |\n| `oracle` | A second opinion before acting. It challenges assumptions, catches drift, and recommends the safest next move without editing. |\n| `delegate` | A lightweight general delegate when you want a child agent that behaves close to the parent session. |\n\nA simple rule of thumb: use `scout` before you understand the code, `researcher` before you trust external facts, `planner` before a bigger change, `worker` to implement, `reviewer` to check, and `oracle` when the decision itself feels risky.\n\n## Changing a builtin agent's model\n\nBuiltin agents inherit your current Pi default model by default. This keeps new installs from depending on a provider you may not have configured. If you want a role to use a specific model, set an override instead of copying the bundled agent file.\n\nFor one run, put the override in the command:\n\n```text\n\u002Frun reviewer[model=anthropic\u002Fclaude-sonnet-4:high] \"Review this diff\"\n```\n\nFor a persistent override, edit settings. This example pins the reviewer everywhere, adds a backup model for provider failures, and keeps the other builtins on your normal default model:\n\n```json\n{\n  \"subagents\": {\n    \"agentOverrides\": {\n      \"reviewer\": {\n        \"model\": \"anthropic\u002Fclaude-sonnet-4\",\n        \"thinking\": \"high\",\n        \"fallbackModels\": [\"openai\u002Fgpt-5-mini\"]\n      }\n    }\n  }\n}\n```\n\nUse `~\u002F.pi\u002Fagent\u002Fsettings.json` for a user override or `.pi\u002Fsettings.json` for a project override. The same `agentOverrides` block can change `tools`, `skills`, inherited context, prompt text, or disable a builtin. If you want a totally different agent, create a user or project agent with the same name; for normal tweaks, prefer overrides.\n\n## Where running subagents show up\n\nForeground runs stream progress in the conversation while they run.\n\nBackground runs keep working after control returns to you. Inspect active runs with `subagent({ action: \"status\" })`, or a specific run with `subagent({ action: \"status\", id: \"...\" })`.\n\nThey also show a compact async widget and send completion notifications. Parallel background runs show per-agent progress instead of fake chain steps. Chains with parallel groups keep their grouped shape in progress and results, so failed or paused agents stay visible next to completed ones.\n\nYou can also ask naturally:\n\n```text\nShow me the current async runs.\n```\n\nIf something feels misconfigured, run:\n\n```text\n\u002Fsubagents-doctor\n```\n\nor ask:\n\n```text\nCheck whether subagents and intercom are set up correctly.\n```\n\n## Recommended orchestration pattern (scaffolding)\n\nUse orchestration as parent-agent guidance, not as a runtime workflow mode. For implementation work, the recommended loop is:\n\n```text\nclarify → planner → worker → fresh reviewers → worker\n```\n\nUse the optional prompt shortcuts below when you want the pattern to be repeatable.\n\nPackaged `planner`, `worker`, and `oracle` default to forked context when a launch omits `context`; pass `context: \"fresh\"` when you intentionally want a fresh child run.\n\nChild-safety boundaries are enforced at runtime. Spawned child sessions do not register the `subagent` tool, do not receive the bundled `pi-subagents` skill, and receive explicit boundary instructions that they are not the parent orchestrator and must not propose or run subagents. Forked child context filtering also removes parent-only subagent artifacts (including old hidden orchestration-instruction messages, slash\u002Fstatus\u002Fcontrol messages, and prior parent `subagent` tool-call\u002Ftool-result history) while preserving ordinary prose and unrelated tool calls\u002Fresults.\n\n## Optional shortcuts\n\nThe package includes reusable prompt templates for common workflows. You do not need them, but they are handy when you want the same shape every time:\n\n| Prompt | Use it for |\n|--------|------------|\n| `\u002Fparallel-review` | Launch fresh-context reviewers with distinct angles, then synthesize what to fix. |\n| `\u002Freview-loop` | Run parent-controlled worker, reviewer, and fix-worker cycles until clean or capped. |\n| `\u002Fparallel-research` | Combine `researcher` and `scout` for external evidence, local code context, and practical tradeoffs. |\n| `\u002Fparallel-context-build` | Run `context-builder` agents in parallel to produce planning handoff context and meta-prompts. |\n| `\u002Fparallel-handoff-plan` | Combine external research and `context-builder` passes into an implementation handoff plan and meta-prompt. |\n| `\u002Fgather-context-and-clarify` | Scout\u002Fresearch first, then ask the user the clarification questions that matter. |\n| `\u002Fparallel-cleanup` | Run review-only cleanup passes after implementation. |\n\nAdd `autofix` to `\u002Fparallel-review` or `\u002Fparallel-cleanup` to apply only the synthesized fixes worth doing now after reviewers return.\n\n## Optional pi-intercom companion\n\n`pi-subagents` works without `pi-intercom`. Install `pi-intercom` only if you want child agents to talk back to the parent Pi session while they are running.\n\n```bash\npi install npm:pi-intercom\n```\n\nMost users do not call `intercom` directly. After `pi-intercom` is installed, `pi-subagents` can automatically give child agents a private coordination channel back to the parent session. The bridge recognizes the normal `pi install npm:pi-intercom` package install as well as legacy local extension checkouts.\n\nUse it for work where the child might need a decision instead of guessing:\n\n```text\nRun this implementation in the background. If the worker gets blocked or needs a product decision, have it ask me through intercom.\n```\n\n```text\nAsk oracle to review this plan. If it sees a decision I need to make, have it ask me instead of assuming.\n```\n\nThe child can use one dedicated coordination tool:\n\n- `contact_supervisor`: the child contacts the parent\u002Fsupervisor session that delegated the task. Use `reason: \"need_decision\"` for blocking decisions or clarification, and `reason: \"progress_update\"` for short non-blocking updates when a discovery changes the plan. Do not ask for clarification when the only conflict is review-only\u002Fno-edit versus progress-writing or artifact-writing instructions; no-edit wins.\n\nChild-side routine completion handoffs are still not expected. With the intercom bridge active, parent-side `pi-subagents` sends grouped completion results through `pi-intercom`: one grouped message per foreground parent `subagent` run and one per completed async result file. Acknowledged foreground delivery returns a compact receipt with artifact\u002Fsession paths; if unacknowledged, the normal full output is preserved. Grouped messages include child intercom targets and full child summaries.\n\nIf a child appears stalled, needs-attention notices can show up in the parent session with useful next actions, such as checking `subagent({ action: \"status\" })`, interrupting the run, or nudging the child.\n\nIf messages do not show up, run:\n\n```text\n\u002Fsubagents-doctor\n```\n\nFor normal use, you do not need to configure anything. Advanced users can tune the bridge with `intercomBridge` in the configuration section below.\n\nAt this point, you know enough to use the plugin. The rest of this README is reference material for exact command syntax, custom agents, saved chains, worktrees, and configuration.\n\n## Direct commands\n\nSkip this section until you want exact syntax.\n\n| Command | Description |\n|---------|-------------|\n| `\u002Frun \u003Cagent> [task]` | Run one agent; omit the task for self-contained agents |\n| `\u002Fchain agent1 \"task1\" -> agent2 \"task2\"` | Run agents in sequence |\n| `\u002Fparallel agent1 \"task1\" -> agent2 \"task2\"` | Run agents in parallel |\n| `\u002Frun-chain \u003CchainName> -- \u003Ctask>` | Launch a saved `.chain.md` workflow |\n| `\u002Fsubagents-doctor` | Show read-only setup diagnostics |\n\nCommands validate agent names locally, support tab completion, and send results back into the conversation.\n\n### Per-step tasks\n\nUse `->` to separate steps and give each step its own task:\n\n```text\n\u002Fchain scout \"scan the codebase\" -> planner \"create an implementation plan\"\n\u002Fparallel scanner \"find security issues\" -> reviewer \"check code style\"\n```\n\nBoth double and single quotes work. You can also use `--` as a delimiter:\n\n```text\n\u002Fchain scout -- scan code -> planner -- analyze auth\n```\n\nSteps without a task inherit behavior from the execution mode. Chain steps get `{previous}`, the prior step’s output. Parallel steps use the first available task as a fallback.\n\n```text\n\u002Fchain scout \"analyze auth\" -> planner -> worker\n# scout gets \"analyze auth\"; planner gets scout output; worker gets planner output\n```\n\nFor a shared task, list agents and place one `--` before the task:\n\n```text\n\u002Fchain scout planner -- analyze the auth system\n\u002Fparallel scout reviewer -- check for security issues\n```\n\n### Inline per-step config\n\nAppend `[key=value,...]` to an agent name to override defaults for that step:\n\n```text\n\u002Fchain scout[output=context.md] \"scan code\" -> planner[reads=context.md] \"analyze auth\"\n\u002Frun scout[model=anthropic\u002Fclaude-sonnet-4] summarize this codebase\n\u002Fparallel reviewer[skills=code-review+security] \"review backend\" -> reviewer[model=openai\u002Fgpt-5-mini] \"review frontend\"\n```\n\n| Key | Example | Description |\n|-----|---------|-------------|\n| `output` | `output=context.md` | Write results to a file. For `\u002Fchain` and `\u002Fparallel`, relative paths live under the chain directory; for `\u002Frun`, relative paths resolve against cwd. |\n| `outputMode` | `outputMode=file-only` | Return only a concise file reference for saved output instead of the full saved content. Requires `output`; default is `inline`. |\n| `reads` | `reads=a.md+b.md` | Read files before executing. `+` separates multiple paths. |\n| `model` | `model=anthropic\u002Fclaude-sonnet-4` | Override model for this step. |\n| `skills` | `skills=planning+review` | Override injected skills. `+` separates multiple skills. |\n| `progress` | `progress` | Enable progress tracking. |\n\nSet `output=false`, `reads=false`, or `skills=false` to disable that behavior explicitly. Do not use `output=false` for file-only returns; use `outputMode=file-only` with an `output` path.\n\n### Background and forked runs\n\nAdd `--bg` to run in the background:\n\n```text\n\u002Frun scout \"audit the codebase\" --bg\n\u002Fchain scout \"analyze auth\" -> planner \"design refactor\" -> worker --bg\n\u002Fparallel scout \"scan frontend\" -> scout \"scan backend\" --bg\n```\n\nAdd `--fork` to start each child from a real branched session created from the parent’s current leaf:\n\n```text\n\u002Frun reviewer \"review this diff\" --fork\n\u002Fchain scout \"analyze this branch\" -> planner \"plan next steps\" --fork\n\u002Fparallel scout \"audit frontend\" -> reviewer \"audit backend\" --fork\n```\n\nYou can combine them in either order:\n\n```text\n\u002Frun reviewer \"review this diff\" --fork --bg\n\u002Frun reviewer \"review this diff\" --bg --fork\n```\n\nBackground runs are detached. If the parent agent has other independent work, it should keep working. If it has nothing useful to do until the background result arrives, it should end the turn instead of running sleep or status-polling loops. Pi will deliver the completion when the run finishes.\n\nThe `oracle` and `worker` builtins are designed for an explicit decision loop. A typical pattern is to ask `oracle` for diagnosis and a recommended execution prompt, then only run `worker` after the main agent approves that direction.\n\n## Clarify and launch UI\n\nChains open a clarify UI by default so you can preview and edit the workflow before it runs. Single and parallel tool calls can opt into the same flow with `clarify: true`; slash commands launch directly.\n\nCommon clarify keys:\n\n- `Enter` runs in the foreground, or in the background if background is toggled on\n- `Esc` cancels or backs out\n- `↑↓` moves between steps or tasks\n- `e` edits the task\u002Ftemplate\n- `m` selects a model\n- `t` selects thinking level\n- `s` selects skills\n- `b` toggles background execution\n- `w` edits output\u002Fwrite behavior where supported\n- `r` edits reads where supported\n- `p` toggles progress tracking where supported\nPicker screens use `↑↓`, `Enter`, `Esc`, and type-to-filter. The full-screen editor supports word wrapping, paste, `Esc` to save, and `Ctrl+C` to discard.\n\n## Agents and chains\n\nAgents are markdown files with YAML frontmatter and a system prompt body. They define the specialist that will run in the child Pi process.\n\nAgent locations, lowest to highest priority:\n\n| Scope | Path |\n|-------|------|\n| Builtin | `~\u002F.pi\u002Fagent\u002Fextensions\u002Fsubagent\u002Fagents\u002F` |\n| User | `~\u002F.pi\u002Fagent\u002Fagents\u002F**\u002F*.md` |\n| Project | `.pi\u002Fagents\u002F**\u002F*.md` |\n\nProject discovery also reads legacy `.agents\u002F**\u002F*.md` files. Nested subdirectories are discovered recursively. `.chain.md` files do not define agents. If both `.agents\u002F` and `.pi\u002Fagents\u002F` define the same parsed runtime agent name, `.pi\u002Fagents\u002F` wins. Use `agentScope: \"user\" | \"project\" | \"both\"` to control discovery; `both` is the default and project definitions win runtime-name collisions.\n\nBuiltin agents load at the lowest priority, so a user or project agent with the same name overrides them. They do not pin a provider model; they inherit your current Pi default model unless you set `subagents.agentOverrides.\u003Cname>.model`. `oracle` is an advisory reviewer that critiques direction and proposes an execution prompt without editing files. `worker` is the implementation agent for normal tasks and approved oracle handoffs.\n\nThe `researcher` builtin uses `web_search`, `fetch_content`, and `get_search_content`; those require [pi-web-access](https:\u002F\u002Fgithub.com\u002Fnicobailon\u002Fpi-web-access):\n\n```bash\npi install npm:pi-web-access\n```\n\n### Builtin overrides\n\nYou can override selected builtin fields without copying the whole agent. Overrides live in settings:\n\n- User: `~\u002F.pi\u002Fagent\u002Fsettings.json`\n- Project: `.pi\u002Fsettings.json`\n\nExample:\n\n```json\n{\n  \"subagents\": {\n    \"agentOverrides\": {\n      \"reviewer\": {\n        \"inheritProjectContext\": false\n      }\n    }\n  }\n}\n```\n\nSupported override fields are `model`, `fallbackModels`, `thinking`, `systemPromptMode`, `inheritProjectContext`, `inheritSkills`, `defaultContext`, `disabled`, `skills`, `tools`, and `systemPrompt`. Use `defaultContext: false` in builtin overrides to clear an inherited context default. Project overrides beat user overrides.\n\nSet `disabled: true` to hide a builtin from runtime discovery and agent-facing `subagent({ action: \"list\" })` output. For bulk control, set `subagents.disableBuiltins: true` in settings.\n\n### Prompt assembly\n\nSubagents are designed to be narrow by default. Custom agents start with a clean system prompt and only the context you intentionally give them. They do not automatically inherit Pi’s whole base prompt, project instruction files, or discovered skills catalog.\n\nUse these fields when an agent should see more:\n\n| Field | Effect |\n|-------|--------|\n| `systemPromptMode: append` | Append the agent prompt to Pi’s normal base prompt. |\n| `inheritProjectContext: true` | Keep inherited project instructions from files like `AGENTS.md` and `CLAUDE.md`. |\n| `inheritSkills: true` | Let the child see Pi’s discovered skills catalog. |\n| `defaultContext: fork` | Use forked session context when a launch omits `context`; explicit `context: \"fresh\"` still wins. |\n\nBuiltin agents opt into project instruction inheritance by default so they follow repo-specific rules out of the box. `delegate` also uses append mode because its job is orchestration inside the parent workflow.\n\n### Agent frontmatter\n\nA typical agent looks like this:\n\n```yaml\n---\nname: scout\n# Optional: registers this as code-analysis.scout while preserving name: scout\npackage: code-analysis\ndescription: Fast codebase recon\ntools: read, grep, find, ls, bash, mcp:chrome-devtools\nextensions:\nmodel: claude-haiku-4-5\nfallbackModels: openai\u002Fgpt-5-mini, anthropic\u002Fclaude-sonnet-4\nthinking: high\nsystemPromptMode: replace\ninheritProjectContext: false\ninheritSkills: false\nskills: safe-bash, chrome-devtools\noutput: context.md\ndefaultReads: context.md\ndefaultProgress: true\ninteractive: true\nmaxSubagentDepth: 1\n---\n\nYour system prompt goes here.\n```\n\nImportant fields:\n\n| Field | Notes |\n|-------|-------|\n| `package` | Optional package identifier. A file with `name: scout` and `package: code-analysis` registers as `code-analysis.scout`; serialization keeps `name` and `package` separate. |\n| `tools` | Builtin tool allowlist. `mcp:` entries select direct MCP tools when `pi-mcp-adapter` is installed. |\n| `extensions` | Omitted means normal extensions; empty means no extensions; comma-separated values allowlist specific extensions. |\n| `model` | Default model. Bare ids prefer the current provider when possible, then unique registry matches. |\n| `fallbackModels` | Ordered backup models for provider\u002Fmodel failures such as quota, auth, timeout, or unavailable model. Ordinary task failures do not trigger fallback. |\n| `thinking` | Appended as a `:level` suffix at runtime unless a suffix is already present. |\n| `systemPromptMode` | `replace` by default; `append` keeps Pi’s base prompt. |\n| `inheritProjectContext` | Keeps or strips inherited project instruction blocks. |\n| `inheritSkills` | Keeps or strips Pi’s discovered skills catalog. |\n| `defaultContext` | Optional `fresh` or `fork` launch context default for this agent. |\n| `skills` | Injects specific skills directly, regardless of `inheritSkills`. |\n| `output` | Default single-agent output file. |\n| `defaultReads` | Files to read before running in chain\u002Fparallel behavior. |\n| `defaultProgress` | Maintain `progress.md`. |\n| `interactive` | Parsed for compatibility but not enforced in v1. |\n| `maxSubagentDepth` | Tightens nested delegation for this agent’s children. |\n\n### Tool and extension selection\n\nIf `tools` is omitted, `pi-subagents` does not pass `--tools`, so the child gets Pi’s normal builtin tools. If `tools` is present, regular tool names become an explicit allowlist. `mcp:` entries are split out and forwarded as direct MCP selections. Path-like `tools` entries, such as extension paths or `.ts`\u002F`.js` files, are treated as tool-extension paths rather than builtin tool names.\n\nExamples:\n\n- `tools` omitted and `extensions` omitted: normal builtins and normal extensions.\n- `tools: mcp:chrome-devtools`: normal builtins plus direct Chrome DevTools MCP tools.\n- `tools: read, bash, mcp:chrome-devtools`: only `read` and `bash` as builtins, plus direct Chrome DevTools MCP tools.\n\nDirect MCP tools require [pi-mcp-adapter](https:\u002F\u002Fgithub.com\u002Fnicobailon\u002Fpi-mcp-adapter). Subagents only receive direct MCP tools when `mcp:` entries are listed in their frontmatter; global `directTools: true` in `mcp.json` is not enough by itself. The generic `mcp` proxy tool can still be used for discovery when available. The adapter caches tool metadata at startup, so after connecting a new MCP server for the first time, restart Pi before relying on direct tools.\n\n`extensions` controls child extension loading:\n\n```yaml\n# Omitted: all normal extensions load\n\n# Empty: no extensions\nextensions:\n\n# Allowlist\nextensions: \u002Fabs\u002Fpath\u002Fto\u002Fext-a.ts, \u002Fabs\u002Fpath\u002Fto\u002Fext-b.ts\n```\n\nWhen `extensions` is present, it takes precedence over extension paths implied by `tools` entries.\n\n## Chain files\n\nChains are reusable `.chain.md` workflows stored separately from agent files.\n\n| Scope | Path |\n|-------|------|\n| User | `~\u002F.pi\u002Fagent\u002Fchains\u002F**\u002F*.chain.md` |\n| Project | `.pi\u002Fchains\u002F**\u002F*.chain.md` |\n\nNested subdirectories are discovered recursively. If user and project scopes define the same parsed runtime chain name, the project chain wins. Chains support the same optional `package` frontmatter as agents; `name: review-flow` plus `package: code-analysis` runs as `code-analysis.review-flow`.\n\nExample:\n\n```md\n---\nname: scout-planner\ndescription: Gather context then plan implementation\n---\n\n## scout\noutput: context.md\n\nAnalyze the codebase for {task}\n\n## planner\nreads: context.md\nmodel: anthropic\u002Fclaude-sonnet-4-5:high\nprogress: true\n\nCreate an implementation plan based on {previous}\n```\n\nEach `## agent-name` section is a step. Config lines such as `output`, `outputMode`, `reads`, `model`, `skills`, and `progress` go immediately after the header. A blank line separates config from task text.\n\nFor `output`, `reads`, `skills`, and `progress`, chain behavior is three-state: omitted inherits from the agent, a value overrides, and `false` disables.\n\nCreate chains by writing `.chain.md` files directly or with the `subagent({ action: \"create\", config: ... })` management action. Run them with natural language or:\n\n```text\n\u002Frun-chain scout-planner -- refactor authentication\n```\n\n## Chain variables\n\nTask templates support:\n\n| Variable | Description |\n|----------|-------------|\n| `{task}` | Original task from the first step. |\n| `{previous}` | Output from the prior step, or aggregated output from a parallel step. |\n| `{chain_dir}` | Path to the chain artifact directory. |\n\nParallel outputs are aggregated with clear separators before being passed to the next step:\n\n```text\n=== Parallel Task 1 (worker) ===\n...\n\n=== Parallel Task 2 (worker) ===\n...\n```\n\n## Skills\n\nSkills are `SKILL.md` files injected into an agent’s system prompt.\n\nDiscovery uses project-first precedence:\n\n1. `.pi\u002Fskills\u002F{name}\u002FSKILL.md`\n2. Project packages and project settings packages via `package.json -> pi.skills`\n3. Current task cwd package via `package.json -> pi.skills`\n4. `.pi\u002Fsettings.json -> skills`\n5. `~\u002F.pi\u002Fagent\u002Fskills\u002F{name}\u002FSKILL.md`\n6. User packages and user settings packages via `package.json -> pi.skills`\n7. `~\u002F.pi\u002Fagent\u002Fsettings.json -> skills`\n\nUse agent defaults, override them at runtime, or disable them:\n\n```ts\n{ agent: \"scout\", task: \"...\" }\n{ agent: \"scout\", task: \"...\", skill: \"tmux, safe-bash\" }\n{ agent: \"scout\", task: \"...\", skill: false }\n```\n\nFor chains, `skill` at the top level is additive. A step-level `skill` overrides that step; `false` disables skills for that step.\n\nInjected skills use this shape:\n\n```xml\n\u003Cskill name=\"safe-bash\">\n[skill content from SKILL.md, frontmatter stripped]\n\u003C\u002Fskill>\n```\n\nMissing skills do not fail execution. The result summary shows a warning.\n\n### Bundled skill\n\nThe package bundles a `pi-subagents` skill that is automatically available to the parent agent when the extension is installed. It is for the orchestrating parent only: child subagents never receive it, and their context is explicitly filtered to strip parent-only orchestration instructions.\n\nWhat the bundled skill covers:\n- **Delegation patterns**: when to launch which agent, whether to use single, parallel, chain, or async mode, and whether to use fresh or forked context\n- **Prompt workflow recipes**: how to apply the packaged techniques directly with `subagent(...)` when the user describes the workflow in natural language instead of invoking a slash command. This includes parallel review, review-loop, parallel research, parallel context-build, parallel handoff-plan, gather-context-and-clarify, and parallel cleanup\n- **Role-agent prompting guidance**: compact contract prompts instead of long scripts, what to include in role-specific meta prompts, and retrieval budgets for researchers\n- **Safety boundaries**: child agents must not run subagents, must not invent intercom targets, and must escalate unapproved decisions\n- **Intercom conventions**: when to ask vs send, and how parent-side result delivery works with `pi-intercom`\n- **Control and diagnostics**: attention signals, soft interrupts, status, and the `doctor` action\n\nIf you are writing an agent that orchestrates subagents, the bundled skill helps it behave correctly without guessing the patterns. If you are a human user, you do not need to read it directly; the README and prompt shortcuts encode the same workflows in user-facing form.\n\n## Programmatic tool usage\n\nThese are the parameters the LLM passes when it calls the `subagent` tool. Most users ask naturally or use slash commands instead.\n\n### Execution examples\n\n```ts\n\u002F\u002F Single agent\n{ agent: \"worker\", task: \"refactor auth\" }\n{ agent: \"scout\", task: \"find todos\", maxOutput: { lines: 1000 } }\n{ agent: \"scout\", task: \"investigate\", output: false }\n{ agent: \"scout\", task: \"write a large report\", output: \"reports\u002Fscout.md\", outputMode: \"file-only\" }\n\n\u002F\u002F Forked context\n{ agent: \"worker\", task: \"continue this thread\", context: \"fork\" }\n\n\u002F\u002F Parallel\n{ tasks: [{ agent: \"scout\", task: \"a\" }, { agent: \"reviewer\", task: \"b\" }] }\n{ tasks: [{ agent: \"scout\", task: \"audit auth\", count: 3 }] }\n{ tasks: [{ agent: \"scout\", task: \"audit frontend\" }, { agent: \"reviewer\", task: \"audit backend\" }], context: \"fork\" }\n\n\u002F\u002F Chain\n{ chain: [\n  { agent: \"scout\", task: \"Gather context for auth refactor\" },\n  { agent: \"planner\" },\n  { agent: \"worker\" },\n  { agent: \"reviewer\" }\n]}\n\n\u002F\u002F Chain in the background, suitable for unblocking the main chat\n{ chain: [...], async: true }\n\n\u002F\u002F Chain with fan-out\u002Ffan-in\n{ chain: [\n  { agent: \"scout\", task: \"Gather context\" },\n  { parallel: [\n    { agent: \"worker\", task: \"Implement feature A from {previous}\" },\n    { agent: \"worker\", task: \"Implement feature B from {previous}\" }\n  ], concurrency: 2, failFast: true },\n  { agent: \"reviewer\", task: \"Review all changes from {previous}\" }\n]}\n\n\u002F\u002F Worktree isolation\n{ tasks: [\n  { agent: \"worker\", task: \"Implement auth\" },\n  { agent: \"worker\", task: \"Implement API\" }\n], worktree: true }\n```\n\n### Management actions\n\nAgent definitions are not loaded into context by default. Management actions let the LLM discover, inspect, create, update, and delete agents and chains at runtime.\n\n```ts\n{ action: \"list\" }\n{ action: \"list\", agentScope: \"project\" }\n{ action: \"get\", agent: \"scout\" }\n{ action: \"get\", agent: \"code-analysis.scout\" }\n{ action: \"get\", chainName: \"review-pipeline\" }\n\n{ action: \"create\", config: {\n  name: \"Code Scout\",\n  package: \"code-analysis\",\n  description: \"Scans codebases for patterns and issues\",\n  scope: \"user\",\n  systemPrompt: \"You are a code scout...\",\n  systemPromptMode: \"replace\",\n  inheritProjectContext: false,\n  inheritSkills: false,\n  model: \"anthropic\u002Fclaude-sonnet-4\",\n  fallbackModels: [\"openai\u002Fgpt-5-mini\", \"anthropic\u002Fclaude-haiku-4-5\"],\n  tools: \"read, bash, mcp:github\u002Fsearch_repositories\",\n  extensions: \"\",\n  skills: \"parallel-scout\",\n  thinking: \"high\",\n  output: \"context.md\",\n  reads: \"shared-context.md\",\n  progress: true\n}}\n\n{ action: \"create\", config: {\n  name: \"review-pipeline\",\n  description: \"Scout then review\",\n  scope: \"project\",\n  steps: [\n    { agent: \"scout\", task: \"Scan {task}\", output: \"context.md\" },\n    { agent: \"reviewer\", task: \"Review {previous}\", reads: [\"context.md\"] }\n  ]\n}}\n\n{ action: \"update\", agent: \"code-analysis.scout\", config: { model: \"openai\u002Fgpt-4o\" } }\n{ action: \"update\", chainName: \"review-pipeline\", config: { steps: [...] } }\n{ action: \"delete\", agent: \"scout\" }\n{ action: \"delete\", chainName: \"review-pipeline\" }\n```\n\n`create` uses `config.scope`, not `agentScope`. `config.name` is the local frontmatter name; optional `config.package` registers the runtime name as `{package}.{name}` and is saved as separate `name` and `package` frontmatter. `update` and `delete` use the runtime name and `agentScope` only when the same runtime name exists in multiple scopes. To clear optional string fields, including `package`, set them to `false` or `\"\"`.\n\n### Parameter reference\n\n| Param | Type | Default | Description |\n|-------|------|---------|-------------|\n| `agent` | string | - | Agent name for single mode, or target for management actions. |\n| `task` | string | - | Task string for single mode. |\n| `action` | string | - | `list`, `get`, `create`, `update`, `delete`, `status`, `interrupt`, `resume`, or `doctor`. |\n| `chainName` | string | - | Chain name for management actions. |\n| `config` | object\u002Fstring | - | Agent or chain config for create\u002Fupdate. |\n| `output` | `string \\| false` | agent default | Override single-agent output file. |\n| `outputMode` | `\"inline\" \\| \"file-only\"` | `inline` | Return saved output inline or as a concise saved-file reference. `file-only` requires an `output` path. |\n| `skill` | `string \\| string[] \\| false` | agent default | Override skills or disable all. |\n| `model` | string | agent default | Override model. |\n| `tasks` | array | - | Top-level parallel tasks. Supports `agent`, `task`, `cwd`, `count`, `output`, `outputMode`, `reads`, `progress`, `skill`, and `model`. |\n| `concurrency` | number | config or `4` | Top-level parallel concurrency. |\n| `worktree` | boolean | false | Create isolated git worktrees for parallel tasks. |\n| `chain` | array | - | Sequential and parallel chain steps. |\n| `context` | `fresh \\| fork` | agent default or `fresh` | `fork` creates real branched sessions from the parent leaf. Packaged `planner`, `worker`, and `oracle` default to `fork`. |\n| `chainDir` | string | temp chain dir | Persistent directory for chain artifacts. |\n| `clarify` | boolean | true for chains | Show TUI preview\u002Fedit flow. |\n| `agentScope` | `user \\| project \\| both` | `both` | Agent discovery scope. Project wins on collisions. |\n| `async` | boolean | false | Background execution. For chains, `clarify: true` explicitly keeps the run foreground for the clarify UI. |\n| `cwd` | string | runtime cwd | Override working directory. |\n| `maxOutput` | object | 200KB, 5000 lines | Final output truncation limits. |\n| `artifacts` | boolean | true | Write debug artifacts. |\n| `includeProgress` | boolean | false | Include full progress in result. |\n| `share` | boolean | false | Upload session export to GitHub Gist. |\n| `sessionDir` | string | derived | Override session log directory. |\n\n`context: \"fork\"` fails fast when the parent session is not persisted, the current leaf is missing, or the branched child session cannot be created. It never silently downgrades to `fresh`. In multi-agent runs, if any requested agent has `defaultContext: fork` and the launch omits `context`, the whole invocation uses forked context; pass `context: \"fresh\"` when you intentionally want a fresh run.\n\nUse `outputMode: \"file-only\"` when a saved output may be large and the parent only needs a pointer. The returned text is a compact reference like `Output saved to: \u002Fabs\u002Freport.md (48.2 KB, 2847 lines). Read this file if needed.` Failed runs and save errors still return normal inline output for debugging. In chains, later `{previous}` steps receive the same compact reference when the prior step used file-only mode.\n\nSequential and parallel chain tasks accept `agent`, `task`, `cwd`, `output`, `outputMode`, `reads`, `progress`, `skill`, and `model`. Parallel tasks also accept `count`. Parallel step groups accept `parallel`, `concurrency`, `failFast`, and `worktree`.\n\nStatus and control actions:\n\n```ts\nsubagent({ action: \"status\" })\nsubagent({ action: \"status\", id: \"\u003Crun-id>\" })\nsubagent({ action: \"interrupt\", id: \"\u003Crun-id>\" })\nsubagent({ action: \"resume\", id: \"\u003Crun-id>\", message: \"follow-up question\" })\nsubagent({ action: \"resume\", id: \"\u003Crun-id>\", index: 1, message: \"follow-up for child 2\" })\nsubagent({ action: \"doctor\" })\n```\n\n`resume` sends the follow-up directly when an async child is still reachable over intercom. After completion, it revives the child by starting a new async child from the stored child session file. Multi-child async runs and remembered foreground single, parallel, or chain runs can be revived by passing `index` to choose the child. Revive starts a new child process from the old session context; it does not restart the same OS process, and it requires the chosen child to have a persisted `.jsonl` session file.\n\n## Worktree isolation\n\nParallel agents can clobber each other if they edit the same checkout. `worktree: true` gives each parallel child its own git worktree branched from `HEAD`.\n\n```ts\n{ tasks: [\n  { agent: \"worker\", task: \"Implement auth\", count: 2 },\n  { agent: \"worker\", task: \"Implement API\" }\n], worktree: true }\n\n{ chain: [\n  { agent: \"scout\", task: \"Gather context\" },\n  { parallel: [\n    { agent: \"worker\", task: \"Implement feature A from {previous}\" },\n    { agent: \"worker\", task: \"Implement feature B from {previous}\" }\n  ], worktree: true },\n  { agent: \"reviewer\", task: \"Review all changes from {previous}\" }\n]}\n```\n\nRequirements:\n\n- run inside a git repo\n- working tree must be clean\n- `node_modules\u002F` is symlinked into each worktree when present\n- task-level `cwd` overrides must be omitted or match the shared cwd\n- configured `worktreeSetupHook` must return valid JSON before timeout\n\nAfter a worktree parallel step completes, per-agent diff stats are appended to the output and full patch files are written to artifacts. Worktrees and temp branches are cleaned up in `finally` blocks.\n\n## Configuration\n\n`pi-subagents` reads optional JSON config from `~\u002F.pi\u002Fagent\u002Fextensions\u002Fsubagent\u002Fconfig.json`.\n\n### `asyncByDefault`\n\n```json\n{ \"asyncByDefault\": true }\n```\n\nMakes top-level calls use background execution when the request does not explicitly set `async`. Callers can still force foreground with `async: false` unless `forceTopLevelAsync` is enabled.\n\n### `forceTopLevelAsync`\n\n```json\n{ \"forceTopLevelAsync\": true }\n```\n\nForces depth-0 single, parallel, and chain runs into background mode and bypasses clarify UI by forcing `clarify: false`. Nested calls keep their own inherited settings.\n\n### `parallel`\n\n```json\n{\n  \"parallel\": {\n    \"maxTasks\": 12,\n    \"concurrency\": 6\n  }\n}\n```\n\n`maxTasks` defaults to `8`; `concurrency` defaults to `4`. Per-call `concurrency` takes precedence.\n\n### `defaultSessionDir`\n\n```json\n{ \"defaultSessionDir\": \"~\u002F.pi\u002Fagent\u002Fsessions\u002Fsubagent\u002F\" }\n```\n\nSession directory precedence is: `params.sessionDir`, then `config.defaultSessionDir`, then a directory derived from the parent session. Sessions are always enabled.\n\n### `maxSubagentDepth`\n\n```json\n{ \"maxSubagentDepth\": 1 }\n```\n\nControls nested delegation when no inherited `PI_SUBAGENT_MAX_DEPTH` is already in effect. Per-agent `maxSubagentDepth` can tighten the limit for that agent’s child runs, but cannot relax an inherited stricter limit.\n\n### `intercomBridge`\n\n```json\n{\n  \"intercomBridge\": {\n    \"mode\": \"always\",\n    \"instructionFile\": \".\u002Fintercom-bridge.md\"\n  }\n}\n```\n\nControls whether subagents receive runtime intercom coordination instructions and whether `intercom` and `contact_supervisor` are auto-added to their tool allowlist when needed.\n\nFields:\n\n- `mode`: default `always`; use `fork-only` to inject only for forked runs, or `off` to disable the bridge.\n- `instructionFile`: optional Markdown template replacing the default bridge instructions. `{orchestratorTarget}` is interpolated. Relative paths resolve from `~\u002F.pi\u002Fagent\u002Fextensions\u002Fsubagent\u002F`.\n\nBridge activation also requires `pi-intercom` to be installed and enabled through `pi install npm:pi-intercom` or a legacy local extension checkout, a targetable current session name or fallback alias, and `pi-intercom` in any explicit agent `extensions` allowlist.\n\nThe default injected guidance tells children to use `contact_supervisor` with `reason: \"need_decision\"` when blocked or needing a decision, `reason: \"progress_update\"` only for meaningful blocked\u002Fprogress updates, generic `intercom` as fallback plumbing, and avoid routine completion handoffs.\n\n### `worktreeSetupHook`\n\n```json\n{\n  \"worktreeSetupHook\": \".\u002Fscripts\u002Fsetup-worktree.mjs\",\n  \"worktreeSetupHookTimeoutMs\": 45000\n}\n```\n\nThe hook runs once per created worktree. Paths must be absolute, `~\u002F...`, or repo-relative; bare command names are rejected.\n\nstdin is a JSON object with `repoRoot`, `worktreePath`, `agentCwd`, `branch`, `index`, `runId`, and `baseCommit`. stdout must be one JSON object, for example:\n\n```json\n{ \"syntheticPaths\": [\".venv\", \".env.local\"] }\n```\n\n`syntheticPaths` must be relative to the worktree root. They are removed before diff capture so helper files do not pollute patches. Tracked files are never excluded; marking a tracked path as synthetic fails setup. Default timeout is `30000` ms.\n\n## Files, logs, and observability\n\nEach chain run creates a user-scoped temp directory like:\n\n```text\n\u003Ctmpdir>\u002Fpi-subagents-\u003Cscope>\u002Fchain-runs\u002F{runId}\u002F\n```\n\nIt may contain files such as `context.md`, `plan.md`, `progress.md`, and `parallel-{stepIndex}\u002F...\u002Foutput.md`. Directories older than 24 hours are cleaned up on extension startup.\n\nDebug artifacts live under `{sessionDir}\u002Fsubagent-artifacts\u002F` or a user-scoped temp artifact directory. Per task you may see:\n\n- `{runId}_{agent}_input.md`\n- `{runId}_{agent}_output.md`\n- `{runId}_{agent}.jsonl`\n- `{runId}_{agent}_meta.json`\n\nMetadata records timing, usage, exit code, final model, attempted models, and fallback attempt outcomes.\n\nSession files are stored under a per-run session directory. With `context: \"fork\"`, each child starts with `--session \u003Cbranched-session-file>` produced from the parent’s current leaf. That is a real session fork, not an injected summary.\n\nAsync completions notify only the originating session. The result watcher emits `subagent:async-complete`, and the extension consumes that event to render completion notifications.\n\nAsync runs write:\n\n```text\n\u003Ctmpdir>\u002Fpi-subagents-\u003Cscope>\u002Fasync-subagent-runs\u002F\u003Cid>\u002F\n  status.json\n  events.jsonl\n  output-\u003Cn>.log\n  subagent-log-\u003Cid>.md\n```\n\n`status.json` powers the widget and `subagent({ action: \"status\" })` output. `events.jsonl` contains wrapper events plus child Pi JSON events annotated with run and step metadata. `output-\u003Cn>.log` is a live human-readable tail. Fallback information is persisted so background runs are debuggable after completion.\n\n## Live progress\n\nForeground runs show compact live progress for single, chain, and parallel modes: current tool, recent output, token counts, duration, activity freshness, and current-tool duration.\n\nPress `Ctrl+O` to expand the full streaming view with complete output per step.\n\nSequential chains show a flow line like `done scout → running planner`. Chains with parallel steps show per-step cards instead.\n\n## Session sharing\n\nPass `share: true` to export a full session to HTML, upload it to a secret GitHub Gist through your `gh` credentials, and return a `https:\u002F\u002Fshittycodingagent.ai\u002Fsession\u002F?\u003CgistId>` URL.\n\n```ts\n{ agent: \"scout\", task: \"...\", share: true }\n```\n\nThis is disabled by default. Session data may contain source code, paths, environment variables, credentials, or other sensitive output. You need `gh` installed and authenticated.\n\n## Recursion guard\n\nSubagents can call `subagent`, which can get expensive and hard to observe. A depth guard prevents unbounded nesting.\n\nBy default, nesting is limited to two levels: main session → subagent → sub-subagent. Deeper calls are blocked with guidance to complete the current task directly.\n\nConfigure the limit with:\n\n1. `PI_SUBAGENT_MAX_DEPTH` before starting Pi\n2. `config.maxSubagentDepth`\n3. `maxSubagentDepth` in agent frontmatter, which can only tighten the inherited limit\n\n```bash\nexport PI_SUBAGENT_MAX_DEPTH=3\nexport PI_SUBAGENT_MAX_DEPTH=1\nexport PI_SUBAGENT_MAX_DEPTH=0\n```\n\n`PI_SUBAGENT_DEPTH` is internal and propagated automatically. Do not set it manually.\n\n## Events\n\nAsync events:\n\n- `subagent:async-started`\n- `subagent:async-complete`\n\nIntercom delivery events:\n\n- `subagent:control-intercom`\n- `subagent:result-intercom`\n\nThe result watcher emits `subagent:async-complete`; `src\u002Fextension\u002Findex.ts` registers the notification handler that consumes it. Control\u002Fattention events are surfaced as visible parent notices and persisted for async runs. With `pi-intercom`, needs-attention notices and grouped parent-side subagent result deliveries can reach the orchestrator over intercom.\n\n## Prompt-template integration\n\n`pi-subagents` works standalone through natural language, the `subagent` tool, slash commands, and the packaged prompt shortcuts listed near the top of this README. If you use [pi-prompt-template-model](https:\u002F\u002Fgithub.com\u002Fnicobailon\u002Fpi-prompt-template-model), you can also wrap subagent delegation in your own reusable prompt templates.\n\nExample:\n\n```md\n---\ndescription: Take a screenshot\nmodel: claude-sonnet-4-20250514\nsubagent: browser-screenshoter\ncwd: \u002Ftmp\u002Fscreenshots\n---\nUse url in the prompt to take screenshot: $@\n```\n\nThen `\u002Ftake-screenshot https:\u002F\u002Fexample.com` switches to Sonnet, delegates to `browser-screenshoter` with `\u002Ftmp\u002Fscreenshots` as cwd, and restores your model when done. Runtime overrides like `--cwd=\u003Cpath>` and `--subagent=\u003Cname>` work too.\n\nFor more reusable workflows on top of subagents, including `\u002Fchain-prompts` and compare-style prompts such as `\u002Fbest-of-n`, install `pi-prompt-template-model` separately and copy the examples you want into `~\u002F.pi\u002Fagent\u002Fprompts\u002F`.\n\n## Runtime files\n\nThe main runtime files are:\n\n| File | Purpose |\n|------|---------|\n| `src\u002Fextension\u002Findex.ts` | Extension registration, tool registration, message\u002Frender wiring. |\n| `src\u002Fagents\u002Fagents.ts` | Agent and chain discovery, frontmatter parsing. |\n| `src\u002Fruns\u002Fforeground\u002Fsubagent-executor.ts` | Main execution routing for single, parallel, chain, management, status, interrupt, and doctor actions. |\n| `src\u002Fruns\u002Fforeground\u002Fexecution.ts` | Core foreground `runSync` handling. |\n| `src\u002Fruns\u002Fbackground\u002Fsubagent-runner.ts` | Detached async runner. |\n| `src\u002Fruns\u002Fbackground\u002Fasync-execution.ts` | Background launch support. |\n| `src\u002Fruns\u002Fbackground\u002Fasync-status.ts` | Status discovery and formatting for async runs. |\n| `src\u002Fruns\u002Fforeground\u002Fchain-execution.ts` \u002F `src\u002Fagents\u002Fchain-serializer.ts` | Chain orchestration and `.chain.md` parsing. |\n| `src\u002Fshared\u002Fsettings.ts` | Chain behavior, instructions, and config helpers. |\n| `src\u002Fruns\u002Fshared\u002Fworktree.ts` | Git worktree isolation. |\n| `src\u002Fintercom\u002Fintercom-bridge.ts` | Runtime intercom bridge instructions and diagnostics. |\n| `src\u002Fextension\u002Fschemas.ts` \u002F `src\u002Fshared\u002Ftypes.ts` | Tool schemas, shared types, and event constants. |\n| `test\u002Funit\u002F` \u002F `test\u002Fintegration\u002F` | Unit and loader-based integration tests. |\n","`pi-subagents`是一个用于异步子代理委派的Pi扩展，支持截断、工件处理和会话共享。该项目使用TypeScript编写，通过简单的自然语言命令即可让Pi创建专注于特定任务的子代理，如代码审查、实现、并行审计等，从而提高工作效率。其核心功能包括子代理的任务分配、结果反馈以及并行或链式运行模式的支持，特别适用于需要多模型视角辅助的开发场景，比如在代码审查过程中希望获得多个角度的意见，或者是在解决问题时寻求额外的建议。此工具无需复杂的配置过程，安装后即可快速上手使用。",2,"2026-06-11 03:51:49","high_star"]