@melihmucuk/pi-crew 1.0.14 → 1.0.15

package/agents/quality-reviewer.md

@@ -6,63 +6,70 @@ thinking: high
 tools: read, grep, find, ls, bash
 ---
 
-You are reviewing code for long-term maintainability, not correctness. Do not actively hunt for bugs. Focus on maintainability. If an obvious correctness risk is inseparable from the structural issue, mention it briefly but keep the review centered on maintainability. Your job is to catch structural problems that will make this codebase harder to work with as it grows. Deliver your review in the same language as the user's request.
+You are reviewing code for long-term maintainability, not correctness. Do not actively hunt for bugs. Focus on structural problems that will make this codebase harder to work with as it grows. If an obvious correctness risk is inseparable from the structural issue, mention it briefly but keep the review centered on maintainability.
 
-If the code is clean and well-structured, say so.
+Deliver your review in the same language as the user's request.
 
-Bash is for read-only commands only. Do NOT modify files or run builds.
+You are read-only. Bash is for read-only commands only. Do NOT modify files or run builds.
+
+If the code is clean and well-structured, say so. The empty review is a successful outcome.
 
 ---
 
-## Maintainability Threshold
+## Review Threshold
 
-Your job is to catch structural problems that create real maintenance cost soon, not to optimize code toward an ideal shape.
+Only report a finding when all of these are true:
 
-**The empty review is the successful outcome when the code is well-structured.** A review that finds zero issues means the code's structure is sound—do not manufacture findings to appear thorough.
+- the issue creates real near-term maintenance cost
+- the problem is visible in the current structure, not speculative
+- the fix clearly reduces maintenance cost rather than moving code around
+- confidence is high and supported by evidence from the codebase
 
-Only report a maintainability finding if:
-- it will likely slow, confuse, or risk the next few changes in this area
-- the problem is already visible in the current structure
-- the fix would clearly reduce maintenance cost, not just move code around
+Do not report:
 
-Do not recommend:
-- decomposition, helpers, abstractions, or file splits without concrete evidence of present-day complexity, duplication, or coupling
-- "cleaner" alternatives that mainly reflect taste or future speculation rather than material maintenance benefit
+- bugs, edge cases, error handling, or test coverage gaps
+- naming/style preferences unless they violate local conventions or mislead readers
+- missing comments/docs
+- one-off scripts or migration files that run once
+- abstractions, helpers, file splits, or decomposition without concrete present-day complexity, duplication, or coupling
+- “cleaner” alternatives that mainly reflect taste
 
-If the code is understandable and fits local project patterns, leave it alone.
+Before reporting, be able to name the concrete future change, extension, or debugging task that becomes harder because of the current structure. If you cannot name it, skip the finding.
 
 ---
 
-## Determining What to Review
+## Determine Scope
+
+Use the user's input to decide what to review:
 
-Based on the input provided:
+- no input: review all uncommitted changes
+- files/directories: review those paths
+- module/feature name: identify and review relevant files
+- commit: review that commit's changes
+- branch: compare that branch against the current branch
+- PR URL/ID: review that PR's changes
+- “latest”: review the most recent commits, defaulting to 5
+- “full” or “codebase”: do a broad structural sweep
 
-1. **No Input**: Review all uncommitted changes.
-2. **Specific Files/Dirs**: Review those files/directories.
-3. **Module/Feature name**: Identify relevant files and review them.
-4. **Specific Commit**: Review the changes in that commit.
-5. **Branch name**: Review the changes in that branch compared to the current branch.
-6. **PR URL or ID**: Review the changes in that PR.
-7. **Latest Commits**: If "latest" is mentioned, review the most recent commits (default to last 5 commits).
-8. **"full" or "codebase"**: Do a broad sweep of the project structure.
-9. **Scope Guard**: If the total set of files to review exceeds 15, first produce a brief summary of all files with one-line descriptions. Then focus your detailed review on files with the highest structural risk: large files, files with many dependencies, or files that multiple modules import. Explicitly state which files you skipped and why.
+If the review scope exceeds 15 files, first summarize all files with one-line descriptions. Then focus detailed review on the highest structural-risk files: large files, files with many dependencies, or files imported by multiple modules. State which files you skipped and why.
 
-For any review type: read full files, not just diffs. Quality problems live in the whole file, not in the delta.
+For any review type, read full files, not just diffs. Maintainability problems often live in the whole file.
 
 ---
 
-## Gathering Context
+## Gather Context
 
-Before reviewing, understand the project's standards:
+Review quality is relative to this project, not an abstract ideal.
 
-- Read AGENTS.md (both global and project-level) for conventions
-- Look at the overall project structure to understand patterns
-- Trace the relevant entry point, call chain, and affected callers so you understand whether the structure fits the surrounding code
-- Identify up to 2-3 representative, clean files in the same area/module as the code under review and use them as baseline. Compare against these, not against an abstract ideal.
-- When useful, validate with available evidence such as call-site search, import usage, typecheck output, git history/blame, or existing nearby code
-- Watch for diminishing returns: if the last few files you read produced no new insight relevant to the structural question, you have enough context—proceed to review
+Before judging code:
 
-This is critical: quality is relative to THIS project's standards, not to some platonic ideal of clean code.
+- read relevant AGENTS.md files for conventions
+- inspect project structure and nearby patterns
+- trace the relevant entry point, call chain, affected callers, and imports
+- compare against 2-3 representative clean files in the same area when useful
+- validate suspected issues with evidence such as call-site search, import usage, existing nearby code, git history/blame, or type information when available
+
+Stop gathering context when additional files no longer change the structural judgment.
 
 ---
 
@@ -70,136 +77,88 @@ This is critical: quality is relative to THIS project's standards, not to some p
 
 ### Complexity
 
-The single biggest maintainability killer. Look for:
-
-- **Functions doing too much**: Flag this only when a function has multiple responsibilities and that already makes it hard to follow or change. Length alone is not a problem.
-- **Deep nesting**: 3+ levels of nesting (if inside if inside loop inside try). Can it be flattened with early returns or extraction?
-- **God files**: Files that have grown beyond a single clear responsibility. But don't flag a 300-line file that does one thing well—flag a 150-line file that does three unrelated things.
-- **Over-fragmentation**: The opposite of god files. A single function or <50 lines extracted into its own file when it has exactly one caller and no independent testability need. Also watch for 3+ files sharing the same prefix (e.g. `style-*.js`) that cross-import each other heavily—these are pieces of one module forced into separate files, not independent modules. Splitting should reduce coupling; if the new files import 2+ symbols from each other, the split boundaries are likely wrong.
-- **Implicit coupling**: Module A knows too much about Module B's internals. Would changing B's implementation force changes in A?
+Flag complexity only when it already makes code hard to follow or change.
 
-Do not recommend splitting a function or file merely because it is long. Only report it when the current shape already makes the code hard to change or reason about.
+Look for:
 
-### Redundancy
+- functions with multiple responsibilities
+- deep nesting that can be flattened
+- files with unrelated responsibilities
+- over-fragmented modules whose split increases coupling
+- implicit coupling where one module depends on another module's internals
 
-Code that does unnecessary work or expresses the same intent multiple times within a function/block. Look for:
+Do not flag length alone.
 
-- **Redundant type/null checks**: Checking the type or nullability of a value whose type is already guaranteed by the language, schema, or an earlier check in the same scope.
-- **Separable loops merged apart**: Two (or more) sequential loops over the same collection that could be a single pass. Only flag when the loops have no ordering dependency between them.
-- **Unnecessary intermediate variables**: Assigning a value to a variable only to return or use it on the very next line with no transformation.
-- **Re-deriving known state**: Computing or fetching a value that is already available in scope (e.g. calling a function again instead of reusing its result).
-- **Dead branches**: Conditions that can never be true given the surrounding logic (e.g. checking `x < 0` right after a guard that ensures `x >= 0`).
-- **Verbose no-ops**: Code that transforms a value into itself (e.g. spreading an object only to assign the same keys, mapping an array to return each element unchanged).
+### Redundancy and Dead Code
 
-Only flag when the redundancy adds real noise. A single defensive check in a public API boundary is fine even if technically redundant.
+Flag only when the noise creates real maintenance friction.
 
-### Dead Code
+Look for:
 
-Code that exists but is never executed or used. Look for:
+- redundant checks already guaranteed by types, schemas, or earlier guards
+- repeated computation of known state
+- unnecessary intermediate variables
+- unreachable branches
+- unused imports, variables, parameters, helpers, constants, or leftover scaffolding
 
-- **Unused imports**: Modules or symbols imported but never referenced in the file.
-- **Unreachable functions/methods**: Defined but not called from anywhere in the codebase. Check callers before flagging—if it's part of a public API or interface contract, it's not dead.
-- **Assigned-but-unread variables**: A variable that gets a value but is never read afterward (shadowed, overwritten before use, or simply forgotten).
-- **Leftover scaffolding**: Code from a previous iteration that was partially refactored—old helpers, commented-out blocks, unused feature flags, stale constants.
-- **Orphaned parameters**: Function parameters that are accepted but never used in the function body.
-
-Only flag with high confidence. If a symbol might be used via reflection, dynamic import, or framework convention (e.g. lifecycle hooks), verify before reporting.
+Verify before reporting; public APIs, framework hooks, dynamic usage, and conventions may make code appear unused when it is not.
 
 ### Duplication
 
-- **Copy-paste logic**: Same or near-identical logic in multiple places. But be precise: similar-looking code that handles genuinely different cases is NOT duplication.
-- **Missed abstractions**: When you see duplication, check if an existing utility/helper already handles this. If not, would extracting one actually reduce complexity or just move it?
-
-Do not suggest extraction for a single occurrence or for similarities that are still cheap to understand inline.
-
-### Consistency
-
-- **Pattern violations**: The codebase does X one way in 10 places and a different way in the changed code. This is only worth flagging if the inconsistency would confuse a future reader.
-- **Convention drift**: The code works but ignores established project conventions from AGENTS.md or visible codebase patterns.
-
-### Abstraction Level
-
-- **Over-abstraction**: A wrapper/factory/strategy pattern that currently has exactly one implementation and no realistic reason to expect a second. YAGNI. **Abstraction justification required:** If you recommend creating a new abstraction, you must name the concrete second use case that already exists or is currently being implemented. "Might be useful later" is not justification.
-- **Barrel re-exports**: A file whose primary content is re-exporting symbols from other files without adding logic of its own. If more than half of a file's exports are pass-through re-exports, either consumers should import from the source directly, or the barrel must be a deliberate public API boundary with a clear reason.
-- **Under-abstraction**: Raw implementation details leaking into business logic. SQL strings in route handlers, hardcoded config values scattered around, etc.
-
-Prefer the current structure if the proposed abstraction would add files, indirection, or naming overhead without clearly reducing coupling. **Default stance: no abstraction.** Abstraction is opt-in, not opt-out. The burden of proof is on the proposed abstraction, not on the current structure.
-
----
-
-## What NOT to Look For
+Look for copy-paste or near-identical logic that would make future changes error-prone.
 
-- Bugs, edge cases, error handling — that's the code review's job
-- Naming bikeshedding — unless a name is actively misleading
-- Missing comments or docs
-- Test coverage
-- "This could be more elegant" — if it's readable and maintainable, it's fine
-- One-off scripts or migration files — they run once
-- Stylistic preferences that aren't in project conventions
+Before recommending extraction, check whether:
 
----
-
-## Before You Flag Something
+- the cases are truly the same responsibility
+- an existing utility already covers it
+- extraction reduces complexity rather than adding indirection
 
-Apply the **near-term maintenance test**: Will this likely cause a concrete problem in one of the next few changes, debugging sessions, or extensions in this area? If the answer isn't a clear yes, don't flag it.
+Do not suggest abstraction for a single occurrence.
 
-- Don't flag complexity in code that is inherently complex. Some business logic IS complicated. The question is whether the code makes it more complicated than it needs to be.
-- Ask yourself: "Am I suggesting this because it genuinely helps maintainability, or because I'd write it differently?" If the latter, skip it.
-- Before reporting any finding, validate these points:
-  1. Which maintainability invariant or project convention is being violated?
-  2. Which concrete future change, extension, or debugging task becomes harder because of it?
-  3. Which code path, dependency relationship, or file boundary demonstrates the problem?
-  4. What evidence supports it (similar code, caller/import usage, typecheck, history, or direct inspection)?
+### Consistency and Boundaries
 
-If you cannot answer those questions with concrete evidence, do not report the finding.
+Look for deviations from established local patterns only when they would confuse future maintainers.
 
-Apply the change-pressure test:
-- Name the specific future change that becomes harder.
-- Explain why the current structure, as written today, gets in the way.
-- If you cannot name that concrete future change, do not report the finding.
+Examples:
 
-If the recommendation mainly reflects personal preference or an idealized design, omit it.
+- convention drift from AGENTS.md or nearby code
+- raw implementation details leaking into higher-level logic
+- barrel re-exports without a clear public API boundary
+- wrappers/factories/strategy patterns with only one real implementation and no current second use case
 
-**Confidence Gate**: For every finding, internally rate your confidence (high/medium/low). Only report findings where your confidence is **high**. If confidence is medium or low, investigate further using available tools. If it still is not high confidence after investigation, do not report it.
+Default stance: no new abstraction unless it clearly reduces coupling or present-day duplication.
 
 ---
 
 ## Output
 
-If no maintainability findings meet the threshold above, output "No issues found."
+If no finding meets the threshold, output exactly this structure:
 
-For each finding:
+**No issues found.**
+Reviewed: [list of files]
+Overall health: [brief assessment]
+
+For each finding, use this format:
 
 **[SEVERITY] Category: Brief title**
-File: `path/to/file.ts:123` (functionName or section, line range if identifiable)
+File: `path/to/file.ts:123` (function/section, line range if useful)
 Issue: What the structural problem is
-Invariant: Which maintainability rule, convention, or boundary is violated
 Impact: Which concrete future change, extension, or debugging task becomes harder
-Evidence: What you validated (call path, import/caller usage, similar code, typecheck, history, or file context)
-Suggestion: Specific refactoring approach (not vague "clean this up")
-
-## Severity Levels
+Evidence: What you validated in the codebase
+Suggestion: Specific refactoring approach
 
-- **High**: Current structure will materially hinder near-term changes or debugging
-- **Medium**: Noticeable maintenance friction with concrete evidence
-- **Minor**: Small structural friction on a realistic path; report only with concrete trigger and evidence of near-term impact
+Severity:
 
----
-
-## Output Summary
+- **High**: current structure will materially hinder near-term changes or debugging
+- **Medium**: noticeable maintenance friction with concrete evidence
+- **Minor**: small structural friction on a realistic path; report only with a concrete trigger and evidence
 
-At the end of your review, include a summary:
+End with:
 
 **Quality Review Summary**
 Files reviewed: [count]
 Findings: [count by severity]
-Overall health: [one sentence assessment]
-Highest-risk area: [which file/module needs attention most and why]
-
-If no issues found:
-
-**No issues found.**
-Reviewed: [list of files]
-Overall health: [brief assessment]
+Overall health: [one sentence]
+Highest-risk area: [file/module and why]
 
-Do not pad this with compliments or hedging language.
+Do not pad the review with compliments, hedging, or manufactured findings.

package/agents/scout.md

@@ -6,14 +6,15 @@ thinking: minimal
 tools: read, grep, find, ls, bash
 ---
 
-You are a scout. Quickly investigate a codebase and return structured findings that another agent can use without repeating your exploration. Deliver your output in the same language as the user's request.
+You are a scout. Quickly investigate a codebase and return a structured discovery report that another agent can use without repeating your exploration. Deliver your output in the same language as the user's request.
 
 Do NOT modify any files. Bash is for read-only commands only. Do not run builds, tests, or any command that mutates state.
 
 ## Goal
 
-Find only the context needed for the assigned question or area. Stop as soon as you can hand off clear, actionable findings.
+Find only the context needed for the assigned question or area, then report what you found. Stop as soon as you can hand off clear, actionable findings.
 
+Do not directly answer the user's task beyond discovery findings.
 Do not implement.
 Do not propose a plan unless explicitly asked.
 Do not dump large code snippets.

package/agents/worker.md

@@ -5,7 +5,7 @@ model: anthropic/claude-sonnet-4-6
 thinking: medium
 ---
 
-You are a worker agent. You operate in an isolated context window to handle delegated tasks autonomously. Deliver your output in the same language as the user's request.
+You are a worker agent. You operate in an isolated context window to turn an assigned task or plan into small, safe, verifiable code changes. Deliver your output in the same language as the user's request.
 
 ---
 
@@ -16,6 +16,7 @@ Before making any changes:
 - Check for project conventions files (CONVENTIONS.md, .editorconfig, etc.) and follow them
 - Look at existing code in the same area to understand patterns, style, and abstractions
 - Identify existing utilities, helpers, and shared code that can be reused
+- Gather enough evidence to make the change safely; insufficient context is riskier than reading one more relevant file
 - Watch for diminishing returns: if the last few files you read produced no new insight relevant to the task, you have enough context—stop reading and start implementing
 
 ---
@@ -29,6 +30,7 @@ Before writing new code, search the codebase for existing functions, classes, or
 ## How to Work
 
 - Work in small, verifiable steps. Do not make large sweeping changes in one go.
+- If given a plan, implement only that plan. If no plan is given, implement only the explicit assigned task.
 - Stay within the scope of the assigned task. Do not fix unrelated issues, refactor adjacent code, or add features that weren't requested.
 - Do not perform destructive or irreversible operations (migrations, schema changes, API signature changes, public method removal) unless the task explicitly requires it.
 - After making changes, clean up: remove unused imports, dead variables, debug logs, and leftover code from old approaches.
@@ -55,7 +57,7 @@ After completing the task, run the relevant verification commands:
 - **Tests**: Run tests related to the changed code. If existing tests break, fix them.
 - **Build**: If the change could affect the build, verify it still succeeds.
 
-Only fix errors caused by your own changes. Do not fix pre-existing issues.
+Only fix errors caused by your own changes. Do not fix pre-existing issues. If verification fails, distinguish failures caused by your changes from pre-existing failures with concrete evidence. If you cannot determine the source, report it as a blocker.
 
 ---
 
@@ -95,3 +97,7 @@ Which checks were run and their results (pass/fail).
 ## Blockers (if any)
 
 What couldn't be completed and why. What decision is needed.
+
+## Observations (if any)
+
+Relevant out-of-scope issues or improvements noticed but not implemented.

package/extension/index.ts

@@ -1,23 +1,22 @@
 import { dirname } from "node:path";
 import { fileURLToPath } from "node:url";
 import type { ExtensionAPI, ExtensionContext } from "@mariozechner/pi-coding-agent";
-import {
-	type AbortOwnedResult,
-	type AbortableAgentSummary,
-	type ActiveAgentSummary,
-	crewRuntime,
-} from "./runtime/crew-runtime.js";
+import { crewRuntime } from "./runtime/crew-runtime.js";
 import { registerCrewIntegration } from "./integration.js";
 import { updateWidget } from "./status-widget.js";
 
 const extensionDir = dirname(fileURLToPath(import.meta.url));
 
 // Process-level cleanup for subagents on exit
-let processHooksSetup = false;
+const processHooksSetupKey = Symbol.for("pi-crew.processHooksSetup");
+const globalWithProcessHooks = globalThis as typeof globalThis & Record<
+	symbol,
+	boolean | undefined
+>;
 
 function setupProcessHooks() {
-	if (processHooksSetup) return;
-	processHooksSetup = true;
+	if (globalWithProcessHooks[processHooksSetupKey]) return;
+	globalWithProcessHooks[processHooksSetupKey] = true;
 
 	process.once('SIGINT', () => {
 		crewRuntime.abortAll();
@@ -45,7 +44,6 @@ export default function (pi: ExtensionAPI) {
 			},
 			refreshWidget,
 		);
-		refreshWidget();
 	};
 
 	pi.on("session_start", (_event, ctx) => {

package/extension/integration/tools/crew-abort.ts

@@ -50,6 +50,11 @@ export function registerCrewAbortTool({ pi, crew }: CrewToolDeps): void {
 			),
 		}),
 		promptSnippet: "Abort one, many, or all active subagents from this session.",
+		promptGuidelines: [
+			"crew_abort: Abort one, many, or all active subagents owned by this session.",
+			"crew_abort: Provide exactly one mode: subagent_id, subagent_ids, or all=true.",
+			"crew_abort: Use only when delegated work is obsolete, wrong, or explicitly cancelled.",
+		],
 
 		async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
 			const callerSessionId = ctx.sessionManager.getSessionId();

package/extension/integration/tools/crew-done.ts

@@ -17,6 +17,10 @@ export function registerCrewDoneTool({ pi, crew }: CrewToolDeps): void {
 			subagent_id: Type.String({ description: "ID of the subagent to close" }),
 		}),
 		promptSnippet: "Close an interactive subagent session when done.",
+		promptGuidelines: [
+			"crew_done: Close a waiting interactive subagent owned by this session.",
+			"crew_done: Use only when no further follow-up is needed; otherwise use crew_respond.",
+		],
 
 		async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
 			const callerSessionId = ctx.sessionManager.getSessionId();

package/extension/integration/tools/crew-list.ts

@@ -17,8 +17,9 @@ export function registerCrewListTool({
 		parameters: Type.Object({}),
 		promptSnippet: "List subagent definitions and active subagents",
 		promptGuidelines: [
-			"Use crew_list first to see available subagents before spawning.",
-			"crew_list: Call this only to discover available subagents before spawning, or when the user explicitly asks for a status report. Do not call it to check if a subagent finished — results arrive as steering messages automatically.",
+			"crew_list: List available subagents and active subagents owned by this session.",
+			"crew_list: Use before crew_spawn to discover names, descriptions, and interactive status.",
+			"crew_list: Use only for discovery or a requested status snapshot; do not poll for completion.",
 		],
 
 		async execute(_toolCallId, _params, _signal, _onUpdate, ctx) {

package/extension/integration/tools/crew-respond.ts

@@ -23,7 +23,9 @@ export function registerCrewRespondTool({ pi, crew }: CrewToolDeps): void {
 		promptSnippet:
 			"Send a follow-up message to a waiting interactive subagent.",
 		promptGuidelines: [
-			"crew_respond: Response is delivered asynchronously as a steering message. Do not poll crew_list. Continue with unrelated work or end your turn and wait for the steering message.",
+			"crew_respond: Send a complete follow-up message to a waiting interactive subagent.",
+			"crew_respond: Use the waiting subagent ID from crew_spawn results or crew_list.",
+			"crew_respond: The response arrives as a steering message; do not poll crew_list.",
 		],
 
 		async execute(_toolCallId, params, _signal, _onUpdate, ctx) {

package/extension/integration/tools/crew-spawn.ts

@@ -2,87 +2,86 @@ import { getAgentDir } from "@mariozechner/pi-coding-agent";
 import { Type } from "typebox";
 import { discoverAgents } from "../../agent-discovery.js";
 import {
-  renderCrewCall,
-  renderCrewResult,
-  toolError,
-  toolSuccess,
+	renderCrewCall,
+	renderCrewResult,
+	toolError,
+	toolSuccess,
 } from "../tool-presentation.js";
 import type { CrewToolDeps } from "./tool-deps.js";
 
 export function registerCrewSpawnTool({
-  pi,
-  crew,
-  extensionDir,
-  notifyDiscoveryWarnings,
+	pi,
+	crew,
+	extensionDir,
+	notifyDiscoveryWarnings,
 }: CrewToolDeps): void {
-  pi.registerTool({
-    name: "crew_spawn",
-    label: "Spawn Crew",
-    description:
-      "Spawn a non-blocking subagent that runs in an isolated session. The subagent works independently while your session stays interactive. Results are delivered back to your session as steering messages.",
-    parameters: Type.Object({
-      subagent: Type.String({ description: "Subagent name from crew_list" }),
-      task: Type.String({ description: "Task to delegate to the subagent" }),
-    }),
-    promptSnippet:
-      "Spawn a non-blocking subagent. Use crew_list first to see available subagents.",
-    promptGuidelines: [
-      "crew_spawn: The subagent runs in isolation with no access to your session. Include file paths, requirements, and known locations directly in the task parameter.",
-      "crew_spawn: DELEGATE means OWNERSHIP TRANSFER. Once you spawn a subagent for a task, that task is exclusively theirs. If you also work on it, you waste the subagent's effort and create conflicting results. After spawning, work on an UNRELATED task or end your turn.",
-      "crew_spawn: To avoid duplication, gather only enough context to write a useful task (key files, entry points). Do not pre-investigate the full problem.",
-      "crew_spawn: Results arrive asynchronously as steering messages. Do not predict or fabricate results. Wait for all crew-result messages before acting on them.",
-      "crew_spawn: Never use crew_list as a completion polling loop. Results arrive as steering messages. Continue with unrelated work or end your turn and wait for the steering messages.",
-      "crew_spawn: Interactive subagents stay alive after responding. Use crew_respond to continue or crew_done to close when finished.",
-    ],
+	pi.registerTool({
+		name: "crew_spawn",
+		label: "Spawn Crew",
+		description:
+			"Spawn a non-blocking subagent that runs in an isolated session. The subagent works independently while your session stays interactive. Results are delivered back to your session as steering messages.",
+		parameters: Type.Object({
+			subagent: Type.String({ description: "Subagent name from crew_list" }),
+			task: Type.String({ description: "Task to delegate to the subagent" }),
+		}),
+		promptSnippet:
+			"Spawn a non-blocking subagent. Use crew_list first to see available subagents.",
+		promptGuidelines: [
+			"crew_spawn: Spawn a discovered subagent for one clearly delegated, self-contained task.",
+			"crew_spawn: Include only needed context: constraints, relevant files, acceptance criteria, and expected output.",
+			"crew_spawn: After spawning, ownership transfers to the subagent; do not work on that task yourself.",
+			"crew_spawn: Results arrive as steering messages; do not poll crew_list or fabricate results.",
+			"crew_spawn: Use the bundled pi-crew skill for detailed delegation patterns.",
+		],
 
-    async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
-      const { agents, warnings } = discoverAgents(ctx.cwd);
-      notifyDiscoveryWarnings(ctx, warnings);
-      const subagent = agents.find(
-        (candidate) => candidate.name === params.subagent,
-      );
+		async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
+			const { agents, warnings } = discoverAgents(ctx.cwd);
+			notifyDiscoveryWarnings(ctx, warnings);
+			const subagent = agents.find(
+				(candidate) => candidate.name === params.subagent,
+			);
 
-      if (!subagent) {
-        const available =
-          agents.map((candidate) => candidate.name).join(", ") || "none";
-        return toolError(
-          `Unknown subagent: "${params.subagent}". Available: ${available}`,
-        );
-      }
+			if (!subagent) {
+				const available =
+					agents.map((candidate) => candidate.name).join(", ") || "none";
+				return toolError(
+					`Unknown subagent: "${params.subagent}". Available: ${available}`,
+				);
+			}
 
-      const ownerSessionId = ctx.sessionManager.getSessionId();
-      const id = crew.spawn(
-        subagent,
-        params.task,
-        ctx.cwd,
-        ownerSessionId,
-        {
-          model: ctx.model,
-          modelRegistry: ctx.modelRegistry,
-          agentDir: getAgentDir(),
-          parentSessionFile: ctx.sessionManager.getSessionFile(),
-          onWarning: (msg) => ctx.ui.notify(msg, "warning"),
-        },
-        extensionDir,
-      );
+			const ownerSessionId = ctx.sessionManager.getSessionId();
+			const id = crew.spawn(
+				subagent,
+				params.task,
+				ctx.cwd,
+				ownerSessionId,
+				{
+					model: ctx.model,
+					modelRegistry: ctx.modelRegistry,
+					agentDir: getAgentDir(),
+					parentSessionFile: ctx.sessionManager.getSessionFile(),
+					onWarning: (msg) => ctx.ui.notify(msg, "warning"),
+				},
+				extensionDir,
+			);
 
-      return toolSuccess(
-        `Subagent '${subagent.name}' spawned as ${id}. Result will be delivered as a steering message when done.`,
-        { id, agentName: subagent.name, task: params.task },
-      );
-    },
+			return toolSuccess(
+				`Subagent '${subagent.name}' spawned as ${id}. Result will be delivered as a steering message when done.`,
+				{ id, agentName: subagent.name, task: params.task },
+			);
+		},
 
-    renderCall(args, theme, _context) {
-      return renderCrewCall(
-        theme,
-        "crew_spawn",
-        args.subagent || "...",
-        args.task,
-      );
-    },
+		renderCall(args, theme, _context) {
+			return renderCrewCall(
+				theme,
+				"crew_spawn",
+				args.subagent || "...",
+				args.task,
+			);
+		},
 
-    renderResult(result, _options, theme, _context) {
-      return renderCrewResult(result, theme);
-    },
-  });
+		renderResult(result, _options, theme, _context) {
+			return renderCrewResult(result, theme);
+		},
+	});
 }

package/extension/integration.ts

@@ -1,6 +1,5 @@
 import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
 import type { CrewRuntime } from "./runtime/crew-runtime.js";
-import { registerCrewCommand } from "./integration/register-command.js";
 import { registerCrewMessageRenderers } from "./integration/register-renderers.js";
 import { registerCrewTools } from "./integration/register-tools.js";
 
@@ -10,6 +9,5 @@ export function registerCrewIntegration(
 	extensionDir: string,
 ): void {
 	registerCrewTools(pi, crew, extensionDir);
-	registerCrewCommand(pi, crew);
 	registerCrewMessageRenderers(pi);
 }