shariq-pi-extensions 0.7.0 → 0.7.1

package/extensions/subagents/src/fusion.ts

@@ -70,7 +70,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; hand decided, bounded work to the sidekick, explore, reviewer, worker, and verifier profiles, and do trivial or judgment-heavy work yourself. 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: 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.";
 
 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.0",
+  "version": "0.7.1",
   "description": "Cross-platform extension suite for the Pi coding agent.",
   "license": "MIT",
   "author": "Shariq Riaz",

package/skills/fusion/SKILL.md

@@ -12,14 +12,16 @@ 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.
+- **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.
 - **`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.
+- **`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.
 - **`worker` (light):** mechanical edits, renames, boilerplate, docs, and narrow tests that are fully specified.
 - **`verifier` (light):** builds, tests, linters, and reproductions. It reports failures and does not fix them.
 - **`general-purpose` (heavy):** rare; for hard, decided work after the sidekick hits a concrete blocker.
 
+Light output is only as good as your check of it, so give light profiles work whose result is cheap to check, such as an edit that applies or a command that passes, and not analysis, diagnosis, or summaries you would pass on unchecked.
+
 ## Write the message
 
 Children start without your conversation. Settle interfaces, consequential choices, and hypotheses before dispatch, and specify rather than describe:
@@ -41,7 +43,7 @@ Children treat the known facts as settled and reopen them only for a concrete ga
 
 - A child's report is a claim; its diff and check output are the evidence. Read the whole change before acting, then send every correction in one follow-up to the same child.
 - Don't rerun checks a child already passed unless the evidence is missing or looks wrong, or the inputs changed since.
-- Treat a root cause without a shown failing path as a hypothesis.
+- Treat a root cause without a shown failing path, a ranked list of candidate causes, and delegated analysis as hypotheses; check the load-bearing findings yourself before you state them as fact.
 - Answer `ask_parent` questions that are yours to decide with `reply_question`. Ask the user only for decisions that need their authority.
 - Use one reviewer, not panels. In measured review runs, extra reviewers raised false positives without finding more defects. When two children disagree, check the disputed fact yourself instead of adding a voter.