@melihmucuk/pi-crew 1.0.8 → 1.0.10

package/dist/integration/tools/crew-list.js

@@ -15,26 +15,16 @@ export function registerCrewListTool({ pi, crew, notifyDiscoveryWarnings, }) {
             const callerSessionId = ctx.sessionManager.getSessionId();
             const running = crew.getActiveSummariesForOwner(callerSessionId);
             const lines = [];
-            lines.push("## Available subagents");
+            lines.push("## Available Subagents");
             if (agents.length === 0) {
                 lines.push("No valid subagent definitions found. Add `.md` files to `<cwd>/.pi/agents/` or `~/.pi/agent/agents/`.");
             }
             else {
                 for (const agent of agents) {
                     lines.push("");
-                    lines.push(`**${agent.name}**`);
-                    if (agent.description)
-                        lines.push(`  ${agent.description}`);
-                    if (agent.model)
-                        lines.push(`  model: ${agent.model}`);
-                    if (agent.interactive)
-                        lines.push("  interactive: true");
-                    if (agent.tools !== undefined) {
-                        lines.push(`  tools: ${agent.tools.length > 0 ? agent.tools.join(", ") : "none"}`);
-                    }
-                    if (agent.skills !== undefined) {
-                        lines.push(`  skills: ${agent.skills.length > 0 ? agent.skills.join(", ") : "none"}`);
-                    }
+                    lines.push(`name: ${agent.name}`);
+                    lines.push(`description: ${agent.description}`);
+                    lines.push(`interactive: ${agent.interactive ? "true" : "false"}`);
                 }
             }
             if (warnings.length > 0) {
@@ -45,7 +35,7 @@ export function registerCrewListTool({ pi, crew, notifyDiscoveryWarnings, }) {
                 }
             }
             lines.push("");
-            lines.push("## Active subagents");
+            lines.push("## Active Subagents");
             if (running.length === 0) {
                 lines.push("No subagents currently active.");
             }
@@ -53,9 +43,11 @@ export function registerCrewListTool({ pi, crew, notifyDiscoveryWarnings, }) {
                 for (const agent of running) {
                     const icon = STATUS_ICON[agent.status] ?? "❓";
                     lines.push("");
-                    lines.push(`**${agent.id}** (${agent.agentName}) — ${icon} ${agent.status}`);
-                    lines.push(`  task: ${agent.taskPreview}`);
-                    lines.push(`  turns: ${agent.turns}`);
+                    lines.push(`id: ${agent.id}`);
+                    lines.push(`name: ${agent.agentName}`);
+                    lines.push(`status: ${icon} ${agent.status}`);
+                    lines.push(`task: ${agent.taskPreview}`);
+                    lines.push(`turns: ${agent.turns}`);
                 }
             }
             const text = lines.join("\n");

package/dist/integration/tools/crew-respond.js

@@ -12,6 +12,9 @@ export function registerCrewRespondTool({ pi, crew }) {
             message: Type.String({ description: "Message to send to the subagent" }),
         }),
         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.",
+        ],
         async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
             const callerSessionId = ctx.sessionManager.getSessionId();
             const { error } = crew.respond(params.subagent_id, params.message, callerSessionId);

package/dist/integration/tools/crew-spawn.js

@@ -14,9 +14,10 @@ export function registerCrewSpawnTool({ pi, crew, extensionDir, notifyDiscoveryW
         promptGuidelines: [
             "Use crew_list first to see available subagents before spawning.",
             "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 STOP. After spawning, either work on an UNRELATED task or end your turn. Never continue the delegated task yourself.",
+            "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. Wait for the steering message.",
             "crew_spawn: Interactive subagents stay alive after responding. Use crew_respond to continue and crew_done to close when finished.",
         ],
         async execute(_toolCallId, params, _signal, _onUpdate, ctx) {

package/package.json

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

package/prompts/pi-crew-plan.md

@@ -11,171 +11,147 @@ 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. Watch for diminishing returns: if the last few files or directories you browsed produced no new insight relevant to scoping, you have enough orientation—proceed to assign scouts.
+Do not trace call chains, analyze implementations, or read full files.
 
-### 3) Spawn scouts
+### Scope Extraction
 
-Call `crew_list` first and verify `scout` is available.
+Before assigning any scout tasks, extract the scope boundary from the user's task:
 
-Spawn one or more scout subagents in parallel (maximum 4). Each scout must receive:
+- **What the task requires** (in scope)
+- **What the task does NOT require** (out of scope)
+- **Scope assumptions** (if any)
 
-- the project root path
-- the specific area or question to investigate
-- enough framing so the scout knows what to look for
+Pass this scope boundary explicitly to every scout and to the planner. This gives subagents an explicit contract to check against, rather than having them infer scope from the task description alone.
 
-Strategic scout allocation:
+## Scout Execution
 
-- 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.
+Call `crew_list` first and verify `scout` is available.
 
-Each scout task must include:
+Spawn up to 4 scouts in parallel. Each scout must have a distinct, non-overlapping focus.
 
-- 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
+Each scout task should include:
 
-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.
+- the user's task
+- project root
+- minimal orientation context already gathered
+- **explicit scope boundary** (what's in scope and out of scope for this scout)
+- explicit investigation scope
+- the specific information to return
+- any relevant user-provided references
+- explicit read-only instruction
 
-### 4) Wait for all scouts
+Keep scout scopes narrow and non-overlapping. A scout that is asked to "investigate the auth system" will explore broadly. A scout that is asked to "find how login tokens are generated and which function validates them" will stay focused. Prefer the latter.
 
-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
+- drop findings outside the scope boundary (scouts sometimes drift)
+- organize findings by area
+- preserve specific facts, constraints, paths, interfaces, and conflicts
+- watch for diminishing returns: if later findings repeat or add no new specifics, you have enough—proceed to the planner rather than processing further
 
-**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
+- **explicit scope boundary** (in-scope / out-of-scope as extracted from the task)
+- 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.
+- Do not expand scope beyond what the user asked. If scouts return findings outside the task scope, drop them before passing to the planner.

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,23 @@ 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.
+Do not perform a broad second review or re-investigate the whole repository. Your job is orchestration, filtering, and merging. If a reviewer finding is ambiguous, high-impact, or appears out of scope, you may do a minimal spot-check to clarify whether it is concrete enough to include.
 
-## 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.
-
-## Required Workflow
+- 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
 
-### 1) Determine scope
+## Context Gathering
 
-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 +39,110 @@ 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.
+- Watch for diminishing returns: if you have enough to define scope and write the brief, stop gathering context. More git commands or file reads at this stage add noise, not clarity.
 
-### 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
+- **explicit scope boundary**: what is being reviewed (in scope) and what is not being reviewed (out of scope). For example: "Only the auth module changes are in scope. The unrelated CSS refactor in the same PR is out of scope for this review."
 
-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`
+## Findings Acceptance Gate
 
-Spawn both in parallel.
-Each task must include:
+Before including a reviewer finding in the final report, apply these filters:
 
-- 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
+Include a finding only if:
+- it is actionable now
+- it describes a realistic scenario for this project
+- it includes a concrete trigger or maintenance impact
+- it includes evidence or a clear rationale from the reviewer
+- its severity matches the described likelihood and impact
+
+Exclude findings that are:
+- speculative or theory-driven (no realistic trigger)
+- based on broken invariants or unsupported usage
+- style preferences or optional refactors without concrete bug risk
+- vague suggestions without concrete trigger, impact, or evidence
+
+Do not exclude a legitimate Minor finding that has a concrete trigger and realistic near-term impact. Minor findings with evidence pass the gate; Minor findings without evidence do not.
 
-### 4) Wait
+If a finding clearly fails the gate, omit it rather than forwarding reviewer noise to the user. Prefer omission for weak or optional findings, but do not discard a potentially important finding solely because the reviewer wrote it imperfectly. The merged report should be shorter and more impactful than the raw reviewer outputs, not a concatenation of them.
 
-Do not produce a final response until both subagents return.
-Do not synthesize partial results.
-Wait for two separate `crew-result` messages.
+## Merge
 
-### 5) Merge reports
+Write the final response in the same language as the user's request.
 
-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.
+Structure:
 
-Order:
+### Consensus Findings
 
-#### A. Consensus Findings
+Merge only findings that are clearly the same issue reported by both reviewers.
 
-**[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`
+### Code Review Findings
+
+Include findings reported only by `code-reviewer`.
+
+### Quality Review Findings
+
+Include findings reported only by `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.
+- Apply the Findings Acceptance Gate before merging. Do not forward weak, speculative, or optional findings; if a single-reviewer finding appears important but ambiguous, do a minimal spot-check before deciding.
+- 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 perform independent review beyond minimal scope and validity checks on reviewer findings. Only orchestrate reviewers and merge their reported results.
+- Never fabricate subagent results. Wait for all successfully spawned reviewers to return.

package/dist/prompt-injection.d.ts

@@ -1,8 +0,0 @@
-import type { AgentConfig } from "./agent-discovery.js";
-/**
- * Format discovered agent definitions for inclusion in the system prompt.
- * Uses XML format consistent with pi's skill injection.
- *
- * Returns an empty string when no agents are available.
- */
-export declare function formatAgentsForPrompt(agents: AgentConfig[]): string;