soft-skills 2.1.12 → 2.1.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "soft-skills",
-  "version": "2.1.12",
+  "version": "2.1.14",
   "description": "Communication toolkit for burnt-out humans and collaborative AI's",
   "author": "Gilad Barnea (https://github.com/giladbarnea)",
   "homepage": "https://github.com/giladbarnea/soft-skills",

package/plugins/soft-skills/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "soft-skills",
-  "version": "2.1.12",
+  "version": "2.1.14",
   "description": "Communication toolkit for burnt-out humans and collaborative AI's",
   "author": {
     "name": "Gilad Barnea",

package/plugins/soft-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "soft-skills",
-  "version": "2.1.12",
+  "version": "2.1.14",
   "description": "Communication toolkit for burnt-out humans and collaborative AI's",
   "author": {
     "name": "Gilad Barnea",

package/plugins/soft-skills/skills/ai-to-delegated/briefing/examples.md

@@ -43,6 +43,22 @@ These illustrate [brief the bottom line, not the how](../coordination/delegates.
       </positive-example-3>
     </example-3>
 
+    <example-4>
+      Example 4 settings: the user and the main agent designed an experiment to test whether a Pi session converted to Claude Code keeps Claude’s signed thinking blocks. Two independent prerequisites stand in the way: a logging proxy that proves a beta header reaches the API, and a Pi-to-Claude session converter.
+      <negative-example-4 why-bad="main agent does both prerequisites itself, one after the other; its own context window fills with proxy logs and converter debugging before the real experiment even starts">
+      User to main agent: "Ok, let’s do the experiment."
+      Main agent builds and debugs the proxy, then writes and tests the converter, then starts the experiment with a crowded context window.
+      </negative-example-4>
+      <positive-example-4 why-good="main agent recognizes two independent, hands-on prerequisites standing between the session and its real goal, suggests forking itself once per prerequisite, and briefs each fork with only its assignment and the proof it must bring back">
+      User to main agent: "Ok, let’s do the experiment."
+      Main agent responds to user: "Two things must exist first: the proxy and the converter. They don’t depend on each other. Should I fork myself into two and build them in parallel?"
+      User to main agent: "Yes."
+      Main agent forks itself twice and prompts the forks: "[to one fork] You are the fork for task 1: prove the beta header and set up the proxy. [to the other fork] You are the fork for task 2: write the Pi-to-Claude converter. [to both] Bring back proof that it works on a real run, or the specific blocker."
+      [The forks build and prove the prerequisites; the main agent’s window stays reserved for the experiment.]
+      Main agent responds to user: "Both prerequisites are ready and proven. Let’s run the experiment."
+      </positive-example-4>
+    </example-4>
+
 ## Choosing an Implementer–Reviewer Team
 
 <team-example>

package/plugins/soft-skills/skills/ai-to-delegated/configurations/hillclimber-watcher/protocol.md

@@ -6,6 +6,7 @@ description: Pairs an iterative optimizer with a watcher that prevents tunnel vi
 
 # Hillclimber–Watcher Team Pattern
 
+If you haven’t yet:
 Before creating this team, read [delegate coordination](../../coordination/delegates.md).
 When briefing participants without shared context, read [fresh-context briefing](../../briefing/fresh-context.md).
 Participants: read [peer coordination](../../coordination/peers.md). The watcher also reads [watcher.md](watcher.md).
@@ -16,7 +17,7 @@ Use this pattern when the task has a measurable target, a search space, and a re
 
 Create a two-teammate team:
 
-1. **Hillclimber** — owns the work. It experiments, implements, measures, and iterates toward the target.
+1. **Hillclimber** — owns the work. It experiments, implements, measures, and iterates toward the target. Owns completion.
 2. **Watcher** — stays mostly idle. It periodically checks whether the hillclimber is making real progress or falling into loops, rabbit holes, overfitting, whack-a-mole’s, or low-leverage work.
 
 The watcher should not become a second implementer. Its value is judgment under low cognitive load.
@@ -28,17 +29,18 @@ Use this when:
 - There is an explicit metric or acceptance target.
 - The solution may require trial and error.
 - The main risk is local optimization, whack-a-mole patches, or tunnel vision.
-- A fresh thinker can improve the search without duplicating the heavy work.
+- A somewhat-detached observer can improve the execution without duplicating the heavy work.
 
 Do not use this for straightforward implementation, simple research, or work where a normal adversarial reviewer is enough.
 
 ## Context floor
 
-This section applies to the dispatcher.
+> This section applies to the dispatcher.
+> The instructions in this sections should be read idempotently; if the prepared context and/or prompt are already available, do not write new ones. Prefer referencing existing resources. Remember that “included in its context window” also counts as “already available”. This is relevant when session forks are involved; for example, if you have a good grasp of what needs to be done, a fork of yours, by definition, also does. A non-fork does need an explicit context floor.
 
-Before spawning the team, write a short context file and tell both teammates to read it first.
+Before spawning the team, write a short context file and tell both teammates to read it first. Put it in a subdirectory of an existing desk directory, or create a new desk directory if none exists.
 
-The context file should include:
+The floor context should include:
 
 1. The actual goal and metric.
 2. The current baseline, if any.
@@ -55,18 +57,15 @@ The dispatcher supplies the goal and context file. Both participants follow the
 When sending this template, resolve its relative file paths from this file's directory.
 
 ```text
-Load the project context skill with the same arguments I used, then load `ai-to-leader` and the peer conduct in `../../coordination/peers.md`.
+{{ context-loading instructions, references, and this Skill }}
 
-Read this context file first:
-@/path/to/curated-teammates-context-brief.md
+You are a hillclimber–watcher team. The shared goal is: <goal and measurable target of the team as a whole>.
 
-You are a hillclimber–watcher team. The shared goal is: <goal and measurable target>.
-
-Hillclimber: own the implementation and optimization loop. Try approaches, measure them, keep the work reproducible, and iterate toward the target. Prefer simple, principled changes over piles of special-case patches. Ping Watcher when you have meaningful progress, and answer Watcher's check-ins.
+Hillclimber: own the {{ task nature: either 'implementation', or 'optimization loop' for ML-shaped tasks, etc. }}. Try approaches, measure them, keep the work reproducible, and iterate toward the target. Prefer simple, principled changes over piles of special-case patches. Ping Watcher when you have meaningful progress, and answer Watcher's check-ins.
 
 Watcher: read the adjacent `watcher.md` for your observation procedure. Do not take over the implementation.
 
-Both: set short, current statuses frequently. Keep summaries concise. Continue until you either reach the target or have been plateuing for more than an hour straight without progress (yes, look at the clock from time to time.).
+Both: set short, current statuses frequently. Keep summaries concise. Continue until you either reach the target or have been plateuing for more than an hour straight without progress (look at the clock from time to time if you have no feeling of passage of time.).
 
 Communicate directly with each other and converge without main-agent micromanagement.
 ```

package/plugins/soft-skills/skills/ai-to-delegated/configurations/hillclimber-watcher/watcher.md

@@ -7,14 +7,14 @@ description: Observe the hillclimber's progress and offer occasional independent
 
 Read this only when you are the watcher. First read the [shared protocol](protocol.md) if it is not already in context.
 
-You are the outside-box watcher. Stay mostly low-activity. Check status every two minutes (Bash `sleep`). Every ten minutes, ask the hillclimber what it has been doing, what progress it has made, and whether it is facing hurdles, rabbit holes, or whack-a-mole loops. Read new or changed files when useful. Then think: If you conclude the hillclimber is tunnel-visioned, overfitting, going in circles, missing an important flaw, or ignoring a better path, send it a concrete suggestion and return to the two-minute sleep/check rhythm. If it looks like hillclimber is doing fine, do not say anything. Send main the gist of major breakthroughs/steps (only once every few rounds.) Do not take over the implementation.
+You are the outside-box watcher. Stay mostly low-activity. Check status every give minutes or so (set yourself an async, non-blocking reminder). Every ~ten minutes, ask the hillclimber what it has been doing, what progress it has made, and whether it is facing hurdles, rabbit holes, or whack-a-mole loops. Read new or changed files when useful. Then think: If you conclude the hillclimber is tunnel-visioned, overfitting, going in circles, missing an important flaw, unjustifiably ballooning the scope, or ignoring a better path, send it a concrete suggestion and return to the five-minute idle/check rhythm. If it looks like hillclimber is doing fine, do not say anything. Send main the gist of major breakthroughs/steps (only once every few rounds.) Do not take over the implementation.
 
 ## Watcher cadence
 
 The watcher loop is deliberately boring:
 
 1. Set status.
-2. Sleep for two minutes.
+2. Sleep for give minutes.
 3. Lightly inspect team status and visible progress.
 4. Every ten minutes, ask the hillclimber for a short progress report.
 5. Think independently about whether the current path is still good.