@melihmucuk/pi-crew 1.0.3 → 1.0.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -8,10 +8,18 @@ Non-blocking subagent orchestration for [pi](https://pi.dev). Spawn isolated sub
8
8
 
9
9
  ## Install
10
10
 
11
+ From npm:
12
+
11
13
  ```bash
12
14
  pi install npm:@melihmucuk/pi-crew
13
15
  ```
14
16
 
17
+ From git:
18
+
19
+ ```bash
20
+ pi install git:github.com/melihmucuk/pi-crew
21
+ ```
22
+
15
23
  This installs the extension, bundled prompt template, and bundled subagent definitions. Bundled subagents are automatically discovered and ready to use without any extra setup.
16
24
 
17
25
  ## Architecture
@@ -73,6 +81,13 @@ Closes an interactive subagent session owned by the current session when you no
73
81
  Aborts a running subagent. Supports tab completion for subagent IDs.
74
82
  Unlike the `crew_abort` tool, this command is intentionally unrestricted and works as an emergency escape hatch across sessions.
75
83
 
84
+ ### `/pi-crew-plan`
85
+
86
+ Expands a bundled prompt template that orchestrates discovery and planning for implementation tasks.
87
+ Use it to spawn scout subagents to investigate the codebase, then delegate to a planner subagent to produce a step-by-step implementation plan.
88
+
89
+ Note: This prompt requires the `scout` and `planner` subagent definitions. These are included as bundled subagents and work out of the box.
90
+
76
91
  ### `/pi-crew-review`
77
92
 
78
93
  Expands a bundled prompt template that orchestrates parallel code and quality reviews.
package/dist/index.js CHANGED
@@ -1,27 +1,49 @@
1
1
  import { dirname } from "node:path";
2
2
  import { fileURLToPath } from "node:url";
3
+ import { discoverAgents } from "./agent-discovery.js";
3
4
  import { CrewManager } from "./crew-manager.js";
4
5
  import { registerCrewIntegration } from "./integration.js";
6
+ import { formatAgentsForPrompt } from "./prompt-injection.js";
5
7
  import { updateWidget } from "./status-widget.js";
6
8
  const extensionDir = dirname(fileURLToPath(import.meta.url));
7
9
  export default function (pi) {
8
10
  const crewManager = new CrewManager(extensionDir);
9
11
  let currentCtx;
12
+ let cachedPromptSuffix = "";
10
13
  const refreshWidget = () => {
11
14
  if (currentCtx)
12
15
  updateWidget(currentCtx, crewManager);
13
16
  };
17
+ const rebuildPromptCache = (cwd) => {
18
+ const { agents } = discoverAgents(cwd);
19
+ cachedPromptSuffix = formatAgentsForPrompt(agents);
20
+ };
14
21
  const activateSession = (ctx) => {
15
22
  currentCtx = ctx;
16
23
  crewManager.activateSession(ctx.sessionManager.getSessionId(), () => ctx.isIdle(), pi);
17
24
  refreshWidget();
18
25
  };
19
26
  crewManager.onWidgetUpdate = refreshWidget;
20
- pi.on("session_start", (_event, ctx) => activateSession(ctx));
27
+ pi.on("session_start", (_event, ctx) => {
28
+ rebuildPromptCache(ctx.cwd);
29
+ activateSession(ctx);
30
+ });
21
31
  pi.on("session_switch", (_event, ctx) => activateSession(ctx));
22
32
  pi.on("session_fork", (_event, ctx) => activateSession(ctx));
23
33
  pi.on("session_shutdown", (_event, ctx) => {
24
34
  crewManager.abortForOwner(ctx.sessionManager.getSessionId(), pi);
25
35
  });
36
+ pi.on("before_agent_start", (event) => {
37
+ if (!cachedPromptSuffix)
38
+ return;
39
+ const marker = "\nCurrent date: ";
40
+ const idx = event.systemPrompt.lastIndexOf(marker);
41
+ if (idx === -1) {
42
+ return { systemPrompt: event.systemPrompt + cachedPromptSuffix };
43
+ }
44
+ const before = event.systemPrompt.slice(0, idx);
45
+ const after = event.systemPrompt.slice(idx);
46
+ return { systemPrompt: before + cachedPromptSuffix + after };
47
+ });
26
48
  registerCrewIntegration(pi, crewManager);
27
49
  }
@@ -0,0 +1,8 @@
1
+ import type { AgentConfig } from "./agent-discovery.js";
2
+ /**
3
+ * Format discovered agent definitions for inclusion in the system prompt.
4
+ * Uses XML format consistent with pi's skill injection.
5
+ *
6
+ * Returns an empty string when no agents are available.
7
+ */
8
+ export declare function formatAgentsForPrompt(agents: AgentConfig[]): string;
@@ -0,0 +1,39 @@
1
+ function escapeXml(str) {
2
+ return str
3
+ .replace(/&/g, "&")
4
+ .replace(/</g, "&lt;")
5
+ .replace(/>/g, "&gt;")
6
+ .replace(/"/g, "&quot;")
7
+ .replace(/'/g, "&apos;");
8
+ }
9
+ /**
10
+ * Format discovered agent definitions for inclusion in the system prompt.
11
+ * Uses XML format consistent with pi's skill injection.
12
+ *
13
+ * Returns an empty string when no agents are available.
14
+ */
15
+ export function formatAgentsForPrompt(agents) {
16
+ if (agents.length === 0)
17
+ return "";
18
+ const lines = [
19
+ "",
20
+ "",
21
+ "---",
22
+ "The following subagents can be spawned via crew_spawn to handle tasks in parallel.",
23
+ "Use crew_list to see their current status. Interactive subagents stay alive after responding;",
24
+ "use crew_respond to continue and crew_done to close them.",
25
+ "",
26
+ "<available_subagents>",
27
+ ];
28
+ for (const agent of agents) {
29
+ lines.push(" <subagent>");
30
+ lines.push(` <name>${escapeXml(agent.name)}</name>`);
31
+ lines.push(` <description>${escapeXml(agent.description)}</description>`);
32
+ lines.push(` <interactive>${agent.interactive ? "true" : "false"}</interactive>`);
33
+ lines.push(" </subagent>");
34
+ }
35
+ lines.push("</available_subagents>");
36
+ lines.push("---");
37
+ lines.push("");
38
+ return lines.join("\n");
39
+ }
@@ -748,7 +748,30 @@ They demonstrate how the extension is intended to be used:
748
748
 
749
749
  Architecturally, these files are not special-cased by the runtime. They are auto-discovered as the lowest-priority source (priority 3) and go through the same discovery and bootstrap pipeline as project-level or user-level definitions. Users can override any bundled subagent by placing a same-named `.md` file in `<cwd>/.pi/agents/` or `~/.pi/agent/agents/`.
750
750
 
751
- ### 14.2 Bundled review orchestration prompt
751
+ ### 14.2 Bundled plan orchestration prompt
752
+
753
+ File:
754
+
755
+ - `prompts/pi-crew-plan.md`
756
+
757
+ This prompt template orchestrates discovery and planning workflow.
758
+
759
+ It tells the orchestrating agent to:
760
+
761
+ - gather minimal orientation context
762
+ - spawn scout subagents to investigate specific areas
763
+ - collect and synthesize scout findings
764
+ - delegate planning to a planner subagent
765
+ - relay the planner's output to the user
766
+
767
+ The prompt enforces strict delegation boundaries:
768
+
769
+ - the orchestrator must not perform deep investigation itself
770
+ - the orchestrator must not write the plan itself
771
+ - detailed discovery belongs to scouts
772
+ - plan creation belongs to the planner
773
+
774
+ ### 14.3 Bundled review orchestration prompt
752
775
 
753
776
  File:
754
777
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@melihmucuk/pi-crew",
3
- "version": "1.0.3",
3
+ "version": "1.0.5",
4
4
  "type": "module",
5
5
  "description": "Non-blocking subagent orchestration for pi coding agent",
6
6
  "files": [
@@ -31,7 +31,8 @@
31
31
  "scripts": {
32
32
  "clean": "rm -rf dist",
33
33
  "build": "npm run clean && tsc",
34
- "typecheck": "tsc --noEmit"
34
+ "typecheck": "tsc --noEmit",
35
+ "prepare": "npm run build"
35
36
  },
36
37
  "peerDependencies": {
37
38
  "@mariozechner/pi-ai": "*",
@@ -0,0 +1,181 @@
1
+ ---
2
+ description: Run parallel subagents to investigate a codebase and produce an implementation plan for the given task.
3
+ ---
4
+
5
+ # Planning Orchestration
6
+
7
+ ## Input
8
+
9
+ **Additional instructions**: `$ARGUMENTS`
10
+
11
+ ## Role
12
+
13
+ This is an orchestration prompt.
14
+ 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.
15
+
16
+ Do not perform deep code investigation yourself.
17
+ Do not write the plan yourself.
18
+ Do not modify any files.
19
+
20
+ ## Operating Boundaries
21
+
22
+ - Do not read full source files before spawning scouts.
23
+ - Do not perform broad codebase searches yourself.
24
+ - Gather only enough context to understand what the task is and how to split the discovery work across scouts.
25
+ - Detailed file reading, pattern analysis, and dependency tracing belong to the scouts.
26
+ - Plan creation belongs to the planner.
27
+
28
+ ## Required Workflow
29
+
30
+ ### 1) Understand the task
31
+
32
+ Determine the task from:
33
+
34
+ - the additional instructions provided above, if any
35
+ - the current conversation context if no additional instructions were provided
36
+
37
+ If the task is still unclear after both sources, ask the user to clarify before proceeding.
38
+
39
+ 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.
40
+
41
+ ### 2) Gather minimal orientation context
42
+
43
+ Collect only what you need to write focused, actionable scout tasks. Start with:
44
+
45
+ - project root structure (`ls` top-level)
46
+ - key config files (package.json, go.mod, Cargo.toml, etc.) to identify language, framework, dependencies
47
+ - README or AGENTS.md if present, for project conventions
48
+
49
+ If this is enough to identify which areas of the codebase the task touches, stop and proceed to spawning scouts.
50
+
51
+ If not, you may do lightweight exploration to locate the right areas:
52
+
53
+ - browse directory trees (`ls`, `find`) to understand module/package layout
54
+ - read a few lines of entry points or index files to understand how the project is organized
55
+ - run targeted searches (`grep`, `rg`) for task-related terms to find which directories or files are relevant
56
+
57
+ 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.
58
+
59
+ ### 3) Spawn scouts
60
+
61
+ Call `crew_list` first and verify `scout` is available.
62
+
63
+ Spawn one or more scout subagents in parallel (maximum 4). Each scout must receive:
64
+
65
+ - the project root path
66
+ - the specific area or question to investigate
67
+ - enough framing so the scout knows what to look for
68
+
69
+ Strategic scout allocation:
70
+
71
+ - If the task touches a single area, one scout may suffice.
72
+ - If the task spans multiple areas (e.g., API + database + frontend), spawn a separate scout per area.
73
+ - If the task requires understanding an existing pattern before proposing changes, dedicate a scout to "find existing patterns/conventions for X".
74
+ - Do not spawn more than 4 scouts. Each scout should have a distinct, non-overlapping investigation focus.
75
+
76
+ Each scout task must include:
77
+
78
+ - the user's original task (so the scout understands **why** it is investigating)
79
+ - project root path
80
+ - the orientation context you already gathered (language, framework, key dependencies, project structure, conventions) so the scout does not repeat this work
81
+ - clear investigation scope (which directories, files, or concepts to explore)
82
+ - what specific information to return (types, interfaces, data flow, dependencies, etc.)
83
+ - any external references from the user (file paths, image paths, documents) that are relevant to this scout's scope, with instructions to inspect them
84
+ - explicit instruction that it is read-only
85
+
86
+ 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.
87
+
88
+ ### 4) Wait for all scouts
89
+
90
+ Do not proceed until every spawned scout has returned.
91
+ Do not synthesize partial results.
92
+ Do not predict or fabricate scout findings.
93
+ Wait for all `crew-result` messages.
94
+
95
+ 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.
96
+
97
+ **Handling scout failures:**
98
+
99
+ - If a scout returns an error or times out, retry it once with the same task.
100
+ - 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.
101
+ - 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.
102
+
103
+ ### 5) Spawn planner
104
+
105
+ Call `crew_list` first and verify `planner` is available.
106
+
107
+ Before spawning the planner, process the scout findings:
108
+
109
+ - Remove duplicate information that multiple scouts reported.
110
+ - Drop generic observations that are not relevant to the task.
111
+ - Keep all specific findings: file paths, function signatures, type definitions, data flows, constraints, and patterns.
112
+ - Organize by area, not by scout. If two scouts reported on overlapping areas, merge their findings under one heading.
113
+ - If scouts reported conflicting information, include both and flag the contradiction.
114
+
115
+ Then spawn the planner subagent with:
116
+
117
+ - the user's original task description (verbatim)
118
+ - any additional user instructions or constraints
119
+ - all external references from the user (file paths, image paths, screenshots, documents, URLs) with instructions to inspect them directly
120
+ - the processed scout findings, organized by area
121
+ - project root path
122
+ - language, framework, key dependencies
123
+ - relevant conventions or constraints discovered by scouts
124
+ - any gaps in discovery (scouts that failed or returned empty) so the planner knows what was not investigated
125
+ - 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
126
+
127
+ The planner is an interactive subagent. It will respond with one of:
128
+
129
+ - **Blocking Questions**: questions that need user input before a plan can be made
130
+ - **Implementation Plan**: the complete plan
131
+ - **No plan needed**: the task is trivial enough that a plan adds no value
132
+
133
+ ### 6) Relay planner output
134
+
135
+ When the planner responds:
136
+
137
+ 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.
138
+
139
+ **If Blocking Questions:**
140
+
141
+ - Tell the user that the planner has questions that need answering before it can produce a plan.
142
+ - Ask the user to answer them.
143
+ - When the user answers, relay the answers to the planner using `crew_respond`.
144
+ - Wait for the planner's next response and repeat this step.
145
+
146
+ **If Implementation Plan:**
147
+
148
+ - Tell the user the plan is ready and ask if they approve or want changes.
149
+ - If the user requests changes, relay the feedback to the planner using `crew_respond`.
150
+ - Wait for the planner's updated plan and repeat this step.
151
+
152
+ **If No plan needed:**
153
+
154
+ - Close the planner session with `crew_done`.
155
+ - Briefly explain why no plan is needed.
156
+ - 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.
157
+
158
+ **If the user approves the plan:**
159
+
160
+ - Call `crew_done` to close the planner session.
161
+ - Confirm that the plan is finalized.
162
+
163
+ ## Relay Rules
164
+
165
+ - 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).
166
+ - Never answer the planner's blocking questions on behalf of the user.
167
+ - Never modify the plan based on your own judgment. All feedback goes through the user.
168
+ - When relaying user feedback to the planner via `crew_respond`, include the user's words verbatim plus any necessary context from the conversation.
169
+
170
+ ## Language
171
+
172
+ All output to the user must be in the same language as the user's prompt.
173
+ When spawning scouts and the planner, instruct them to respond in the same language as the user's prompt.
174
+
175
+ ## IMPORTANT
176
+
177
+ - DO NOT perform deep codebase investigation yourself. Delegate to scouts.
178
+ - DO NOT write or modify the plan yourself. Delegate to the planner.
179
+ - NEVER PREDICT or FABRICATE results for subagents that have not yet reported back to you.
180
+ - Do NOT rewrite or duplicate subagent output that is already visible as a steering message.
181
+ - ALWAYS wait for explicit user approval before finalizing the plan.