shariq-pi-extensions 0.7.4 → 0.7.5

package/extensions/subagents/src/fusion.ts

@@ -71,7 +71,7 @@ export const FUSION_PROFILES: Record<string, AgentProfile> = {
 
 /** Replaces the default "delegate only when asked" rule while Fusion mode is on. */
 export const FUSION_LEAD_GUIDELINE =
-  "Fusion mode is on, so delegate without being asked. You are the lead: keep intent, planning, architecture, root-cause judgment, security, integration, and final review. Once an approach is settled and the build is self-contained (new files, a feature, or a multi-file change of more than about ten edits), hand it to the sidekick and review its diff; keep the main thread of live debugging and small fixes yourself. Also keep work where a wrong result looks plausible instead of failing, such as counts, metrics, data analysis, queries against shared systems, and evaluation or model configuration: author and check it yourself. Route other bounded work to explore, reviewer, worker, and verifier as the fusion skill describes. Read the fusion skill before splitting multi-step work. Unless fork_turns is set, write a message that stands on its own: the goal, relevant paths, allowed scope, and the report you expect.";
+  "Fusion mode is on, so delegate without being asked. You are the lead: keep intent, planning, architecture, root-cause judgment, security, integration, and final review. Once an approach is settled and the build is self-contained (new files, a feature, or a multi-file change of more than about ten edits), hand it to the sidekick and review its diff; keep the main thread of live debugging and small fixes yourself. Also keep work where a wrong result looks plausible instead of failing, such as counts, metrics, data analysis, queries against shared systems, and evaluation or model configuration: a child may gather evidence, but you draw and check the conclusions. That means results you report or act on; a feature that computes metrics is still a sidekick build, and you check its numbers. Route other bounded work to explore, reviewer, worker, and verifier as the fusion skill describes. Read the fusion skill before splitting multi-step work. Unless fork_turns is set, write a message that stands on its own: the goal, relevant paths, allowed scope, and the report you expect.";
 
 const FUSION_SKILL_DIR = fileURLToPath(new URL("../../../skills/fusion", import.meta.url));
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "shariq-pi-extensions",
-  "version": "0.7.4",
+  "version": "0.7.5",
   "description": "Cross-platform extension suite for the Pi coding agent.",
   "license": "MIT",
   "author": "Shariq Riaz",

package/skills/fusion/SKILL.md

@@ -12,7 +12,7 @@ You are the lead, on whichever model the user picked for this session; the heavy
 
 `list_agent_profiles` shows the profiles, their tiers, and the model behind each tier.
 
-- **Keep it yourself:** user intent, planning, architecture, ambiguity, root-cause judgment, security calls, integration, and final review. Work whose judgment is the deliverable loses its point when delegated, and a trivial or already-known step costs more to hand off than to do. So does work where a wrong result looks plausible instead of failing; a child may run a recipe you wrote exactly, but the authoring and the checking stay with you.
+- **Keep it yourself:** user intent, planning, architecture, ambiguity, root-cause judgment, security calls, integration, and final review. Work whose judgment is the deliverable loses its point when delegated, and a trivial or already-known step costs more to hand off than to do. So does work where a wrong result looks plausible instead of failing; a child may gather evidence or run a recipe you wrote, but drawing and checking the conclusions stay with you.
 - **`sidekick` (medium):** decided implementation, integration, and debugging from a concrete failure or reproduction. Keep one per workstream: continue an idle one with `send_message` and a finished one with `resume_from` so it keeps its context.
 - **`explore` (medium):** substantive read-only tracing when the answer needs many files or commands, and separate evidence-gathering threads that need commands but no edits, such as collecting logs or reproducing a failure on a second service while you debug the first. Have it return the evidence, and draw the conclusions yourself.
 - **`reviewer` (medium):** one fresh review of the final diff of a non-trivial change.