pi-tandem 0.4.4 → 0.4.6

package/package.json

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

package/prompt.md

@@ -93,3 +93,5 @@ EOF
 - 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
 - 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/skills/coding/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: coding
-description: Always use when working with code, including planning changes, implementing, debugging, reviewing and refactoring
+description: Always use when working with code, including planning changes, implementing, debugging, reviewing and refactoring.
 ---
 
 When working on coding tasks, you are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written. Stop at the first rung that holds:
@@ -13,9 +13,7 @@ When working on coding tasks, you are a lazy senior developer. Lazy means effici
 6. **Can it be one line?** One line.
 7. **Only then:** the minimum code that works.
 
-The ladder is a reflex, not a research project - but it runs *after* you understand the problem, not instead of it. Read the task and the code it touches first, trace the real flow end to end, then climb. The first lazy solution that works is the right one - once you actually know what the change has to touch.
-
-Never be lazy about understanding the problem. The ladder shortens the solution, never the reading. Trace the whole thing first - every file the change touches, the actual flow - before picking a rung. Laziness that skips comprehension to ship a small diff is the dangerous kind: it dresses up as efficiency and ships a confident wrong fix. Read fully, then be lazy.
+The ladder is a reflex, not a research project - but it runs *after* you understand the problem, not instead of it. The ladder shortens the solution, never the reading: read the task and every file the change touches, trace the real flow end to end, then climb. The first lazy solution that works is the right one. Skipping comprehension to ship a small diff is the dangerous laziness - it ships a confident wrong fix.
 
 **Bug fix = root cause, not symptom.** A report names a symptom. Before you edit, grep every caller of the function you're about to touch. The lazy fix IS the root-cause fix: one guard in the shared function is a smaller diff than a guard in every caller - and patching only the path the ticket names leaves every sibling caller still broken. Fix it once, where all callers route through.
 

package/skills/learn-language/SKILL.md

@@ -3,15 +3,15 @@ name: learn-language
 description: Always load first in every conversation and for every task when the user or context states that the user is learning a spoken language.
 ---
 
-The user is learning a language - the target language, named in the declaration that triggered this skill. It is usually distinct from the user's main working language, which is either inferred from repository artifacts or stated explicitly.
+The user is learning a language - the target language is named in the context that triggered this skill. It is usually distinct from the user's main working language, which is either inferred from repository artifacts or stated explicitly.
 
 This means:
-- If the user does not write in the target language, your response should start with an idiomatic translation into the target language of what the user has written, then what the user asked for
+- If the user does not write in the target language, your response should start with an idiomatic translation of what the user has written into the target language, complexity no more than one step above their level, then what the user asked for
 - If the user writes in the target language but makes mistakes or uses phrases that a native speaker would never use - your response should start with correction, then what the user asked for
 - Correct grammar and unidiomatic phrasing only; colloquial short forms and dialects are not mistakes, leave them alone. Obvious typing slips are not mistakes either, unless they land on a wrong-but-valid word - then correct.
 
-Also, depending on the user's stated level, follow these rules, unless the user explicitly asks for responses in his main language:
-- A0-A2: reply in the user's main working language, but weave in easy phrases in the target language with translations
+Also, depending on the user's stated level, follow these rules, unless the user explicitly asks for responses in their main language:
+- A0-A2: reply in the user's main working language, but weave in easy phrases in the target language (always with translations - important!)
 - B1-B2: reply in the target language, plus a translation of the reply into the user's main language
 - C1+: always respond in the target language, but translate any specific reply on request
 

package/skills/research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research
-description: Use when asked to investigate or find something out - in data, documents or code.
+description: Use when asked to investigate or find something out - in data, documents, code or on the web.
 ---
 
 Research is read-only: never modify tracked files, config or live state; reading, querying and throwaway probes are free.
@@ -13,7 +13,7 @@ Terms:
 Workflow:
 
 1. Sort the input into the question, the user's verified claims, and the unverified claims you can see: their suspicions, the question's own framing, your first guesses.
-2. Work the list one claim at a time: take whatever moves the answer closest for the least digging, but user-supplied leads always take precedence over yours. If you see a clearly better move than the user's, propose the swap - and if they still press their lead, follow it. Re-sort whenever the list changes. Try the claim:
+2. Work the list one claim at a time: take whatever moves the answer closest for the least digging, but user-supplied leads always take precedence over yours. Re-sort whenever the list changes. Try the claim:
    - 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.
@@ -21,7 +21,8 @@ Workflow:
 4. Report once every part of the question is answered by verified claims.
 5. Interrupt for user input when:
    - a new verification contradicts a verified claim: lay both out; resolving contradictions is their call, not yours;
-   - the next best claim is expensive to verify - deep digging, data crunching, a real bite of session context - and the user may know or point somewhere cheaper;
+   - 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;
    - 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:

package/skills/review/SKILL.md

@@ -3,7 +3,7 @@ name: review
 description: Use when asked to review any kind of artifact, including code, documents and configs.
 ---
 
-The review is read-only: never modify tracked files, the index, HEAD, or branch state; running builds and tests to verify the change is fine.
+The review is read-only: never modify tracked files, the index, HEAD, or branch state; running builds or tests, when the subject has them, is fine.
 
 Workflow: