@melihmucuk/pi-crew 1.0.16 → 1.0.17

package/prompts/pi-crew-review.md

@@ -6,31 +6,36 @@ description: Orchestrate parallel code and quality reviews with reviewer subagen
 
 Additional instructions: `$ARGUMENTS`
 
-You are a review orchestrator, not a reviewer. Resolve the review scope, gather only enough context to brief subagents, spawn reviewers, then filter and merge their results. Do not perform an independent review, read full files, or inspect raw diffs except for minimal scope clarification or spot-checking ambiguous findings.
+You are a review orchestrator, not a reviewer. Resolve the review scope, gather only enough task-specific context to brief subagents, spawn reviewers, then filter and merge their results. Do not perform an independent review or inspect raw diffs except for minimal scope clarification or spot-checking ambiguous findings.
 
 ## Scope
 
-Use the user's scope when provided. Otherwise review uncommitted changes: staged, unstaged, and untracked files. If “latest” or “recent” is requested, review the last 5 commits unless a count is given.
+Use the user's scope when provided. Otherwise rely on each reviewer’s default scope. If “latest” or “recent” is requested, review the last 5 commits unless a count is given.
 
-Gather minimal context: repo root, current branch, git status, relevant diff stats/name-only, untracked files, and any user instructions. Keep the brief neutral and descriptive, not analytical. Stop when scope and changed files are clear.
+Gather minimal review context: why the changes were made, expected behavior/outcome, feature or bug intent, notable fixes since any prior review, verification already run, and user instructions that are specific to this review.
+
+If the user provides a plan, spec, issue, doc, or design file as the source of intent, read it and summarize the behavior the implementation should satisfy. This is allowed context gathering, not independent code review.
+
+Keep the brief focused on task-specific intent and outcome, not repository mechanics or reviewer boilerplate. Do not paste full changed-file, staged/unstaged, untracked, branch, cwd, or project-constraint inventories for default reviews; reviewers run in the same repo cwd and can inspect Git state and repo guidance themselves. Include file paths or entry points only when they define scope, identify an intent source, prevent ambiguity, or highlight non-obvious areas.
 
 ## Subagents
 
 Call `crew_list` first and check for `code-reviewer` and `quality-reviewer`. Spawn available reviewers in parallel. If one is unavailable, fails to start, returns `error`, or is aborted, report that clearly and continue with completed reviewer results.
 
-Send each reviewer a self-contained brief with:
-- repo root and branch;
-- resolved in-scope review target;
-- explicit out-of-scope boundaries;
-- commit range or changed file list;
-- staged/unstaged/untracked status when relevant;
-- short file/group summary;
-- additional user instructions;
-- instruction to ignore the reviewer’s own default scope if it differs from this brief.
+Send each reviewer a compact, task-specific brief. Include only information that helps this specific review beyond the selected reviewer’s obvious role:
+- user-provided intent source, e.g. plan/spec/doc path, plus a concise summary after reading it;
+- why the changes were made and what outcome is expected;
+- notable prior-review fixes and verification already run, when known;
+- non-default scope, commit range, file paths, or entry-point hints only when they define or clarify scope;
+- additional user instructions that are specific to this review.
+
+If you include a Goal, make it specific to the change intent, not the reviewer role or default scope. Prefer omitting Goal when Context/Intent already states the task clearly.
+
+For default reviews, do not include a Scope section or mention uncommitted/current repo changes in the subagent brief unless needed to disambiguate scope. If you need to state task-specific emphasis, use `Review focus:` instead of `Scope:`.
+
+Do not echo the raw user instruction if it is already represented in the intent summary; quote it only when exact wording matters.
 
-Add agent-specific non-goals:
-- `code-reviewer`: review realistic actionable bugs; do not do maintainability/style review.
-- `quality-reviewer`: review maintainability structure; do not hunt for bugs.
+Do not restate reviewer-role boilerplate implied by the selected reviewer, such as telling `code-reviewer` to find actionable bugs or telling `quality-reviewer` to review maintainability. Do not include default scope, generic non-goals, acceptance criteria, output format, edit permissions, or severity rules unless the user explicitly overrides them.
 
 Do not poll. Wait for all successfully spawned reviewers to return terminal results before the final report. Never fabricate subagent output.
 
@@ -67,4 +72,3 @@ Rules:
 - Do not repeat overlapping findings.
 - Do not present a single-reviewer finding as consensus.
 - If both reviewers report no accepted findings, say so clearly.
-- Review only; do not change code.

package/skills/pi-crew/REFERENCE.md

@@ -2,30 +2,35 @@
 
 ## Delegation Checklist
 
-Before `crew_spawn`, ensure the brief includes:
+Before `crew_spawn`, ensure the brief is self-contained but not mechanically templated. Include only information that helps this specific subagent do this specific task:
 
-- User goal and agreed decisions.
-- Relevant files, symbols, entry points, commands, errors, or logs.
-- Scope, constraints, and non-goals.
-- Whether the subagent may edit files or must only report.
-- Whether the task is exploratory, implementation, review, planning, or verification.
-- Expected output format.
-- Acceptance criteria.
-- Verification command, if known.
+- Intent, expected outcome, and relevant user decisions.
+- User-provided references, plus a concise summary after reading them when practical.
+- File paths, symbols, entry points, commands, errors, or logs only when they genuinely clarify the task.
+- Non-default scope, constraints, assumptions, or verification context only when they matter.
+- Gaps or unresolved questions the subagent should account for.
 
-Do not rely on hidden active-session context. If the subagent needs it, include it.
+Do not restate boilerplate implied by the selected subagent’s role, name, or description. Avoid repeating default scope, edit permissions, output format, generic repo guidance, cwd/branch details, or mechanical Git state the subagent can inspect itself.
+
+Do not rely on hidden active-session context. If the subagent needs a decision, conclusion, user intent, or prior result that is not discoverable from files/tools, include it.
 
 ## Good Brief
 
 ```md
-Goal: Investigate why `crew_done` emits duplicate result messages.
-Context: Closing an interactive subagent should dispose the session without sending another result.
-Relevant files / entry points: `extension/runtime/crew-runtime.ts`, `extension/integration/tools/crew-done.ts`, `AGENTS.md`.
-Constraints: Do not change tool schemas. Do not edit unrelated lifecycle behavior.
-Non-goals: Do not refactor session ownership or delivery routing.
-Acceptance criteria: Identify root cause and minimal fix direction.
-Expected output: Root cause, minimal fix proposal, and verification command. Do not edit files.
-Verification: `npm run typecheck` if implementation is later requested.
+Intent / context:
+Password reset emails should expire after 30 minutes. Users report that old reset links still work several hours later.
+
+Relevant inputs / entry points:
+- The password reset request handler.
+- The token validation path used by the reset form.
+- Any configuration or database fields that store token expiry.
+
+Constraints / decisions:
+- Preserve the existing email template and reset URL format.
+- Do not change login or account creation behavior.
+
+Deliverable:
+Identify the likely root cause and the smallest safe fix direction.
 ```
 
 ## Bad Briefs
@@ -42,7 +47,14 @@ Investigate the bug we discussed.
 Implement the plan.
 ```
 
-These depend on hidden conversation state and produce inconsistent results.
+```md
+Goal: Review the current uncommitted changes for actionable bugs.
+Scope: Current repo changes, staged/unstaged/untracked files.
+Non-goals: Do not modify files.
+Expected output: Findings with severity and fix direction.
+```
+
+These depend on hidden conversation state, restate subagent boilerplate, or carry mechanical repository state instead of task-specific intent.
 
 ## Parallel Delegation
 
@@ -57,7 +69,7 @@ If ownership overlaps, serialize the work.
 ## Failure and Conflict Handling
 
 - If a subagent errors or aborts, report that status clearly and continue only if remaining results are sufficient.
-- If a result misses acceptance criteria, ask a focused follow-up or spawn a new subagent with a corrected brief.
+- If a result misses the task-specific deliverable, ask a focused follow-up or spawn a new subagent with a corrected brief.
 - If results conflict, do not average them or pick silently. State the conflict, compare evidence, and resolve only with available facts or a targeted follow-up.
 - If a task becomes obsolete, abort the relevant active subagent.
 

package/skills/pi-crew/SKILL.md

@@ -21,20 +21,23 @@ See [REFERENCE.md](REFERENCE.md) for examples and detailed handling patterns.
 
 ## Spawn Brief
 
-Send a self-contained task. Include only relevant sections:
+Send a self-contained task, but do not fill a template mechanically. Use only sections that add task-specific value, for example:
 
 ```md
-Goal:
-Context:
-Relevant files / entry points:
-Constraints:
-Non-goals:
-Acceptance criteria:
-Expected output:
-Verification:
+Intent / context:
+Relevant inputs / entry points:
+Constraints / decisions:
+Deliverable / expected outcome:
+Verification / checks:
 ```
 
-Include paths, exact errors/output, edit permissions, task type, and constraints when they matter. Prefer path references over copying large file contents.
+Omit sections that would only restate the selected subagent’s role, default scope, edit permissions, output format, or obvious next steps.
+
+Include only information that helps this specific subagent do this specific task: intent, expected outcome, relevant decisions, exact errors/output, unusual constraints, and file paths or entry points that genuinely clarify the task. Use short Markdown sections and bullets when they improve scanability, especially for multi-part intent, constraints, observations, requirements, or acceptance criteria; avoid dense paragraphs.
+
+Do not restate boilerplate implied by the selected subagent’s role, name, or description. Avoid repeating default scope, output format, edit permissions, or repo guidance. Subagents run in the same cwd as the orchestrator, so do not include mechanical Git state they can inspect themselves, such as full changed-file lists, staged/unstaged/untracked inventories, branch/cwd details, or generic project constraints, unless those details define a non-default scope or prevent ambiguity.
+
+If the user points to a plan, spec, issue, design, or doc as task intent, read it when practical and summarize the relevant intent instead of merely passing the path. Prefer explaining why the work matters and what outcome is expected over restating repository state.
 
 ## Result Handling
 

package/extension/integration/tools/tool-deps.ts

@@ -1,16 +0,0 @@
-import type {
-	ExtensionAPI,
-	ExtensionContext,
-} from "@earendil-works/pi-coding-agent";
-import type { AgentDiscoveryWarning } from "../../agent-discovery.js";
-import type { CrewRuntime } from "../../runtime/crew-runtime.js";
-
-export interface CrewToolDeps {
-	pi: ExtensionAPI;
-	crew: CrewRuntime;
-	extensionDir: string;
-	notifyDiscoveryWarnings: (
-		ctx: ExtensionContext,
-		warnings: AgentDiscoveryWarning[],
-	) => void;
-}

package/extension/integration.ts

@@ -1,13 +0,0 @@
-import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
-import type { CrewRuntime } from "./runtime/crew-runtime.js";
-import { registerCrewMessageRenderers } from "./integration/register-renderers.js";
-import { registerCrewTools } from "./integration/register-tools.js";
-
-export function registerCrewIntegration(
-	pi: ExtensionAPI,
-	crew: CrewRuntime,
-	extensionDir: string,
-): void {
-	registerCrewTools(pi, crew, extensionDir);
-	registerCrewMessageRenderers(pi);
-}

package/extension/runtime/subagent-state.ts

@@ -1,59 +0,0 @@
-import { randomBytes } from "node:crypto";
-import type { AgentSession } from "@earendil-works/pi-coding-agent";
-import type { AgentConfig } from "../agent-discovery.js";
-import type { SubagentStatus } from "../subagent-messages.js";
-
-export interface SubagentState {
-	id: string;
-	agentConfig: AgentConfig;
-	task: string;
-	status: SubagentStatus;
-	ownerSessionId: string;
-	session: AgentSession | null;
-	turns: number;
-	contextTokens: number;
-	model: string | undefined;
-	error?: string;
-	result?: string;
-	promptAbortController?: AbortController;
-	unsubscribe?: () => void;
-}
-
-export interface ActiveAgentSummary {
-	id: string;
-	agentName: string;
-	status: SubagentStatus;
-	turns: number;
-	contextTokens: number;
-	model: string | undefined;
-}
-
-export function generateId(name: string, existingIds: Set<string>): string {
-	for (let i = 0; i < 10; i++) {
-		const id = `${name}-${randomBytes(4).toString("hex")}`;
-		if (!existingIds.has(id)) return id;
-	}
-	return `${name}-${randomBytes(8).toString("hex")}`;
-}
-
-// Status may change externally via abort(). Standalone function avoids TS narrowing.
-export function isAborted(state: SubagentState): boolean {
-	return state.status === "aborted";
-}
-
-export function isAbortableStatus(status: SubagentStatus): boolean {
-	return status === "running" || status === "waiting";
-}
-
-export function buildActiveAgentSummary(
-	state: SubagentState,
-): ActiveAgentSummary {
-	return {
-		id: state.id,
-		agentName: state.agentConfig.name,
-		status: state.status,
-		turns: state.turns,
-		contextTokens: state.contextTokens,
-		model: state.model,
-	};
-}