@zaganjade/pi-multi-skill 1.3.2 → 1.3.4

package/README.md

@@ -207,17 +207,37 @@ Pi collapses user messages only when the **entire** message matches its native s
 <skill name="skill-a, skill-b" location="pi-multi-skill">
   <manually_attached_skills count="2" bundles="@debug">
     …priority rules…
-    <skill name="skill-a" location="/path/to/SKILL.md">…</skill>
-    <skill name="skill-b" location="/path/to/SKILL.md">…</skill>
+    <skill name="skill-a" location="/path/to/SKILL.md">…</skill-block>
+    <skill name="skill-b" location="/path/to/SKILL.md">…</skill-block>
     <user_query>Your instructions here</user_query>
   </manually_attached_skills>
 </skill>
+
+Your instructions here
 ```
 
 - **1 skill, no extras** → single native block → `[skill] skill-name`
 - **2+ skills** (or bundles/instructions) → outer native block hides all inner content → `[skill] a, b, c` (Ctrl+O to expand)
+- The user's free-text instructions are appended AFTER `</skill>` as Pi's
+  `userMessage` tail, so they render as a normal visible message below the
+  collapsed header: `[skill] a, b (ctrl+o to expand)` + `your instructions`.
 - Inner `<manually_attached_skills bundles="…">` is preserved for **pi-usage** bundle attribution
 
+> **Why inner blocks close with `</skill-block>` and instructions live outside the envelope?**
+> Two constraints shaped this. First, Pi's display parser matches the outer
+> envelope with a non-greedy regex and cannot tell a nested `</skill>` apart
+> from the envelope's own closing tag — with nested `</skill>`, any trailing
+> section caused the parser to split at the last inner `</skill>` and **leak**
+> `<user_query>…`, `</manually_attached_skills>`, and the outer `</skill>` into
+> the rendered user message as raw tags. Inner blocks therefore open with
+> `<skill name="…">` (kept so **pi-usage** still attributes each skill via
+> `/<skill\s+name="([^"]+)"/g`) but close with the non-colliding `</skill-block>`,
+> which neither parser's regex can match. Second, so the user's typed
+> instructions stay visible (not hidden inside the collapsed block) while the
+> skill *content* collapses, instructions are placed after `</skill>\n\n` as
+> plain text — exactly Pi's native `userMessage` tail. Covered by
+> `node --test test/parse-leak.test.mjs`.
+
 ### Session hints
 
 After each user turn, the extension may suggest a relevant bundle (non-blocking `info` notification):

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@zaganjade/pi-multi-skill",
-	"version": "1.3.2",
+	"version": "1.3.4",
 	"description": "Chain multiple skills via /skills — bundles (JSON/YAML), load modes, BMAD --auto, /skills-last, /skills-setup, conflict resolution, parallel dispatch, activation stats, bundle attribution for pi-usage.",
 	"type": "module",
 	"keywords": [
@@ -21,6 +21,9 @@
 		"url": "https://github.com/ZaganJade/pi-extension/issues"
 	},
 	"main": "./src/index.ts",
+	"scripts": {
+		"test": "node --test test/"
+	},
 	"files": [
 		"src/",
 		"README.md",

package/src/build.ts

@@ -7,6 +7,26 @@ import { buildParallelDispatchBlock } from "./subagents.ts";
 
 const SUBAGENT_STOP = "<SUBAGENT-STOP>";
 const MULTI_SKILL_LOCATION = "pi-multi-skill";
+
+/**
+ * Closing tag for INNER per-skill blocks inside a multi-skill payload.
+ *
+ * MUST NOT be `</skill>`. Pi's display parser (`parseSkillBlock`) uses a
+ * non-greedy regex that cannot distinguish a nested `</skill>` from the outer
+ * envelope's own closing tag. With nested `</skill>`, the parser split at the
+ * last inner `</skill>` and dumped every trailing section (`<user_query>`,
+ * `</manually_attached_skills>`, the outer `</skill>`) into the rendered
+ * `userMessage` — appearing as raw tags in the chat. Using a non-colliding
+ * closer keeps the outer envelope parseable so those sections stay inside the
+ * collapsed content.
+ *
+ * The opening tag stays `<skill name="…" location="…">` so pi-usage can still
+ * attribute each skill individually via `/<skill\s+name="([^"]+)"/g`; pi-usage
+ * only reads openings, so a non-colliding closer is safe. `</skill-block>` is
+ * chosen because it contains neither `</skill>` nor `<skill ` (with a space),
+ * so it cannot match either parser's regex.
+ */
+const INNER_SKILL_CLOSE = "</skill-block>";
 const SKILL_CHECK_MARKERS = [
 	"If you think there is even a 1% chance a skill might apply",
 	"Invoke relevant or requested skills BEFORE any response",
@@ -36,6 +56,21 @@ export function formatPiSkillBlock(
 	return `<skill name="${escapeXml(name)}" location="${escapeXml(location)}">\n${content}\n</skill>`;
 }
 
+/**
+ * Wrap a single skill's content for inclusion INSIDE a multi-skill payload.
+ *
+ * Uses a non-colliding closer (see INNER_SKILL_CLOSE) so the outer native skill
+ * block parses cleanly with no tag leakage. The opening stays
+ * `<skill name="…">` to preserve pi-usage per-skill attribution.
+ */
+function formatInnerSkillItem(
+	name: string,
+	location: string,
+	content: string,
+): string {
+	return `<skill name="${escapeXml(name)}" location="${escapeXml(location)}">\n${content}\n${INNER_SKILL_CLOSE}`;
+}
+
 export function isPiSkillBlock(text: string): boolean {
 	return PI_SKILL_BLOCK_RE.test(text);
 }
@@ -163,7 +198,7 @@ function renderSkillBlock(
 			content = formatFullBody(skill, body);
 	}
 
-	return formatPiSkillBlock(skill.name, skill.filePath, content);
+	return formatInnerSkillItem(skill.name, skill.filePath, content);
 }
 
 function buildAgentPayload(
@@ -219,12 +254,11 @@ function buildAgentPayload(
 		);
 	}
 
-	if (options.instructions) {
-		parts.push("");
-		parts.push("<user_query>");
-		parts.push(options.instructions);
-		parts.push("</user_query>");
-	}
+	// NOTE: options.instructions is intentionally NOT added inside the payload.
+	// It is appended after the outer </skill> envelope in buildCombinedMessage
+	// so Pi renders it as the visible user message (the `userMessage` tail of
+	// parseSkillBlock) while the skill content stays collapsed. Wrapping it in
+	// <user_query> tags here would leak those tags into the rendered message.
 
 	if (notFound.length > 0) {
 		parts.push("");
@@ -302,6 +336,15 @@ export function buildCombinedMessage(
 		message = expandedBlocks[0];
 	}
 
+	// Surface the user's free-text instructions as Pi's `userMessage` tail
+	// (the optional text after `</skill>\n\n`). Pi renders the skill block
+	// collapsed as `[skill] a, b (ctrl+o to expand)` and this tail as a normal
+	// visible user message below it — which is the desired display. Plain text
+	// only: wrapping tags here would render literally.
+	if (options.instructions && expandedBlocks.length > 0) {
+		message = `${message}\n\n${options.instructions}`;
+	}
+
 	return {
 		message,
 		notFound,