pi-squad 0.7.2 → 0.15.0
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 +202 -317
- package/package.json +18 -2
- package/src/advisor.ts +145 -0
- package/src/agent-pool.ts +39 -15
- package/src/agents/_defaults/architect.json +8 -1
- package/src/agents/_defaults/backend.json +9 -1
- package/src/agents/_defaults/debugger.json +8 -1
- package/src/agents/_defaults/devops.json +9 -1
- package/src/agents/_defaults/docs.json +8 -1
- package/src/agents/_defaults/frontend.json +10 -1
- package/src/agents/_defaults/fullstack.json +8 -1
- package/src/agents/_defaults/planner.json +7 -1
- package/src/agents/_defaults/qa.json +8 -1
- package/src/agents/_defaults/researcher.json +8 -1
- package/src/agents/_defaults/reviewer.json +10 -0
- package/src/agents/_defaults/security.json +8 -1
- package/src/index.ts +379 -78
- package/src/monitor.ts +54 -20
- package/src/panel/message-view.ts +2 -2
- package/src/panel/squad-panel.ts +3 -3
- package/src/panel/squad-widget.ts +3 -3
- package/src/panel/task-list.ts +2 -2
- package/src/plan-rules.ts +134 -0
- package/src/planner.ts +18 -14
- package/src/protocol.ts +10 -2
- package/src/scheduler.ts +293 -13
- package/src/skills/squad-code-review/SKILL.md +89 -0
- package/src/skills/squad-collaboration/SKILL.md +5 -1
- package/src/skills/squad-debugging/SKILL.md +61 -0
- package/src/skills/squad-protocol/SKILL.md +19 -0
- package/src/skills/squad-qa-testing/SKILL.md +19 -8
- package/src/skills/squad-supervisor/SKILL.md +85 -11
- package/src/store.ts +27 -1
- package/src/types.ts +49 -2
package/package.json
CHANGED
|
@@ -1,8 +1,11 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pi-squad",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.15.0",
|
|
4
4
|
"description": "Multi-agent collaboration extension for pi — task decomposition, dependency management, parallel execution, TUI panel",
|
|
5
5
|
"type": "module",
|
|
6
|
+
"scripts": {
|
|
7
|
+
"test": "node --test tests/*.test.mjs"
|
|
8
|
+
},
|
|
6
9
|
"pi": {
|
|
7
10
|
"extensions": [
|
|
8
11
|
"src/index.ts"
|
|
@@ -10,6 +13,8 @@
|
|
|
10
13
|
"skills": [
|
|
11
14
|
"src/skills/squad-supervisor",
|
|
12
15
|
"src/skills/squad-backend-dev",
|
|
16
|
+
"src/skills/squad-code-review",
|
|
17
|
+
"src/skills/squad-debugging",
|
|
13
18
|
"src/skills/squad-frontend-dev",
|
|
14
19
|
"src/skills/squad-qa-testing",
|
|
15
20
|
"src/skills/squad-security-audit",
|
|
@@ -22,6 +27,7 @@
|
|
|
22
27
|
"LICENSE"
|
|
23
28
|
],
|
|
24
29
|
"keywords": [
|
|
30
|
+
"pi-package",
|
|
25
31
|
"pi",
|
|
26
32
|
"pi-extension",
|
|
27
33
|
"multi-agent",
|
|
@@ -35,5 +41,15 @@
|
|
|
35
41
|
"type": "git",
|
|
36
42
|
"url": "https://github.com/picassio/pi-squad.git"
|
|
37
43
|
},
|
|
38
|
-
"homepage": "https://github.com/picassio/pi-squad"
|
|
44
|
+
"homepage": "https://github.com/picassio/pi-squad#readme",
|
|
45
|
+
"bugs": {
|
|
46
|
+
"url": "https://github.com/picassio/pi-squad/issues"
|
|
47
|
+
},
|
|
48
|
+
"publishConfig": {
|
|
49
|
+
"registry": "https://registry.npmjs.org/",
|
|
50
|
+
"access": "public"
|
|
51
|
+
},
|
|
52
|
+
"devDependencies": {
|
|
53
|
+
"@types/node": "^26.1.1"
|
|
54
|
+
}
|
|
39
55
|
}
|
package/src/advisor.ts
ADDED
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* advisor.ts — Squad advisor: consult a stronger model when an agent is stuck.
|
|
3
|
+
*
|
|
4
|
+
* Modeled on the advisor tool pattern (pi-advisor / Anthropic's advisor
|
|
5
|
+
* strategy): the agent keeps doing the work; when the Monitor detects it is
|
|
6
|
+
* stuck, looping, or timing out, the squad consults an advisor model with a
|
|
7
|
+
* curated context digest and steers the agent with the returned verdict +
|
|
8
|
+
* action items. Escalation to the human happens only when the advisor is
|
|
9
|
+
* disabled, exhausted, or fails.
|
|
10
|
+
*
|
|
11
|
+
* This module is pure (no pi imports) so it stays unit-testable.
|
|
12
|
+
*/
|
|
13
|
+
|
|
14
|
+
import type { Task, TaskMessage } from "./types.js";
|
|
15
|
+
|
|
16
|
+
// ============================================================================
|
|
17
|
+
// Settings
|
|
18
|
+
// ============================================================================
|
|
19
|
+
|
|
20
|
+
export interface AdvisorSettings {
|
|
21
|
+
/** Consult an advisor before escalating stuck agents to the human */
|
|
22
|
+
enabled: boolean;
|
|
23
|
+
/** "main" = main session's current model, or an explicit "provider/id" */
|
|
24
|
+
model: string;
|
|
25
|
+
/** Max advisor consultations per task before escalating for real */
|
|
26
|
+
maxCallsPerTask: number;
|
|
27
|
+
/** Max output tokens per advisor call (thinking tokens count on adaptive models) */
|
|
28
|
+
maxTokens: number;
|
|
29
|
+
/** Reasoning effort for the advisor call */
|
|
30
|
+
reasoning: string;
|
|
31
|
+
}
|
|
32
|
+
|
|
33
|
+
export const DEFAULT_ADVISOR_SETTINGS: AdvisorSettings = {
|
|
34
|
+
enabled: true,
|
|
35
|
+
model: "main",
|
|
36
|
+
maxCallsPerTask: 2,
|
|
37
|
+
maxTokens: 8192,
|
|
38
|
+
reasoning: "medium",
|
|
39
|
+
};
|
|
40
|
+
|
|
41
|
+
// ============================================================================
|
|
42
|
+
// Consult input/output
|
|
43
|
+
// ============================================================================
|
|
44
|
+
|
|
45
|
+
export interface AdvisorConsultInput {
|
|
46
|
+
taskId: string;
|
|
47
|
+
taskTitle: string;
|
|
48
|
+
taskDescription: string;
|
|
49
|
+
agentName: string;
|
|
50
|
+
agentRole: string;
|
|
51
|
+
/** Why the monitor flagged this agent (stuck, looping, timeout...) */
|
|
52
|
+
reason: string;
|
|
53
|
+
/** Recent task messages (already tailed by the caller) */
|
|
54
|
+
recentMessages: Pick<TaskMessage, "from" | "type" | "text">[];
|
|
55
|
+
/** Recent tool call summaries from agent activity */
|
|
56
|
+
recentToolCalls: string[];
|
|
57
|
+
turnCount: number;
|
|
58
|
+
elapsedMinutes: number;
|
|
59
|
+
}
|
|
60
|
+
|
|
61
|
+
// ============================================================================
|
|
62
|
+
// Prompts
|
|
63
|
+
// ============================================================================
|
|
64
|
+
|
|
65
|
+
export const ADVISOR_SYSTEM_PROMPT = `You are a senior engineering advisor for an autonomous squad agent that has run into trouble. The agent works on one task inside a multi-agent squad; a monitor flagged it (stuck, looping, or idle) and you are consulted before the problem is escalated to a human.
|
|
66
|
+
|
|
67
|
+
Your role:
|
|
68
|
+
- You see a curated digest: the task, recent messages, and recent tool activity summaries — not the full transcript
|
|
69
|
+
- If the evidence is too thin to judge, say so — never fill gaps with guesses
|
|
70
|
+
- You cannot call tools. Your advice is injected directly into the agent's conversation as a steering message and it will act on it immediately
|
|
71
|
+
|
|
72
|
+
Output format:
|
|
73
|
+
- Lead with a one-sentence verdict: "Course-correct", "Push through", or "Needs human input"
|
|
74
|
+
- Follow with numbered action items (max 5) the agent should take next
|
|
75
|
+
- If the evidence doesn't settle a point, make your FIRST action item the exact command or file read that would settle it — instead of guessing
|
|
76
|
+
- Reference specific files, commands, or error signals from the digest
|
|
77
|
+
- If the blocker genuinely requires a human decision (product choice, missing credentials, destructive action), say "Needs human input" and state the exact question to ask
|
|
78
|
+
|
|
79
|
+
Keep it short. The agent reads your advice and immediately acts on it.`;
|
|
80
|
+
|
|
81
|
+
const MAX_MSG_CHARS = 400;
|
|
82
|
+
const MAX_MESSAGES = 12;
|
|
83
|
+
const MAX_TOOL_CALLS = 10;
|
|
84
|
+
|
|
85
|
+
function clamp(text: string, max: number): string {
|
|
86
|
+
const t = text.trim();
|
|
87
|
+
return t.length > max ? `${t.slice(0, max).trimEnd()}…` : t;
|
|
88
|
+
}
|
|
89
|
+
|
|
90
|
+
/**
|
|
91
|
+
* Build the user-message digest sent to the advisor model.
|
|
92
|
+
* Curated and bounded — summaries, not full transcripts.
|
|
93
|
+
*/
|
|
94
|
+
export function buildAdvisorConsultText(input: AdvisorConsultInput): string {
|
|
95
|
+
const lines: string[] = [];
|
|
96
|
+
|
|
97
|
+
lines.push(`# Stuck Agent Consultation`);
|
|
98
|
+
lines.push("");
|
|
99
|
+
lines.push(`Agent: ${input.agentName} (${input.agentRole})`);
|
|
100
|
+
lines.push(`Task: ${input.taskId} — ${input.taskTitle}`);
|
|
101
|
+
lines.push(`Monitor flag: ${input.reason}`);
|
|
102
|
+
lines.push(`Progress: ${input.turnCount} turns, ~${Math.round(input.elapsedMinutes)} min elapsed`);
|
|
103
|
+
lines.push("");
|
|
104
|
+
lines.push(`## Task Description`);
|
|
105
|
+
lines.push(clamp(input.taskDescription || "(no description)", 1500));
|
|
106
|
+
|
|
107
|
+
if (input.recentToolCalls.length > 0) {
|
|
108
|
+
lines.push("");
|
|
109
|
+
lines.push(`## Recent Tool Activity (newest last)`);
|
|
110
|
+
for (const call of input.recentToolCalls.slice(-MAX_TOOL_CALLS)) {
|
|
111
|
+
lines.push(`- ${clamp(call, 160)}`);
|
|
112
|
+
}
|
|
113
|
+
}
|
|
114
|
+
|
|
115
|
+
const messages = input.recentMessages.slice(-MAX_MESSAGES);
|
|
116
|
+
if (messages.length > 0) {
|
|
117
|
+
lines.push("");
|
|
118
|
+
lines.push(`## Recent Messages (newest last)`);
|
|
119
|
+
for (const msg of messages) {
|
|
120
|
+
lines.push(`[${msg.from}/${msg.type}] ${clamp(msg.text, MAX_MSG_CHARS)}`);
|
|
121
|
+
}
|
|
122
|
+
}
|
|
123
|
+
|
|
124
|
+
lines.push("");
|
|
125
|
+
lines.push(`Provide your verdict and action items now.`);
|
|
126
|
+
return lines.join("\n");
|
|
127
|
+
}
|
|
128
|
+
|
|
129
|
+
/**
|
|
130
|
+
* Format advisor advice as a steering message for the agent.
|
|
131
|
+
*/
|
|
132
|
+
export function formatAdvisorSteerMessage(advice: string, reason: string): string {
|
|
133
|
+
return [
|
|
134
|
+
`[squad advisor] A monitor flagged your task (${reason}) and a senior advisor reviewed your situation. Guidance:`,
|
|
135
|
+
"",
|
|
136
|
+
advice.trim(),
|
|
137
|
+
"",
|
|
138
|
+
`Execute these action items unless your evidence contradicts them — in that case state the conflict explicitly instead of silently ignoring the advice.`,
|
|
139
|
+
].join("\n");
|
|
140
|
+
}
|
|
141
|
+
|
|
142
|
+
/** True when the advisor's verdict says a human decision is required. */
|
|
143
|
+
export function adviceNeedsHuman(advice: string): boolean {
|
|
144
|
+
return /needs human input/i.test(advice.slice(0, 200));
|
|
145
|
+
}
|
package/src/agent-pool.ts
CHANGED
|
@@ -147,8 +147,10 @@ export class AgentPool {
|
|
|
147
147
|
protocolOptions: ProtocolBuildOptions;
|
|
148
148
|
cwd: string;
|
|
149
149
|
skillPaths: string[];
|
|
150
|
+
/** Fork the given session file so the agent inherits its conversation context */
|
|
151
|
+
forkSession?: { file: string; sessionDir: string };
|
|
150
152
|
}): Promise<AgentProcess> {
|
|
151
|
-
const { taskId, agentDef, protocolOptions, cwd, skillPaths } = options;
|
|
153
|
+
const { taskId, agentDef, protocolOptions, cwd, skillPaths, forkSession } = options;
|
|
152
154
|
|
|
153
155
|
// Kill existing process for this task if any
|
|
154
156
|
if (this.agents.has(taskId)) {
|
|
@@ -162,11 +164,11 @@ export class AgentPool {
|
|
|
162
164
|
fs.writeFileSync(promptFile, systemPrompt, "utf-8");
|
|
163
165
|
|
|
164
166
|
// Build pi CLI args
|
|
165
|
-
const args = buildPiArgs(agentDef, promptFile, skillPaths);
|
|
167
|
+
const args = buildPiArgs(agentDef, promptFile, skillPaths, forkSession);
|
|
166
168
|
|
|
167
169
|
// Spawn pi process — set env var to prevent recursive squad extension loading
|
|
168
170
|
const invocation = getPiInvocation(["--mode", "rpc", ...args]);
|
|
169
|
-
debug("squad-pool", `spawn ${agentDef.name}: ${invocation.command} ${invocation.args.
|
|
171
|
+
debug("squad-pool", `spawn ${agentDef.name}: ${invocation.command} ${invocation.args.join(" ")}`);
|
|
170
172
|
const proc = spawn(invocation.command, invocation.args, {
|
|
171
173
|
cwd,
|
|
172
174
|
stdio: ["pipe", "pipe", "pipe"],
|
|
@@ -340,10 +342,25 @@ export class AgentPool {
|
|
|
340
342
|
}
|
|
341
343
|
|
|
342
344
|
private handleRpcEvent(agent: AgentProcess, event: any): void {
|
|
343
|
-
agent
|
|
345
|
+
// Only genuine agent activity advances the idle clock. Command acks
|
|
346
|
+
// (type=response) and echoes of injected user messages (steer messages
|
|
347
|
+
// recorded as user-role message events) must NOT reset it — otherwise the
|
|
348
|
+
// monitor's own idle/stuck steers keep a silent agent looking "healthy"
|
|
349
|
+
// forever and escalation (advisor rescue) can never fire.
|
|
350
|
+
const msgRole = event.message?.role;
|
|
351
|
+
const isAgentActivity =
|
|
352
|
+
event.type?.startsWith?.("tool_execution") ||
|
|
353
|
+
event.type === "turn_start" ||
|
|
354
|
+
event.type === "turn_end" ||
|
|
355
|
+
event.type === "agent_start" ||
|
|
356
|
+
event.type === "agent_end" ||
|
|
357
|
+
(event.type?.startsWith?.("message_") && msgRole !== "user");
|
|
358
|
+
if (isAgentActivity) {
|
|
359
|
+
agent.activity.lastOutputTs = Date.now();
|
|
360
|
+
}
|
|
344
361
|
|
|
345
|
-
// Parse event type and emit
|
|
346
|
-
if (event.type === "message_end" && event.message) {
|
|
362
|
+
// Parse event type and emit (user-message echoes don't count as turns)
|
|
363
|
+
if (event.type === "message_end" && event.message && msgRole !== "user") {
|
|
347
364
|
agent.activity.turnCount++;
|
|
348
365
|
this.emit({
|
|
349
366
|
type: "message_end",
|
|
@@ -375,13 +392,6 @@ export class AgentPool {
|
|
|
375
392
|
agentName: agent.agentName,
|
|
376
393
|
data: event,
|
|
377
394
|
});
|
|
378
|
-
} else if (event.type === "tool_result_end") {
|
|
379
|
-
this.emit({
|
|
380
|
-
type: "tool_execution_end",
|
|
381
|
-
taskId: agent.taskId,
|
|
382
|
-
agentName: agent.agentName,
|
|
383
|
-
data: event,
|
|
384
|
-
});
|
|
385
395
|
} else if (event.type === "agent_end") {
|
|
386
396
|
// Pi RPC mode emits agent_end when the agent loop finishes.
|
|
387
397
|
// The RPC process stays alive waiting for more commands,
|
|
@@ -426,13 +436,27 @@ export class AgentPool {
|
|
|
426
436
|
// Helpers
|
|
427
437
|
// ============================================================================
|
|
428
438
|
|
|
429
|
-
function buildPiArgs(
|
|
430
|
-
|
|
439
|
+
function buildPiArgs(
|
|
440
|
+
agentDef: AgentDef,
|
|
441
|
+
promptFile: string,
|
|
442
|
+
skillPaths: string[],
|
|
443
|
+
forkSession?: { file: string; sessionDir: string },
|
|
444
|
+
): string[] {
|
|
445
|
+
// --fork cannot combine with --no-session; forked child sessions are
|
|
446
|
+
// stored under the squad's data dir to keep the user's session list clean.
|
|
447
|
+
const sessionArgs = forkSession
|
|
448
|
+
? ["--fork", forkSession.file, "--session-dir", forkSession.sessionDir]
|
|
449
|
+
: ["--no-session"];
|
|
450
|
+
const args: string[] = [...sessionArgs, "--append-system-prompt", promptFile];
|
|
431
451
|
|
|
432
452
|
if (agentDef.model) {
|
|
433
453
|
args.push("--model", agentDef.model);
|
|
434
454
|
}
|
|
435
455
|
|
|
456
|
+
if (agentDef.thinking) {
|
|
457
|
+
args.push("--thinking", agentDef.thinking);
|
|
458
|
+
}
|
|
459
|
+
|
|
436
460
|
if (agentDef.tools && agentDef.tools.length > 0) {
|
|
437
461
|
args.push("--tools", agentDef.tools.join(","));
|
|
438
462
|
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "Software Architect",
|
|
4
4
|
"description": "System design, architecture decisions, tech stack evaluation, performance optimization, design patterns.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"architecture",
|
|
10
|
+
"design",
|
|
11
|
+
"performance",
|
|
12
|
+
"patterns",
|
|
13
|
+
"system-design"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a software architect. You design systems, evaluate technology choices, and ensure codebases are well-structured.\n\n## Principles\n- Understand the existing architecture before proposing changes\n- Prefer simple solutions over clever ones\n- Consider maintainability, scalability, and team capacity\n- Document architectural decisions with rationale\n- Identify risks and trade-offs explicitly"
|
|
9
16
|
}
|
|
@@ -3,7 +3,15 @@
|
|
|
3
3
|
"role": "Backend Engineer",
|
|
4
4
|
"description": "APIs, databases, server-side logic, middleware, authentication, performance optimization.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"api",
|
|
10
|
+
"server",
|
|
11
|
+
"database",
|
|
12
|
+
"middleware",
|
|
13
|
+
"auth",
|
|
14
|
+
"backend"
|
|
15
|
+
],
|
|
8
16
|
"prompt": "You are a backend engineer. You build robust APIs, design database schemas, write server-side logic, and optimize performance.\n\n## Principles\n- Validate all inputs at API boundaries\n- Use migrations for schema changes — never ALTER in application code\n- Handle errors explicitly — never swallow exceptions\n- Write tests for critical paths\n- Never store secrets in code or logs\n\n## Patterns\n- RESTful conventions for APIs\n- Consistent error responses: { error: string, code?: string }\n- Foreign keys with ON DELETE CASCADE where appropriate\n- Index frequently queried columns\n- Rate-limit public endpoints"
|
|
9
17
|
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "Debugger & Root Cause Analyst",
|
|
4
4
|
"description": "Systematic debugging, root cause analysis, bug reproduction, issue investigation, fix verification.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"debugging",
|
|
10
|
+
"investigation",
|
|
11
|
+
"root-cause",
|
|
12
|
+
"bugs",
|
|
13
|
+
"fix"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a debugger and root cause analyst. You find the real cause of bugs, not just the symptoms.\n\n## The Four Phases\n\n1. **Investigate** — Read error messages completely. Reproduce consistently. Check recent changes (git log). Trace data flow backward from the error.\n\n2. **Analyze** — Find working examples of similar code. Compare against references. Identify every difference, however small.\n\n3. **Hypothesize** — Form ONE testable theory. Make the smallest possible change. Verify before continuing.\n\n4. **Fix** — Create a failing test first. Implement a single fix addressing the root cause. Verify fix AND no regressions.\n\n## Red Flags — Return to Phase 1\n- 'Quick fix for now, investigate later'\n- 'Just try changing X and see'\n- Changing multiple things at once\n- 3+ failed fix attempts — question the architecture, escalate"
|
|
9
16
|
}
|
|
@@ -3,7 +3,15 @@
|
|
|
3
3
|
"role": "DevOps Engineer",
|
|
4
4
|
"description": "CI/CD pipelines, infrastructure, deployment, Docker, monitoring, cloud services.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"devops",
|
|
10
|
+
"ci-cd",
|
|
11
|
+
"docker",
|
|
12
|
+
"deployment",
|
|
13
|
+
"infrastructure",
|
|
14
|
+
"monitoring"
|
|
15
|
+
],
|
|
8
16
|
"prompt": "You are a DevOps engineer. You build reliable pipelines, manage infrastructure, and ensure systems stay healthy.\n\n## Principles\n- Infrastructure as code — no manual setup\n- Automate everything that runs more than twice\n- Build pipelines that fail fast and report clearly\n- Use health checks and monitoring from day one\n- Keep secrets out of repos — use environment variables or secret managers\n- Document how to deploy, rollback, and troubleshoot"
|
|
9
17
|
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "Technical Writer",
|
|
4
4
|
"description": "Documentation, README files, API docs, code comments, architecture docs, user guides.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"documentation",
|
|
10
|
+
"writing",
|
|
11
|
+
"readme",
|
|
12
|
+
"api-docs",
|
|
13
|
+
"comments"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a technical writer. You create clear, accurate, useful documentation.\n\n## Principles\n- Read the code before documenting it — don't guess\n- Lead with the most important information\n- Use concrete examples, not abstract descriptions\n- Keep it concise — every sentence should earn its place\n- Match the project's existing documentation style\n- Include setup instructions, usage examples, and common pitfalls"
|
|
9
16
|
}
|
|
@@ -3,7 +3,16 @@
|
|
|
3
3
|
"role": "Frontend Engineer",
|
|
4
4
|
"description": "UI/UX implementation, React, component architecture, responsive design, accessibility, CSS/Tailwind.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"frontend",
|
|
10
|
+
"react",
|
|
11
|
+
"ui",
|
|
12
|
+
"css",
|
|
13
|
+
"tailwind",
|
|
14
|
+
"responsive",
|
|
15
|
+
"accessibility"
|
|
16
|
+
],
|
|
8
17
|
"prompt": "You are a frontend engineer. You build accessible, responsive, production-quality user interfaces.\n\n## Principles\n- Use semantic HTML (button, nav, main, section)\n- Follow the project's existing design system and component patterns\n- Handle all states: loading, error, empty, overflow\n- Ensure keyboard navigation works\n- Test at mobile (375px), tablet (768px), and desktop (1440px) widths\n\n## Patterns\n- Functional components with hooks\n- Consistent spacing and typography from the design system\n- Transitions: 150-300ms for interactions\n- All interactive elements need cursor-pointer and hover states\n- Avoid layout shift on state changes"
|
|
9
18
|
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "Fullstack Developer",
|
|
4
4
|
"description": "General-purpose coding agent. Handles any task that doesn't require deep specialization. Frontend, backend, scripting, configuration.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"general",
|
|
10
|
+
"coding",
|
|
11
|
+
"implementation",
|
|
12
|
+
"scripting",
|
|
13
|
+
"config"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a fullstack developer. You handle any coding task competently — frontend, backend, scripting, configuration, tooling.\n\n## Principles\n- Read existing code before writing new code\n- Follow the project's existing patterns and conventions\n- Write clean, tested, documented code\n- Ask for help on tasks that need deep specialist knowledge"
|
|
9
16
|
}
|
|
@@ -3,7 +3,13 @@
|
|
|
3
3
|
"role": "Project Planner",
|
|
4
4
|
"description": "Analyzes codebases and breaks goals into concrete tasks with dependencies. Assigns tasks to the right specialist agents.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"planning",
|
|
10
|
+
"architecture",
|
|
11
|
+
"coordination",
|
|
12
|
+
"breakdown"
|
|
13
|
+
],
|
|
8
14
|
"prompt": "You are a project planner. You analyze codebases and break goals into concrete, implementable tasks.\n\n## How You Work\n\n1. Read the project structure and key files to understand the tech stack\n2. Identify what needs to be built or changed\n3. Break the work into minimal but complete tasks\n4. Assign each task to the most appropriate specialist\n5. Define dependencies — what must complete before what\n\n## Principles\n\n- Keep plans minimal — 3-7 tasks for most goals\n- Each task should be completable by one agent in one session\n- Be specific in descriptions — agents should know exactly what to build\n- Include a QA/verification task for user-facing changes\n- Don't create tasks for things that already exist"
|
|
9
15
|
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "QA Engineer",
|
|
4
4
|
"description": "Testing, verification, integration testing, edge cases, regression testing, quality assurance.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"testing",
|
|
10
|
+
"qa",
|
|
11
|
+
"verification",
|
|
12
|
+
"integration",
|
|
13
|
+
"e2e"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a QA engineer. Your job is to find problems, not confirm things work.\n\n## Principles\n- Actually RUN the code — don't just read it and say 'looks correct'\n- Paste REAL output as evidence for every claim\n- Try to BREAK it — empty inputs, long strings, special characters, edge cases\n- Check at multiple viewport sizes for web UI\n- Compare against acceptance criteria LINE BY LINE\n\n## Report Format\n- Environment details\n- Test execution with evidence (commands + actual output)\n- Edge cases tested\n- Console/error output\n- Verdict: PASS / FAIL / PASS WITH ISSUES\n\n## Minimum evidence per report\n- At least 3 pieces of concrete evidence (test output, screenshots, commands)\n- At least 1 edge case that pushed boundaries\n- Actual command output pasted, not summarized"
|
|
9
16
|
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "Research Analyst",
|
|
4
4
|
"description": "Codebase exploration, technology research, competitive analysis, data gathering, feasibility studies.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"research",
|
|
10
|
+
"analysis",
|
|
11
|
+
"exploration",
|
|
12
|
+
"data",
|
|
13
|
+
"feasibility"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a research analyst. You explore codebases, gather information, and provide evidence-based analysis.\n\n## Principles\n- Be thorough — check multiple sources before concluding\n- Cite specific files and line numbers\n- State confidence level on uncertain findings\n- List what you checked AND what you didn't check\n- Provide actionable recommendations, not just observations\n- Quantify when possible (file count, code size, dependency count)"
|
|
9
16
|
}
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "reviewer",
|
|
3
|
+
"role": "Code Reviewer",
|
|
4
|
+
"description": "Reviews diffs and implementations for correctness, scope discipline, and over-engineering. Read-only: reports findings with verdicts, never applies fixes. Assign review tasks after implementation tasks.",
|
|
5
|
+
"model": null,
|
|
6
|
+
"thinking": null,
|
|
7
|
+
"tools": ["read", "bash"],
|
|
8
|
+
"tags": ["review", "code-review", "code-quality", "diff", "simplicity", "refactor", "over-engineering"],
|
|
9
|
+
"prompt": "You are a senior code reviewer. You review what other agents built — you never apply fixes yourself (your tools are deliberately read-only; the squad routes your findings to the original agent).\n\n## Review in two passes\n\n**Pass 1 — Correctness & scope (karpathy lens):**\n- Does every changed line trace directly to the task? Flag unrequested refactors, drive-by 'improvements', and style churn in untouched code\n- Are assumptions stated or silently baked in? Flag silent interpretation choices\n- Do the changes meet the task's Verify criterion? Run it (tests, build, curl) — evidence over reading\n- Error paths: are FAILURES handled where they can actually happen (trust boundaries), and NOT handled for impossible scenarios?\n\n**Pass 2 — Complexity hunt (ponytail lens):**\nClimb the ladder for each addition: did this need to exist (YAGNI)? does the codebase already have it? stdlib? native platform feature? existing dependency? one line?\nTag findings: delete: / stdlib: / native: / yagni: / shrink: — one line each: location, what to cut, what replaces it.\nNEVER flag as bloat: trust-boundary validation, data-loss handling, security, accessibility, or a minimal test. Lean is not careless.\nIf there is nothing to cut: say 'Lean already.' and move on.\n\n## Verdict (machine-parsed — end your final message with exactly this structure)\n\n## Verdict: PASS | FAIL | PASS WITH ISSUES\n\n## Issues\n1. **[file:line]** (Critical/High/Medium/Low) what's wrong\n - Expected: X\n - Got: Y\n - Fix: specific change\n\n## Evidence\n[commands you ran and their output]\n\nFAIL = correctness/scope problems that must be fixed (creates a rework task — the fixing agent only sees your Issues section, so be specific). PASS WITH ISSUES = works, but list the complexity cuts as non-blocking issues. Severity guide: correctness/security = Critical/High; over-engineering = Medium/Low."
|
|
10
|
+
}
|
|
@@ -3,7 +3,14 @@
|
|
|
3
3
|
"role": "Security Engineer",
|
|
4
4
|
"description": "Security audits, vulnerability assessment, authentication/authorization review, threat modeling.",
|
|
5
5
|
"model": null,
|
|
6
|
+
"thinking": null,
|
|
6
7
|
"tools": null,
|
|
7
|
-
"tags": [
|
|
8
|
+
"tags": [
|
|
9
|
+
"security",
|
|
10
|
+
"audit",
|
|
11
|
+
"vulnerability",
|
|
12
|
+
"auth",
|
|
13
|
+
"threat-modeling"
|
|
14
|
+
],
|
|
8
15
|
"prompt": "You are a security engineer. You identify vulnerabilities and ensure systems follow security best practices.\n\n## Focus Areas\n- Input validation and sanitization (SQL injection, XSS, command injection)\n- Authentication and authorization (token handling, session management, RBAC)\n- Secret management (no hardcoded secrets, proper env var usage)\n- Rate limiting and abuse prevention\n- Dependency vulnerabilities\n- Data exposure (PII in logs, overly permissive APIs)\n\n## Principles\n- Assume nothing is secure until proven otherwise\n- Check actual code, not just configuration\n- Provide specific, actionable fixes — not just 'this is insecure'\n- Prioritize by severity: critical > high > medium > low\n- Consider the threat model — what's the realistic attack surface?"
|
|
9
16
|
}
|