@sangyaahub/pi-marg 1.0.5 → 1.0.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sangyaahub/pi-marg",
-  "version": "1.0.5",
+  "version": "1.0.7",
   "description": "A governed, model-routed development path for Pi Agent and Oh My Pi.",
   "type": "module",
   "license": "MIT",

package/rules/auto-mode.md

@@ -10,6 +10,7 @@ For every new substantive user task, load and follow the `auto-mode-router` skil
 - Do not restart intake for acknowledgements, clarifications, approval replies, or follow-ups that belong to the active task.
 - If the conversation already contains an active Auto Mode session record, reuse it. Start a new intake only when the user starts a materially different task or invokes `/auto-reset`.
 - The first intake question is always whether the work is for a job/client or personal.
+- Ask work context, work type, and skill mode through the host selection tool (`ask` on OMP). One stage at a time. Do not ask the user to type a number.
 - Confirm one of work types 1–7, then confirm skill mode 1–4 before execution.
 - After skill mode, use the live `auto_model_route` catalog and record required A/B/C/D choices. A and C must use different underlying models; B and D must use different underlying models.
 - Activate the saved model before each A/B/C/D stage. Never guess or pin a version absent from the active Pi or OMP registry.

package/scripts/install.sh

@@ -71,4 +71,4 @@ if [[ "${runtime}" == "omp" || "${runtime}" == "both" ]]; then
   omp plugin install --scope user pi-marg@pi-marg-marketplace
 fi
 
-echo "PiMarg v1.0.5 installed for ${runtime}. Start a fresh runtime session, then run /pi-marg."
+echo "PiMarg v1.0.6 installed for ${runtime}. Start a fresh runtime session, then run /pi-marg."

package/scripts/validate.sh

@@ -45,7 +45,7 @@ bun -e '
   const packageJson = await Bun.file("package.json").json();
   const marketplace = await Bun.file(".omp-plugin/marketplace.json").json();
   if (packageJson.name !== "@sangyaahub/pi-marg") throw new Error("Unexpected package name");
-  if (packageJson.version !== "1.0.5") throw new Error("package.json must be v1.0.5");
+  if (packageJson.version !== "1.0.7") throw new Error("package.json must be v1.0.7");
   if (packageJson.license !== "MIT") throw new Error("package.json must declare MIT");
   if (packageJson.author !== "Sangyaa") throw new Error("Unexpected package author");
   if (!packageJson.keywords?.includes("pi-package")) throw new Error("Pi catalog keyword is missing");

package/skills/auto-mode-router/SKILL.md

@@ -7,7 +7,7 @@ description: Classify a new work request, select one development-method skill sp
 
 Turn a user request into one controlled workflow.
 
-1. Read [intake-and-state.md](references/intake-and-state.md) and complete the intake stages in order.
+1. Read [intake-and-state.md](references/intake-and-state.md) and complete the intake stages in order. Ask work context, work type, and skill mode with the host selection tool, one stage at a time.
 2. After the user selects mode 1–4, read [routing-matrix.md](references/routing-matrix.md) and select exactly one primary skill spine.
 3. Read [session-ledger.md](references/session-ledger.md), create the neutral Markdown ledger, and identify the selected spine's authoritative planning artifact.
 4. Read [models-and-tools.md](references/models-and-tools.md). Call `auto_model_route` with `action: catalog` and the confirmed work type, present the live choices, and save each required A/B/C/D selection. The runtime rejects A=C and B=D. Then save two distinct runtime-only recovery models with `action: select_fallback`: high first, low second.

package/skills/auto-mode-router/references/intake-and-state.md

@@ -16,16 +16,24 @@ CONTEXT ─► TYPE ─► SKILL MODE ─► MODELS ─► RUNTIME ─► ADD-ON
 
 Ask one intake stage at a time. A clear user prompt can support a proposed classification, but it does not remove the required confirmation.
 
+## How to ask
+
+Stages 1–3 are selection questions. Call the host's blocking question tool when that tool is already in the current tool list. On OMP the tool is `ask`. Elsewhere, use the listed equivalent (`AskUserQuestion`, `ask_user_question`, or `vscode_askquestions`). Do not probe for a tool that is not listed.
+
+Put each choice in `options` as a short label with no leading number. Set `recommended` to the inferred option when the tool accepts it. Then stop and wait. Do not print the choices as a numbered chat list, and do not ask for a typed number or a combined reply such as `2 / 7 / 4`.
+
+Work type has seven options. Pass all seven in that one question. The ask tool's usual "2–5 options" note is for ordinary clarifications; it does not apply to this fixed list, and it is not a reason to drop a type or switch to typed numbers.
+
+If no question tool is listed, or a real call returns an error, render one numbered list in chat and accept the number. The live model catalog in stage 4 always uses that numbered path, because a full provider or model list does not fit the selection UI.
+
 ## Stage 1 — work context
 
-Ask first with numbered options:
+Ask with the question tool:
 
-> Is this for your job/client, or is it personal work?
->
-> 1. Job/client
-> 2. Personal
+- Question: Is this for your job/client, or is it personal work?
+- Options: `Job/client`, `Personal`
 
-Record exactly one canonical value (`job-client` or `personal`); numbering is presentation-only:
+Record exactly one canonical value (`job-client` or `personal`):
 
 - `job-client`: Do not add Sangyaa branding, name, logo, metadata, footer, or promotional language. Use the employer/client/project brand already in scope.
 - `personal`: Existing project branding wins. Sangyaa branding is opt-in, never automatic.
@@ -34,23 +42,26 @@ Do not start code, research, or planning before this answer unless the user is a
 
 ## Stage 2 — work type
 
-Infer the most likely type, state it plainly, and ask the user to confirm. If ambiguous, show the relevant choices only.
+Infer the most likely type, name it in the question, mark that option recommended, and ask with the question tool. If ambiguous, show only the relevant choices. These labels are the options; the number is the recorded type id, not a chat prefix.
 
-1. New idea or development from scratch: brainstorming and analysis.
-2. New feature for an existing repository.
-3. Improve an existing feature in an existing repository.
-4. Proactive bug discovery or bug fix in an existing repository.
-5. Security review or security fixes.
-6. Thoughts, explanation, or another question about an existing repository or feature.
-7. Business, sales, or other non-technical analysis.
+1. `New idea or development from scratch` — brainstorming and analysis.
+2. `New feature for an existing repository`
+3. `Improve an existing feature in an existing repository`
+4. `Proactive bug discovery or bug fix in an existing repository`
+5. `Security review or security fixes`
+6. `Thoughts, explanation, or another question about an existing repository or feature`
+7. `Business, sales, or other non-technical analysis`
 
 If one request contains multiple types, pick the type that owns the immediate outcome and record later types as follow-on phases. Do not open multiple workflow spines.
 
 ## Stage 3 — skill mode
 
-Ask:
+Ask with the question tool. Question: Which method should own this task? Options:
 
-> Which method should own this task: 1) Compound Engineering, 2) Superpowers, 3) GSD Core, or 4) choose the best one for me?
+1. `Compound Engineering`
+2. `Superpowers`
+3. `GSD Core`
+4. `Choose the best one for me`
 
 - Mode 1: use the Compound Engineering mapping for the confirmed work type.
 - Mode 2: use the Superpowers mapping.
@@ -65,7 +76,7 @@ Catalog presentation is provider-first:
 
 1. Show **every** authenticated provider as numbered options `1.`, `2.`, … (including Devin when present). Never omit a logged-in provider and never curate down to Claude/Codex/Cursor only.
 2. After the user picks a provider, call `auto_model_route` again with the same work type and `provider=<name>` so the tool lists **every** model for that provider as numbered `1.`, `2.`, …
-3. Ask the user with those numbered labels. If the option UI cannot fit the full list, paste the numbered list into the question text and accept the number or exact selector.
+3. Ask in chat with those numbered labels, and accept the number or the exact selector. Do not put a full provider or model list into the selection tool; it truncates and hides logged-in providers.
 
 Interactive `/pi-marg` uses the same provider → model two-step with numbered labels.
 
@@ -125,6 +136,8 @@ ledger: <path>
 
 Reuse this state for normal follow-ups. Start over only when the user explicitly resets it or introduces a materially different outcome.
 
+The v2 model route persists `boundary` (`Job/client` or `Personal`) and `skillMode` with the A/B/C/D selectors and backups. Reopening `/pi-marg` highlights those saved values. The conversational `context:` and `mode:` lines above are the same facts in the ledger's shorthand; they are not a second configuration store.
+
 ## Availability check
 
 Before declaring the task ready: