shariq-pi-extensions 0.7.3 → 0.7.5
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.
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
Controls what ordinary **Enter** does when the interactive Pi agent is already running:
|
|
4
4
|
|
|
5
5
|
- `steer` (default) queues the message before the agent's next model step.
|
|
6
|
-
- `interrupt` signals Pi's active abort controller immediately, retains the submitted text and images, then starts a fresh turn at Pi's safe `agent_settled` boundary. Multiple inputs received during cancellation are preserved in order in that replacement turn.
|
|
6
|
+
- `interrupt` signals Pi's active abort controller immediately, retains the submitted text and images, then starts a fresh turn at Pi's safe `agent_settled` boundary. If another extension starts a run at that boundary first, the retained input steers that run instead. Multiple inputs received during cancellation are preserved in order in that replacement turn.
|
|
7
7
|
- `follow-up` queues the message until the active run finishes.
|
|
8
8
|
|
|
9
9
|
Use `/input-mode` for the picker or `/input-mode steer|interrupt|follow-up` for direct selection. The global choice is stored with restrictive permissions in `<agent-dir>/input-mode.json`; non-default modes appear in Pi's status area.
|
|
@@ -93,7 +93,8 @@ export function createInputModeExtension(options: InputModeExtensionOptions = {}
|
|
|
93
93
|
pi.on("agent_settled", () => {
|
|
94
94
|
if (pendingInterrupts.length === 0) return;
|
|
95
95
|
const input = mergeInputs(pendingInterrupts.splice(0));
|
|
96
|
-
|
|
96
|
+
// Another settled action may start a run first; the interrupting input then steers it.
|
|
97
|
+
pi.sendUserMessage(input, { deliverAs: "steer", expandPromptTemplates: true });
|
|
97
98
|
});
|
|
98
99
|
|
|
99
100
|
pi.on("session_shutdown", () => {
|
|
@@ -71,7 +71,7 @@ export const FUSION_PROFILES: Record<string, AgentProfile> = {
|
|
|
71
71
|
|
|
72
72
|
/** Replaces the default "delegate only when asked" rule while Fusion mode is on. */
|
|
73
73
|
export const FUSION_LEAD_GUIDELINE =
|
|
74
|
-
"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:
|
|
74
|
+
"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.";
|
|
75
75
|
|
|
76
76
|
const FUSION_SKILL_DIR = fileURLToPath(new URL("../../../skills/fusion", import.meta.url));
|
|
77
77
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "shariq-pi-extensions",
|
|
3
|
-
"version": "0.7.
|
|
3
|
+
"version": "0.7.5",
|
|
4
4
|
"description": "Cross-platform extension suite for the Pi coding agent.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "Shariq Riaz",
|
|
@@ -98,10 +98,10 @@
|
|
|
98
98
|
}
|
|
99
99
|
},
|
|
100
100
|
"devDependencies": {
|
|
101
|
-
"@earendil-works/pi-agent-core": "^1.
|
|
102
|
-
"@earendil-works/pi-ai": "^1.
|
|
103
|
-
"@earendil-works/pi-coding-agent": "^1.
|
|
104
|
-
"@earendil-works/pi-tui": "^1.
|
|
101
|
+
"@earendil-works/pi-agent-core": "^1.2.0",
|
|
102
|
+
"@earendil-works/pi-ai": "^1.2.0",
|
|
103
|
+
"@earendil-works/pi-coding-agent": "^1.2.0",
|
|
104
|
+
"@earendil-works/pi-tui": "^1.2.0",
|
|
105
105
|
"@types/node": "^26.6.4",
|
|
106
106
|
"typebox": "^1.3.34",
|
|
107
107
|
"typescript": "^7.0.2"
|
package/skills/fusion/SKILL.md
CHANGED
|
@@ -12,7 +12,7 @@ You are the lead, on whichever model the user picked for this session; the heavy
|
|
|
12
12
|
|
|
13
13
|
`list_agent_profiles` shows the profiles, their tiers, and the model behind each tier.
|
|
14
14
|
|
|
15
|
-
- **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
|
|
15
|
+
- **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.
|
|
16
16
|
- **`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.
|
|
17
17
|
- **`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.
|
|
18
18
|
- **`reviewer` (medium):** one fresh review of the final diff of a non-trivial change.
|