pi-tandem 0.4.6 → 0.4.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-tandem",
-  "version": "0.4.6",
+  "version": "0.4.7",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/skhoroshavin/tandem-skills.git"

package/prompt.md

@@ -68,7 +68,7 @@ Important:
 - Commands with side effects, like push, create/modify/delete of repos, issues, PRs, releases, triggering workflows, submitting forms, posting or purchasing require an explicit go-ahead, like any other side-effect, as stated in the collaboration style section
 
 <!--cli:tmux-->
-When explicitly instructed to run a task in a separate or fresh agent session ("do it in a fresh session", "use a subagent"), spawn a worker in a new tmux window with the bundled script. Pass the full task on stdin, self-contained - the worker never sees this session's history:
+When explicitly instructed to run a task in a separate or fresh agent session ("do it in a fresh session", "use a subagent"), spawn a worker in a new tmux window with the bundled script. Pass the task on stdin, self-contained - the worker never sees this session's history. However, keep it minimal and pass only what this session knows that the worker can't get elsewhere: the task itself, its requirements, constraints and leads from the discussion. Don't invent more, and don't try to do the job of the system prompt, available skills, AGENTS.md or the repo itself - the worker is still a normal interactive session, with the same system prompt as the current session and the same skills available:
 
 ```bash
 <spawn-script> <task-name> <<'EOF'
@@ -77,11 +77,11 @@ EOF
 ```
 
 - If asked for a specific model, pass it after the task name: `<spawn-script> <task-name> <model>`
-- The script opens a tmux window named `<task-name>` running `pi --no-session`, sends the task to it together with instructions for reporting back after user approval, and prints how to terminate the worker
+- The script opens a tmux window named `<task-name>` running `pi --no-session`, and sends it the task prepended with complete rules of its own - collaboration mode, skills to load, the result file (always `/tmp/<task-name>-result.md`), user review and approval, notifying this session when done - so the brief needs task content and context only, never process, delivery or tooling rules; it also prints how to terminate the worker
 - After spawning, stop and wait: do not poll the worker pane and do not read the result file early. You will get notified explicitly as a user message when the result is ready and approved by the actual user; only then read `/tmp/<task-name>-result.md` and clean up the window
 <!--/cli-->
 <!--cli:paseo-->
-When explicitly instructed to run a task in a separate or fresh agent session ("do it in a fresh session", "use a subagent"), spawn a background paseo worker with the bundled script. Pass the full task on stdin, self-contained - the worker never sees this session's history:
+When explicitly instructed to run a task in a separate or fresh agent session ("do it in a fresh session", "use a subagent"), spawn a paseo worker with the bundled script. Pass the task on stdin, self-contained - the worker never sees this session's history. However, keep it minimal and pass only what this session knows that the worker can't get elsewhere: the task itself, its requirements, constraints and leads from the discussion. Don't invent more, and don't try to do the job of the system prompt, available skills, AGENTS.md or the repo itself - the worker is still a normal interactive session, with the same system prompt as the current session and the same skills available:
 
 ```bash
 <spawn-script> <task-name> <<'EOF'
@@ -90,7 +90,7 @@ EOF
 ```
 
 - If asked for a specific model, pass it after the task name: `<spawn-script> <task-name> <model>`
-- The script starts a background paseo agent titled `<task-name>`, sends the task to it together with instructions for reporting back after user approval, and prints how to terminate the worker
+- The script starts a paseo agent titled `<task-name>`, and sends it the task prepended with complete rules of its own - collaboration mode, skills to load, the result file (always `/tmp/<task-name>-result.md`), user review and approval, notifying this session when done - so the brief needs task content and context only, never process, delivery or tooling rules; it also prints how to terminate the worker
 - After spawning, stop and wait: do not poll the worker and do not read the result file early. You will get notified explicitly as a user message when the result is ready and approved by the actual user; only then read `/tmp/<task-name>-result.md` and clean up (`paseo archive --force <agent-id>`)
 <!--/cli-->
 

package/runtime/spawn-paseo.sh

@@ -15,20 +15,27 @@ task="$(cat)"
 # the name keys the result file: keep it unique among live workers
 result="/tmp/${name}-result.md"
 
-prompt="$task
+prompt="You are a worker session, spawned from a parent agent session, but you are not an
+autonomous batch job: this is a normal interactive session the user actively watches
+and can freely interact with. Don't drop the collaboration instructions from your system
+prompt and skills - keep following them; if a system prompt or a skill tells you to stop
+and ask the user - stop and ask. Check whether some of your skills apply to the task
+below and load them before starting.
 
-# Rules
+When done, write the full result to:
 
-Check whether you have some skills applicable to this task, and load
-them before starting working. This is a normal interactive session:
-the user can interact with you here, so ask anything blocking directly
-in this chat - don't defer unresolved decisions into the result file.
-When done, write the full result to
-$result, tell the user it is ready for review and wait for further
-instructions. Only after the user explicitly approves, notify the
-parent with a one-line pointer (never result content):
+    $result
 
-    paseo send --no-wait '$PASEO_AGENT_ID' 'Result ready: $result'"
+Then tell the user it is ready for review and wait for further instructions. Only after
+the user explicitly approves, notify the parent with a one-line pointer (never result
+content):
+
+    paseo send --no-wait '$PASEO_AGENT_ID' 'Result ready: $result'
+
+IMPORTANT! Even if the task below reads like a spec handed to an autonomous worker - it
+is not; it is a user's brief for this interactive session.
+
+$task"
 
 # a crashed run may have left a stale result for this name
 rm -f "$result"

package/runtime/spawn-tmux.sh

@@ -19,20 +19,27 @@ parent="$(tmux display-message -p -t "$TMUX_PANE" '#{session_name}:#{window_name
 # live workers
 result="/tmp/${name}-result.md"
 
-prompt="$task
+prompt="You are a worker session, spawned from a parent agent session, but you are not an
+autonomous batch job: this is a normal interactive session the user actively watches
+and can freely interact with. Don't drop the collaboration instructions from your system
+prompt and skills - keep following them; if a system prompt or a skill tells you to stop
+and ask the user - stop and ask. Check whether some of your skills apply to the task
+below and load them before starting.
 
-# Rules
+When done, write the full result to:
 
-Check whether you have some skills applicable to this task, and load
-them before starting working. This is a normal interactive session:
-the user can interact with you here, so ask anything blocking directly
-in this chat - don't defer unresolved decisions into the result file.
-When done, write the full result to
-$result, tell the user it is ready for review and wait for further
-instructions. Only after the user explicitly approves, notify the
-parent with a one-line pointer (never result content):
+    $result
 
-    tmux send-keys -t '$parent' 'Result ready: $result' Enter"
+Then tell the user it is ready for review and wait for further instructions. Only after
+the user explicitly approves, notify the parent with a one-line pointer (never result
+content):
+
+    tmux send-keys -t '$parent' 'Result ready: $result' Enter
+
+IMPORTANT! Even if the task below reads like a spec handed to an autonomous worker - it
+is not; it is a user's brief for this interactive session.
+
+$task"
 
 # make the prompt safe for the sh -c string tmux runs in the new window
 # (must stay unquoted: inside double quotes bash mangles the \' escaping)

package/skills/research/SKILL.md

@@ -17,12 +17,12 @@ Workflow:
    - verified: move it over; queue the new claims it suggests;
    - refuted: its opposite is verified; queue what that opens up;
    - not directly checkable: swap it for intermediate claims that would settle it.
-3. Verify by tracing the real thing end to end; a plausible story is not verification. "No such thing" counts only when you looked everywhere it could be - and when the answer hangs on a "no", check it again from another angle. When a probe would settle a claim more cheaply or more reliably than reading - a throwaway script, a query, a client call - probe; keep probes in a scratch directory, never the repo.
+3. Verify by tracing the real thing end to end; a plausible story is not verification. "No such thing" counts only when you looked everywhere it could be - and when the answer hangs on a "no", check it again from another angle. When a probe would settle a claim more cheaply or more reliably than reading - a throwaway script, a query, a client call - probe; keep probes in a scratch directory, never the repo. Settle each claim with the cheapest sufficient evidence and move on; stop mining a lead once it has answered the question asked of it.
 4. Report once every part of the question is answered by verified claims.
-5. Interrupt for user input when:
+5. Never continue past these without asking the user:
    - a new verification contradicts a verified claim: lay both out; resolving contradictions is their call, not yours;
    - a lead of yours is clearly better than the user's: propose the swap, but if they still press their lead, follow their lead, don't switch silently;
-   - the next best claim is expensive to verify - deep digging, data crunching, a big share of the context budget - and the user may know or point somewhere cheaper;
+   - you are about to go deeper - start checking another repo, do another set of probes - on top of significant context already spent; the user may rather settle for what's verified so far, or point to a shortcut;
    - the list is empty and the question is still open: ask what else to check.
 
 Report rules, whether it lands in chat or a file: