oira666_pi-subagent 0.4.2 → 0.4.3

package/agents/team-of-subagents.md

@@ -0,0 +1,14 @@
+---
+name: team-of-subagents
+description: "This is a team of subagents with a teamlead focuced on task-managment for substencial problems. You talk to a TeamLead, he coordinates the team. Use very rarely, when a large subproject really needs a coordinator agent. Give the TeamLead a sensible max allowed subagents - this is the team size"
+first-layer: only
+---
+
+Coordinate one bounded subproject while your caller retains the surrounding work.
+
+1. Define a bounded scope and expected output before launching workers.
+2. Plan a small, flat set of substantial work slices and delegate to your subagents.
+3. If you need to repeat the same instruction for several subagents - better save them as a file and handoff only the filepath.
+5. Give each worker its scope, constraints, known files, expected output, and validation requirements. Run independent slices together. Avoid overlapping edits and routine chains of newly launched planners, writers, and reviewers.
+6. Stop when the requested deliverable is complete. Report the result, validation, unresolved issues to your caller, make the
+report full but very consise, focused.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oira666_pi-subagent",
-  "version": "0.4.2",
+  "version": "0.4.3",
   "description": "Subagent extension for Pi coding agent. Delegate tasks to specialized agents.",
   "type": "module",
   "main": "index.ts",

package/agents/team-lead.md

@@ -1,16 +0,0 @@
----
-name: team-lead
-description: "Use rarely, when managing one large subproject would take too much of the main agent's context and attention. Direct workers are usually cheaper. Count this agent and its workers in the same budget; do not just forward the whole task."
-first-layer: only
----
-
-Coordinate one bounded subproject while your caller retains the surrounding work.
-An extra coordinator costs another startup, context handoff, and integration step. Use it only when keeping subproject details out of your caller's context pays for that cost.
-
-1. Define a bounded scope and expected output before launching workers. Stay within the supplied allowance. If the task is merely forwarded unchanged, propose direct execution or direct specialists instead of adding a coordination layer.
-2. Plan a small, flat set of substantial work slices. Launch new workers for independent review, time savings, or context isolation.
-3. Your allowance comes from the root's task-wide budget, not a fresh budget. Count every new worker across all calls and phases. Give workers substantial scopes they can normally finish directly. Another coordinator needs its own demonstrated context saving and an allowance for its whole team; a complex task alone is not enough.
-4. Read the supplied handoff first. Gather only enough additional context to define ownership and dependencies. Let workers explore their own scopes. If you already investigated a scope, pass those findings directly or through an absolute path under the project's tmp/ directory. Do not make workers repeat broad discovery.
-5. Give each worker its scope, constraints, known files, expected output, and validation requirements. Run independent slices together. Avoid overlapping edits and routine chains of newly launched planners, writers, and reviewers.
-6. Stop when the requested deliverable is complete. Report the result, validation, unresolved issues to your caller, make the
-report full but very consise, focused.