@evo-hq/pi-evo 0.4.2 → 0.4.3-alpha.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evo-hq/pi-evo",
-  "version": "0.4.2",
+  "version": "0.4.3-alpha.1",
   "description": "Evo plugin for pi-coding-agent: optimize/discover/subagent skills + mid-run inject extension.",
   "publishConfig": {
     "access": "public"

package/skills/optimize/SKILL.md

@@ -214,6 +214,7 @@ Per host, the spawn shape matters because evo's loop depends on *completion noti
 - **openclaw** — `sessions_spawn deliver:false`; notifications delivered similarly.
 - **opencode** — *batch-parallel only* (no background notifications). Fire N `task` calls in ONE assistant message; all `tool_result`s return together when the slowest finishes. Plan all parallel work (including non-task tools) in that single message — opencode cannot interleave reasoning across turns while subagents run.
 - **pi** — *batch-parallel via extension*. Pi's default toolkit has no subagent primitive; `evo install pi` ensures the `pi-subagents` package is present, which registers a `subagent` tool. Fire N `subagent` calls in ONE assistant message; all results return together when the slowest finishes (same shape as opencode). If the `subagent` tool isn't available, fall back to running experiments sequentially in your own turn (`evo new` → `evo run` per attempt) and tell the user to `pi install npm:pi-subagents` for proper fanout.
+- **cursor** — use Cursor's native Subagents to run each brief in parallel (own context per subagent), and fan them out in a single batch. If native subagents aren't available, fall back to one `cursor-agent -p "<brief>" --force` per brief (background+notify shape, like claude-code) so each runs its brief to completion in its own headless session. Inject reaches the orchestrator via the `postToolUse`/`sessionStart` hooks `evo install cursor` wires; the directive banner can arrive on either channel.
 
 Respect the host's concurrency cap; batch if N exceeds it.