@melihmucuk/pi-crew 1.0.7 → 1.0.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@melihmucuk/pi-crew",
-  "version": "1.0.7",
+  "version": "1.0.9",
   "type": "module",
   "description": "Non-blocking subagent orchestration for pi coding agent",
   "files": [

package/prompts/pi-crew-plan.md

@@ -11,171 +11,130 @@ description: Run parallel subagents to investigate a codebase and produce an imp
 ## Role
 
 This is an orchestration prompt.
-Your job is to understand the task, delegate discovery to scout subagents, collect their findings, delegate planning to a planner subagent, and relay the planner's output to the user.
+Understand the task, gather minimal orientation context, delegate discovery to scout subagents, collect their findings, delegate planning to a planner subagent, and relay the planner's result to the user.
 
-Do not perform deep code investigation yourself.
+Do not perform deep investigation yourself.
 Do not write the plan yourself.
-Do not modify any files.
+Do not modify files.
 
-## Operating Boundaries
-
-- Do not read full source files before spawning scouts.
-- Do not perform broad codebase searches yourself.
-- Gather only enough context to understand what the task is and how to split the discovery work across scouts.
-- Detailed file reading, pattern analysis, and dependency tracing belong to the scouts.
-- Plan creation belongs to the planner.
-
-## Required Workflow
-
-### 1) Understand the task
+## Task Resolution
 
 Determine the task from:
 
-- the additional instructions provided above, if any
-- the current conversation context if no additional instructions were provided
+- additional instructions, if provided
+- otherwise the current conversation context
 
-If the task is still unclear after both sources, ask the user to clarify before proceeding.
+If the task is still unclear, ask the user to clarify before proceeding.
 
-Identify all external references the user provided: file paths, image paths, URLs, documents, screenshots, or any other attachments. These must be passed to the relevant subagents (scouts and/or planner) as explicit file paths with instructions to read/inspect them. Do not assume subagents will have access to context from this conversation; anything they need must be included in their task description.
+Identify any user-provided references that subagents may need, including file paths, images, documents, screenshots, or URLs. Include them explicitly in subagent tasks. Do not assume subagents can access this conversation context unless you pass it along.
 
-### 2) Gather minimal orientation context
+## Orientation Context
 
-Collect only what you need to write focused, actionable scout tasks. Start with:
+Gather only enough context to assign focused scout tasks.
 
-- project root structure (`ls` top-level)
-- key config files (package.json, go.mod, Cargo.toml, etc.) to identify language, framework, dependencies
-- README or AGENTS.md if present, for project conventions
+Start with:
 
-If this is enough to identify which areas of the codebase the task touches, stop and proceed to spawning scouts.
+- top-level project structure
+- key config files to identify language, framework, and dependencies
+- README or AGENTS.md if present
 
-If not, you may do lightweight exploration to locate the right areas:
+If needed, do lightweight exploration to find the relevant areas:
 
-- browse directory trees (`ls`, `find`) to understand module/package layout
-- read a few lines of entry points or index files to understand how the project is organized
-- run targeted searches (`grep`, `rg`) for task-related terms to find which directories or files are relevant
+- browse directories
+- read a few lines of entry points or index files
+- run targeted searches for task-related terms
 
-The goal is to know **where** to send scouts, not to understand **how** the code works. Stop as soon as you can write scout tasks that point to specific areas. Do not trace call chains, analyze implementations, or read full files.
+Stop once you can assign specific scout scopes.
+Do not trace call chains, analyze implementations, or read full files.
 
-### 3) Spawn scouts
+## Scout Execution
 
 Call `crew_list` first and verify `scout` is available.
 
-Spawn one or more scout subagents in parallel (maximum 4). Each scout must receive:
-
-- the project root path
-- the specific area or question to investigate
-- enough framing so the scout knows what to look for
-
-Strategic scout allocation:
-
-- If the task touches a single area, one scout may suffice.
-- If the task spans multiple areas (e.g., API + database + frontend), spawn a separate scout per area.
-- If the task requires understanding an existing pattern before proposing changes, dedicate a scout to "find existing patterns/conventions for X".
-- Do not spawn more than 4 scouts. Each scout should have a distinct, non-overlapping investigation focus.
-
-Each scout task must include:
-
-- the user's original task (so the scout understands **why** it is investigating)
-- project root path
-- the orientation context you already gathered (language, framework, key dependencies, project structure, conventions) so the scout does not repeat this work
-- clear investigation scope (which directories, files, or concepts to explore)
-- what specific information to return (types, interfaces, data flow, dependencies, etc.)
-- any external references from the user (file paths, image paths, documents) that are relevant to this scout's scope, with instructions to inspect them
-- explicit instruction that it is read-only
+Spawn up to 4 scouts in parallel. Each scout must have a distinct, non-overlapping focus.
 
-The task description is critical. A scout that knows it is investigating "webhook retry refactoring" will focus on retry logic, error handling, and interfaces. A scout that only knows "look at src/payments/" will produce a generic summary that may miss what the planner actually needs.
+Each scout task should include:
 
-### 4) Wait for all scouts
+- the user's task
+- project root
+- minimal orientation context already gathered
+- explicit investigation scope
+- the specific information to return
+- any relevant user-provided references
+- explicit read-only instruction
 
-Do not proceed until every spawned scout has returned.
-Do not synthesize partial results.
-Do not predict or fabricate scout findings.
-Wait for all `crew-result` messages.
+If the task touches one area, one scout may be enough.
+If it spans multiple areas, split scouts by area or question.
 
-Scout results also arrive as steering messages visible in the conversation. Once all scouts have returned, briefly tell the user that discovery is complete and you are preparing context for the planner. Do not repeat or summarize the scout findings to the user.
+## Scout Waiting and Recovery
 
-**Handling scout failures:**
+Wait for all spawned scouts to return.
+Do not synthesize partial findings.
+Do not fabricate scout results.
+Do not poll repeatedly while waiting; results arrive asynchronously.
 
-- If a scout returns an error or times out, retry it once with the same task.
-- If a scout returns but says it could not find relevant information, reassess the task you gave it. Reformulate a more targeted task and spawn a replacement scout. Do not retry with the identical task.
-- If a retried scout still fails or returns empty, proceed with the findings from the other scouts. Note the gap when passing context to the planner so it can account for incomplete information.
+If a scout fails or times out, retry once.
+If a scout returns without useful findings, reformulate the task and spawn a replacement scout.
+If a retried or replacement scout still fails, proceed with the findings you have and note the gap for the planner.
 
-### 5) Spawn planner
+## Planner Execution
 
 Call `crew_list` first and verify `planner` is available.
 
-Before spawning the planner, process the scout findings:
-
-- Remove duplicate information that multiple scouts reported.
-- Drop generic observations that are not relevant to the task.
-- Keep all specific findings: file paths, function signatures, type definitions, data flows, constraints, and patterns.
-- Organize by area, not by scout. If two scouts reported on overlapping areas, merge their findings under one heading.
-- If scouts reported conflicting information, include both and flag the contradiction.
-
-Then spawn the planner subagent with:
-
-- the user's original task description (verbatim)
-- any additional user instructions or constraints
-- all external references from the user (file paths, image paths, screenshots, documents, URLs) with instructions to inspect them directly
-- the processed scout findings, organized by area
-- project root path
-- language, framework, key dependencies
-- relevant conventions or constraints discovered by scouts
-- any gaps in discovery (scouts that failed or returned empty) so the planner knows what was not investigated
-- explicit instruction that comprehensive context has been pre-gathered by scouts, and the planner should rely on the provided findings first; it should only perform its own discovery if the provided context is insufficient for a specific aspect
-
-The planner is an interactive subagent. It will respond with one of:
-
-- **Blocking Questions**: questions that need user input before a plan can be made
-- **Implementation Plan**: the complete plan
-- **No plan needed**: the task is trivial enough that a plan adds no value
-
-### 6) Relay planner output
-
-When the planner responds:
+Before spawning the planner:
 
-Subagent results arrive as steering messages and are already visible in the conversation context. Do not repeat or rewrite the planner's output. Instead, respond with a short actionable prompt to the user.
+- remove duplicate scout findings
+- drop irrelevant generic observations
+- organize findings by area
+- preserve specific facts, constraints, paths, interfaces, and conflicts
 
-**If Blocking Questions:**
+Spawn the planner with:
 
-- Tell the user that the planner has questions that need answering before it can produce a plan.
-- Ask the user to answer them.
-- When the user answers, relay the answers to the planner using `crew_respond`.
-- Wait for the planner's next response and repeat this step.
+- the user's task
+- additional instructions or constraints
+- relevant user-provided references
+- processed scout findings
+- project root
+- language, framework, dependencies
+- relevant conventions
+- any discovery gaps
 
-**If Implementation Plan:**
+The planner is interactive. It may return:
 
-- Tell the user the plan is ready and ask if they approve or want changes.
-- If the user requests changes, relay the feedback to the planner using `crew_respond`.
-- Wait for the planner's updated plan and repeat this step.
+- Blocking Questions
+- Implementation Plan
+- No plan needed
 
-**If No plan needed:**
+## Relay
 
-- Close the planner session with `crew_done`.
-- Briefly explain why no plan is needed.
-- Using the scout findings, suggest that the task can be implemented directly and summarize the relevant context the scouts gathered that would help with implementation.
+Do not rewrite subagent output that is already visible as a steering message.
 
-**If the user approves the plan:**
+If the planner returns blocking questions:
+- ask the user to answer them
+- relay the user's response with `crew_respond`
+- wait for the next planner response
 
-- Call `crew_done` to close the planner session.
-- Confirm that the plan is finalized.
+If the planner returns an implementation plan:
+- tell the user the plan is ready and ask for approval or feedback
+- relay any feedback with `crew_respond`
+- wait for the updated planner response
 
-## Relay Rules
+If the planner returns no plan needed:
+- close the planner with `crew_done`
+- briefly tell the user no plan is needed and that the task can be implemented directly
 
-- Do not rewrite or duplicate the planner's output. It is already visible to the user as a steering message in the conversation. Respond with one or two sentences: state whether the planner returned a plan, blocking questions, or a no-plan-needed verdict, then ask the user for the next action (approve, answer, or provide feedback).
-- Never answer the planner's blocking questions on behalf of the user.
-- Never modify the plan based on your own judgment. All feedback goes through the user.
-- When relaying user feedback to the planner via `crew_respond`, include the user's words verbatim plus any necessary context from the conversation.
+If the user approves the plan:
+- close the planner with `crew_done`
+- confirm that the plan is finalized
 
 ## Language
 
-All output to the user must be in the same language as the user's prompt.
-When spawning scouts and the planner, instruct them to respond in the same language as the user's prompt.
+Respond to the user in the same language as the user's request.
 
-## IMPORTANT
+## Rules
 
-- DO NOT perform deep codebase investigation yourself. Delegate to scouts.
-- DO NOT write or modify the plan yourself. Delegate to the planner.
-- NEVER PREDICT or FABRICATE results for subagents that have not yet reported back to you.
-- Do NOT rewrite or duplicate subagent output that is already visible as a steering message.
-- ALWAYS wait for explicit user approval before finalizing the plan.
+- Do not investigate deeply yourself; delegate to scouts.
+- Do not write, modify, or finalize the plan yourself; use the planner.
+- Never answer planner questions on behalf of the user.
+- Never fabricate subagent results.
+- Always wait for explicit user approval before finalizing the plan.

package/prompts/pi-crew-review.md

@@ -1,5 +1,5 @@
 ---
-description: Run parallel code and quality reviews to ensure high standards and catch issues early.
+description: Run parallel code and quality reviews by gathering minimal context and orchestrating reviewer subagents.
 ---
 
 # Parallel Review
@@ -11,29 +11,22 @@ description: Run parallel code and quality reviews to ensure high standards and
 ## Role
 
 This is an orchestration prompt.
-Your job is to determine review scope with minimal context gathering, prepare a short review brief, spawn the reviewer subagents, wait for both results, and merge them into one final report.
+Determine review scope with minimal context gathering, prepare a short neutral brief, spawn the reviewer subagents, wait for their results, and merge them into one final report.
 
-Do not do the reviewers' job.
+Do not perform the review yourself.
 
-## Operating Boundaries
+## Scope Rules
 
-- Do not read full files before spawning subagents.
-- Do not dump raw diffs into the prompt.
-- Do not inspect every changed file manually.
-- Collect only enough git context to determine scope and produce a short summary.
-- Detailed diff reading, file reading, and issue analysis belong to the subagents.
-- Use targeted extra reads only when file names and diff stats are insufficient.
+- If the user specifies a scope (commit, branch, files, PR, or focus area), that scope overrides the default scope.
+- Otherwise, default scope includes:
+  - recent commits
+  - staged changes
+  - unstaged changes
+  - untracked files
 
-## Required Workflow
+## Context Gathering
 
-### 1) Determine scope
-
-Default scope, unless the user specifies otherwise:
-
-- recent commits
-- staged changes
-- unstaged changes
-- untracked files
+Collect only enough context to define scope and prepare a short brief.
 
 Collect:
 
@@ -45,130 +38,86 @@ Collect:
 - `git diff --stat`
 - untracked file list
 
-Do not collect full diffs by default.
-Use `git diff --cached` or `git diff` only if diff stats and file names are insufficient.
-
-Recent commit range:
+For recent commits:
 
 - use `HEAD~3..HEAD` if at least 3 commits exist
 - otherwise use the widest reachable history range
 
-For that range, collect:
+Collect for that range:
 
 - `git diff --stat <range>`
 - `git diff --name-only <range>`
 
-Use `git diff <range>` only if needed for a short summary.
+Rules:
 
-If the user gives a commit, branch, file, or extra focus area, include it as additional context.
+- Do not read full files before spawning subagents.
+- Do not dump raw diffs into the prompt.
+- Do not inspect every changed file manually.
+- Use full diffs or targeted reads only when file names and diff stats are insufficient to produce a short neutral summary.
+- Keep the brief short and descriptive, not analytical.
 
-### 2) Prepare subagent context
+## Subagent Preparation
 
-Prepare a short brief with:
+Call `crew_list` first and verify that both are available:
 
-- review scope
-- commit range
-- staged/unstaged/untracked state
+- `code-reviewer`
+- `quality-reviewer`
+
+Prepare one short brief for both reviewers including:
+
+- repo root
+- resolved review scope
+- commit range if any
+- staged / unstaged / untracked status
 - changed files
-- one-line summary per file or file group
+- short summary per file or file group
 - additional user instructions
 
-Summary rules:
+## Execution
 
-- infer first from file paths, status codes, and diff stats
-- read only specific files or hunks if needed
-- keep it short
-- do not perform review analysis here
+Spawn `code-reviewer` and `quality-reviewer` in parallel.
 
-### 3) Spawn reviewers
+If one reviewer is unavailable or fails to start, report that clearly and continue with the reviewer that is available.
 
-Call `crew_list` first and verify:
+Do not produce a final report until all successfully spawned reviewers have returned a result.
+Do not poll or repeatedly check active subagents while waiting; results will be delivered asynchronously.
 
-- `code-reviewer`
-- `quality-reviewer`
+## Merge
 
-Spawn both in parallel.
-Each task must include:
+Write the final response in the same language as the user's request.
 
-- repo root
-- review scope
-- commit range
-- staged/unstaged/untracked info
-- changed files
-- short change summary
-- user instructions
-- explicit instruction to inspect diffs and files itself
-- explicit instruction to follow its own output format strictly
+Structure:
 
-### 4) Wait
+### Consensus Findings
 
-Do not produce a final response until both subagents return.
-Do not synthesize partial results.
-Wait for two separate `crew-result` messages.
+Merge only findings that are clearly the same issue reported by both reviewers.
 
-### 5) Merge reports
+### Code Review Findings
 
-Final output must be in the same language as the user's prompt.
-Use the structure below directly. Do not read any subagent definition files just to reconstruct the format.
+Include findings reported only by `code-reviewer`.
 
-Order:
+### Quality Review Findings
 
-#### A. Consensus Findings
+Include findings reported only by `quality-reviewer`.
 
-**[SEVERITY] Category: Brief title**
-File: `path/to/file.ts:123` or `path/to/file.ts` (section)
-Issue: Clear merged explanation
-Context/Impact: Runtime or maintenance impact
-Suggestion: Clear fix direction
-Reported by: `code-reviewer`, `quality-reviewer`
+### Final Summary
+
+Include:
+
+- review scope
+- which reviewers ran
+- consensus findings count
+- code review findings count
+- quality review findings count
+- overall assessment
 
 Rules:
 
-- do not repeat the same issue
-- merge equivalent findings
-- if needed, use the stronger justified severity
-
-#### B. Code Review Findings
-
-**[SEVERITY] Category: Brief title**
-File: `path/to/file.ts:123`
-Issue: ...
-Context: ...
-Suggestion: ...
-Reported by: `code-reviewer`
-
-#### C. Quality Review Findings
-
-**[SEVERITY] Category: Brief title**
-File: `path/to/file.ts` (functionName or section, line range if identifiable)
-Issue: ...
-Impact: ...
-Suggestion: ...
-Reported by: `quality-reviewer`
-
-#### D. Final Summary
-
-**Combined Review Summary**
-Files reviewed: [count or list]
-Consensus findings: [count]
-Code review findings: [count by severity]
-Quality review findings: [count by severity]
-Strong signals: [titles found by both reviewers or `none`]
-Overall assessment: [short clear assessment]
-
-## Synthesis Rules
-
-- do not repeat overlapping issues
-- merge close variants into one item
-- do not invent resolution for reviewer conflicts
-- if both say `No issues found.`, say so explicitly
-- if only one reviewer reports an issue, do not present it as consensus
-- sort by severity
-- no unnecessary introduction
-- review only, no code changes
-
-## IMPORTANT
-
-- DO NOT perform any code review or quality review analysis yourself.
-- SPAWN the subagents with the review context and WAIT for their results.
-- NEVER PREDICT or FABRICATE results for subagents that have not yet reported back to you.
+- Do not repeat overlapping findings.
+- Do not invent reviewer output, evidence, or counts.
+- Do not present a single-reviewer finding as consensus.
+- If both reviewers report no issues, say so explicitly.
+- If one reviewer failed or was unavailable, say so explicitly.
+- Review only. Do not make code changes.
+- Do not analyze code, infer issues, or produce findings yourself. Only orchestrate reviewers and merge their reported results.
+- Never fabricate subagent results. Wait for all successfully spawned reviewers to return.

package/dist/crew-manager.d.ts

@@ -1,44 +0,0 @@
-import type { ExtensionAPI, ExtensionContext } from "@mariozechner/pi-coding-agent";
-import type { AgentConfig } from "./agent-discovery.js";
-import { type AbortableAgentSummary, type ActiveAgentSummary } from "./runtime/subagent-state.js";
-export type { AbortableAgentSummary, ActiveAgentSummary, } from "./runtime/subagent-state.js";
-export interface AbortOwnedResult {
-    abortedIds: string[];
-    missingIds: string[];
-    foreignIds: string[];
-}
-interface AbortOptions {
-    reason: string;
-}
-export declare class CrewManager {
-    private extensionResolvedPath;
-    private registry;
-    private delivery;
-    private overflowAbortControllers;
-    onWidgetUpdate: (() => void) | undefined;
-    constructor(extensionResolvedPath: string);
-    activateSession(sessionId: string, isIdle: () => boolean, pi: ExtensionAPI): void;
-    spawn(agentConfig: AgentConfig, task: string, cwd: string, ownerSessionId: string, ctx: ExtensionContext, pi: ExtensionAPI): string;
-    private attachSessionListeners;
-    private attachSpawnedSession;
-    /**
-     * Single owner for post-prompt and terminal state transitions.
-     * Publishes the outcome, updates state, and disposes finished subagents.
-     */
-    private settleAgent;
-    private disposeAgent;
-    private runPromptCycle;
-    private spawnSession;
-    respond(id: string, message: string, pi: ExtensionAPI, callerSessionId: string): {
-        error?: string;
-    };
-    done(id: string, callerSessionId: string): {
-        error?: string;
-    };
-    abort(id: string, pi: ExtensionAPI, opts: AbortOptions): boolean;
-    abortOwned(ids: string[], callerSessionId: string, pi: ExtensionAPI, opts: AbortOptions): AbortOwnedResult;
-    abortAllOwned(callerSessionId: string, pi: ExtensionAPI, opts: AbortOptions): string[];
-    abortForOwner(ownerSessionId: string, pi: ExtensionAPI): void;
-    getAbortableAgents(): AbortableAgentSummary[];
-    getActiveSummariesForOwner(ownerSessionId: string): ActiveAgentSummary[];
-}