soft-skills 2.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Gilad Barnea
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,166 @@
+# `soft-skills`
+
+![Late-shift desk with a terminal showing trusted AI delegation](assets/interaction-banner.png)
+
+> **Communication toolkit for burnt-out humans and AI collaborations.**
+
+[![Release](https://img.shields.io/github/v/release/giladbarnea/soft-skills?style=flat-square&color=111111&label=release)](https://github.com/giladbarnea/soft-skills/releases/latest)
+![Works with Claude Code, Codex, and Pi](https://img.shields.io/badge/works%20with-Claude%20Code%20%7C%20Codex%20%7C%20Pi-111111?style=flat-square)
+[![MIT license](https://img.shields.io/badge/license-MIT-111111?style=flat-square)](LICENSE)
+
+**AI agents are good at code and bad at communication.**
+**`soft-skills` solves that.**
+
+## This probably sounds familiar
+
+**Your agent reports to you (a bit like a toddler):**
+
+- **A wall of text,** written from inside its own head.
+- **Terminology** it invented an hour ago.
+- **Out-of-context reasoning** that makes no sense.
+- **Implementation details** you do not care about.
+- **Decisions** it should have made on its own, surfaced to you.
+
+**Your agents do a bad job working together:**
+
+- **The main agent micromanages** the subagent, weakens it, and destroys any added value.
+- **It replays** the subagent's work, "just to make sure."
+
+## Before and after: AI work report to human
+
+**Before**
+
+> Wired `TokenBucketV2` behind `RL_STRICT` through the middleware shim. Fixed the flaky `test_burst_window` (clock skew in the fixture). Also refactored `limits.py` while I was there and bumped redis-py. Sliding-window edge cases still TBD but should be fine. Want me to also…
+
+**After**
+
+> Rate limiting is live on the public API: 100 requests per minute per client.
+>
+> **One decision for you:** should paying customers get a higher limit? I recommend 1,000.
+
+## Before and after: AI to AI
+
+The main agent needs an explorer subagent to find where rate limiting happens in the codebase.
+
+**Before**
+
+> Find where rate limiting is implemented. You MUST search ONLY these EXACT locations: `server/middleware.py`, `server/limits.py`, `config/redis.yaml`. Do NOT look anywhere else.
+
+*If it knew where to look, it would not need the subagent.*
+
+**After**
+
+> I am about to change how the public API limits clients. Find where rate limiting happens and everything it touches.
+
+## The idea
+
+**`soft-skills` is built on [theory of mind](https://en.wikipedia.org/wiki/Theory_of_mind):**
+
+> In psychology and philosophy, theory of mind (often abbreviated to ToM) is the capacity to understand other individuals by ascribing mental states to them. A theory of mind includes the understanding that others' beliefs, desires, intentions, emotions, and thoughts may be different from one's own. Possessing a functional theory of mind is crucial for success in everyday human social interactions. People use a theory of mind when analyzing, judging, and inferring other people's behaviors.
+
+AI agents force you to build a bridge between their understanding and yours. **`soft-skills` solves this by making them do this for you.**
+
+## What it teaches
+
+### Agent → human
+
+- **Outcome first.** Every report re-grounds you from the last decision you made together.
+- **One name per thing.** No private jargon.
+- **Knowing signal from noise.** Only what changes your next decision. The rest gets handled.
+- **Questions with context.** What changed, the options ruled out, a recommendation.
+- **Plain English.** Short sentences for a tired brain juggling a dozen sessions.
+
+`soft-skills` applies principles from cognitive psychology, content and information design, and proven protocols like ASD-STE100.
+
+### Agent → agent
+
+- **Down, to delegates.** Brief the *why* and how it fits in the larger context. Describe the outcome you need, not how to get there. Then trust them, and let them do what they are good at.
+- **Up, to the leader.** Escalate only what needs judgment. Know which decisions to make now and report later, and which are worth pausing to surface.
+- **Sideways, to peers.** Share findings. Never instruct.
+
+**Plus, guides to the tradeoffs:**
+
+- When to delegate at all.
+- Subagents vs. teams.
+- When and when not to fork the session's context window.
+- Agents that lead agents.
+- Multi-hour runs with nobody watching.
+- Fast models vs. slow and smart models.
+- Managing the context of delegates and of itself, to keep the ship afloat.
+
+## What you get
+
+- **You make the big decisions.** Your brain stops hurting when you read AI responses.
+- **Better agent performance in longer, sharper sessions.** The upgraded context management does the work.
+- **Agents do not get stuck in rabbit holes.** They raise a flag at the right time.
+- **A team that does real work.** No babysitting needed. Agents that feel like colleagues you loved working with.
+
+## The skills
+
+| Skill | Job |
+| --- | --- |
+| `theory-of-mind` | The foundation: write for a reader who was not there. |
+| `ai-to-leader` | Reports and questions to whoever assigned the work. |
+| `ai-to-delegated` | Delegation, briefing, supervision, and teamwork. |
+| `handoff` | Pass the work to a fresh agent with decisions and reasons intact. |
+| `peer-review` | Fresh-eyes review: proven issues and complexity to remove. |
+
+**Agents load these on their own when the situation fits.**
+
+## `soft-skills` is NOT for you if:
+
+- You easily understand everything your agent tells you.
+- You don't know what "Claudish" is.
+- You never have "bro what the f*** are you saying right now" moments.
+- You never forget what you did in that other AI session.
+- You run at most one session at a time.
+
+## Install
+
+**Claude Code**
+
+```text
+/plugin marketplace add giladbarnea/soft-skills
+/plugin install soft-skills@soft-skills
+```
+
+**Codex**
+
+```bash
+codex plugin marketplace add giladbarnea/soft-skills
+codex plugin add soft-skills@soft-skills
+```
+
+**Pi**
+
+```bash
+pi install npm:soft-skills
+```
+
+Then start a new Pi session.
+
+## Only Markdown
+
+No MCP server, no code, no network calls, no hooks, no background process. Your laptop can remain disappointed by the missing daemon.
+
+<details>
+<summary><b>Releasing</b> (maintainers)</summary>
+
+Pushing a `vMAJOR.MINOR.PATCH` tag starts the [release workflow](.github/workflows/release.yml).
+
+1. Set the same version in `package.json`, `plugins/soft-skills/.claude-plugin/plugin.json`, and `plugins/soft-skills/.codex-plugin/plugin.json`.
+2. Commit and push.
+3. Create and push the matching tag:
+
+   ```bash
+   git tag -a v1.1.0 -m "Soft Skills v1.1.0"
+   git push origin v1.1.0
+   ```
+
+CI checks that the three versions match the tag, publishes to npm with [trusted publishing](https://docs.npmjs.com/trusted-publishers), and creates the GitHub release. Branch pushes alone do not publish.
+
+</details>
+
+## License
+
+[MIT](LICENSE).

package/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "soft-skills",
+  "version": "2.1.0",
+  "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",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/giladbarnea/soft-skills.git"
+  },
+  "license": "MIT",
+  "keywords": [
+    "pi-package",
+    "communication",
+    "delegation",
+    "handoff",
+    "peer-review",
+    "agents"
+  ],
+  "files": [
+    "plugins/soft-skills"
+  ],
+  "pi": {
+    "skills": [
+      "./plugins/soft-skills/skills"
+    ]
+  }
+}

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

@@ -0,0 +1,19 @@
+{
+  "name": "soft-skills",
+  "version": "2.1.0",
+  "description": "Communication toolkit for burnt-out humans and collaborative AI's",
+  "author": {
+    "name": "Gilad Barnea",
+    "url": "https://github.com/giladbarnea"
+  },
+  "homepage": "https://github.com/giladbarnea/soft-skills",
+  "repository": "https://github.com/giladbarnea/soft-skills",
+  "license": "MIT",
+  "keywords": [
+    "communication",
+    "delegation",
+    "handoff",
+    "peer-review",
+    "agents"
+  ]
+}

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

@@ -0,0 +1,27 @@
+{
+  "name": "soft-skills",
+  "version": "2.1.0",
+  "description": "Communication toolkit for burnt-out humans and collaborative AI's",
+  "author": {
+    "name": "Gilad Barnea",
+    "url": "https://github.com/giladbarnea"
+  },
+  "homepage": "https://github.com/giladbarnea/soft-skills",
+  "repository": "https://github.com/giladbarnea/soft-skills",
+  "license": "MIT",
+  "keywords": [
+    "communication",
+    "delegation",
+    "handoff",
+    "peer-review",
+    "agents"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Soft Skills",
+    "shortDescription": "Communication toolkit for burnt-out humans and collaborative AI's",
+    "longDescription": "Communication toolkit for burnt-out humans and collaborative AI's",
+    "developerName": "Gilad Barnea",
+    "category": "Productivity"
+  }
+}

package/plugins/soft-skills/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Gilad Barnea
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/plugins/soft-skills/roles.md

@@ -0,0 +1,35 @@
+---
+name: roles
+description: Map an agent's relationships to the interaction guidance that applies.
+---
+
+# Roles: Who Are You in the Structure?
+
+Instructions attach to edges, not to agents. An agent has no role; its edges do.
+
+Definitions:
+
+- **Your leader**: whoever gave you your mission and receives your results. Every agent has exactly one — the human, or the agent that dispatched you.
+- **Your delegates**: AI’s you dispatched. Zero or more.
+- **Your peers**: teammates working alongside you under the same leader. Zero or more.
+
+Hierarchy depth never matters. Every agent’s neighborhood looks the same: one edge up, optional edges down and sideways. Classify by your adjacent edges only.
+
+## The classifier
+
+Read every matching route, once while its contents remain in context. Reconsider the routes when your relationships change.
+
+| question | if yes, load |
+| --- | --- |
+| — (always) | [`theory-of-mind`](skills/theory-of-mind/SKILL.md) + [`ai-to-leader`](skills/ai-to-leader/SKILL.md) |
+| Is your leader a human? | [`ai-to-leader/references/human.md`](skills/ai-to-leader/references/human.md) |
+| Do you dispatch or supervise delegates? | [Delegate coordination](skills/ai-to-delegated/coordination/delegates.md) |
+| Do your delegates lead their own agents? | Also [leading leaders](skills/ai-to-delegated/coordination/leading-leaders.md) |
+| Do you have teammates? | [Peer coordination](skills/ai-to-delegated/coordination/peers.md) |
+
+Notes:
+
+- “Both” is not a special state. A mid-chain agent holds an upward edge and downward edges. It loads both skills and applies each to its own edge. The two spaces never conflict, because they govern different edges.
+- Narrow, in-and-out delegation still flips the dispatch bit. Whatever you delegated is not yours until it returns, regardless of how much of the work stays in your hands.
+
+For delegation planning, briefing, or named configurations, use the matching routes in [ai-to-delegated](skills/ai-to-delegated/SKILL.md).

package/plugins/soft-skills/skills/ai-to-delegated/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: ai-to-delegated
+description: Best practices for getting a step-function leap in performance from other AI agents when instructing or communicating with them. Load `ai-to-delegated` before spawning a sub-agent, creating a team or talking to a teammate agent. Trigger words include “dispatch an agent”, “spawn a team”, and “talk with another ai”.
+---
+
+# AI → Delegated
+
+Read all routes that match your current situation. Follow further links only when their stated condition applies.
+Read each file once while its contents remain in context. Reconsider the routes when your situation changes.
+For relationship definitions, see the plugin's [roles map](../../roles.md).
+
+| Current situation | Read |
+| --- | --- |
+| Deciding whether delegation is worthwhile | [When to delegate](planning/when-to-delegate.md) |
+| Choosing or changing a delegation shape and agents' configuration | [Choose a configuration](planning/choose-configuration.md) |
+| About to dispatch, or currently supervising delegates | [Delegate coordination](coordination/delegates.md) |
+| The session appears to span multiple hours or more | Also [Many-hours supervision](coordination/many-hours-supervision.md) |
+| Requesting work from an agent without shared context | [Fresh-context briefing](briefing/fresh-context.md) |
+| (Don't) brief an agent with inherited context window | [Forked-context briefing](briefing/forked-context.md) |
+| Examples of briefing delegates | [Briefing examples](briefing/examples.md) |
+| Working alongside peers | [Peer coordination](coordination/peers.md) |
+| About to commission, or currently supervising leaders | Also [leading leaders](coordination/leading-leaders.md) |
+
+## Named configurations
+
+If a configuration is already chosen, read its file directly. Each file routes the dispatcher and participants to the guidance they need.
+
+- [Research fanout](configurations/research-fanout.md): independent research followed by synthesis.
+- [Colloquium](configurations/colloquium.md): adjacent research efforts with live peer exchange.
+- [Pair programming](configurations/pair-programming.md): agree on a plan, implement, and review once.
+- [Hillclimber–watcher](configurations/hillclimber-watcher/protocol.md): optimize toward a measurable target with outside judgment.
+
+These configurations are examples to generalize from. They are incomplete and evolving, not required structures.

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

@@ -0,0 +1,63 @@
+---
+name: briefing-examples
+description: Contrasting examples of preserving intent and context when requesting work from other agents.
+---
+
+# Briefing Examples
+
+These illustrate [fresh-context briefing](fresh-context.md). Read them when examples would help apply its principles.
+
+<example-1>
+      <negative-example-1 why-bad="main agent shoots its own foot by limiting the delegate research scope">
+      User to main agent: "Why does Vercel claim their integrated version is beneficial?"
+      Main agent spawns a sub-agent and prompts it: "Research why Vercel claim their integrated version is beneficial (edge runtime, seamless DX, zero-config, billing, monitoring, tight coupling to `vercel` CLI / dashboard / functions)."
+      </negative-example-1>
+      <positive-example-1 why-good="main agent declares the bottom line added value it needs without prescribing what   and how to do it">
+      User to main agent: "Why does Vercel claim their integrated version is beneficial?"
+      Main agent spawns a sub-agent and prompts it: "I want to know why Vercel claim their integrated version is   beneficial."
+      </positive-example-1>
+    </example-1>
+
+    <example-2>
+      Example 2 settings: the `load-context` skill instructs to read CLAUDE.md, ARCHITECTURE.md, docs/webserver/API.  md, docs/data/architecture.md, server/api.py, and server/db.py.    
+      <negative-example-2 why-bad="main agent fails to leverage the harness and instead prescribes what to do;   moreover it makes the same scope-narrowing mistake as in example-1">
+      User to main agent: "/skill:load-context domain: acme, subdomain1: the public REST API, subdomain2: the data   layer. I want to plan a view layer with you later, so let’s understand the foundations."
+      Main agent spawns a sub-agent and prompts it: "Read CLAUDE.md, ARCHITECTURE.md, docs/webserver/API.md, docs/data/  architecture.md, server/api.py, server/db.py, and summarize how the REST API and data layers work. Cover how   function `server/api.py:from_db` fetches the data by calling the `server/db.py:get_data` function, and how [...  proceeds to prescribe ironically specific locations to “discover”]"
+      </negative-example-2>
+      <positive-example-2 why-good="main agent recognizes the work can be distributed concurrently, shortly shares the   wider context (the “why”), forwards the user’s context levers — keeping the shared domain and handing each agent   one of the two subdomains rather than dropping them — and does not micro-manage the agents with how-exactly   instructions">
+      User to main agent: "/skill:load-context domain: acme, subdomain1: the public REST API, subdomain2: the data   layer. I want to plan a view layer with you later, so let’s understand the foundations."
+      Main agent fans out research scope horizontally to two parallel sub-agents and prompts them: "The user and I are   planning a new view layer, so we need a thorough understanding of the foundations. [to one agent] /  skill:load-context domain: acme, subdomain: the public REST API [to the other agent] /skill:load-context domain:   acme, subdomain: the data layer. [to both] Study your subdomain deeply and exhaustively."
+      [Main agent receives the two independent sub-agents’ responses, thinks hard to synthesize them]
+      Main agent responds to user: "I have deep understanding of both layers and their relationships. What did you   have in mind?"
+      </positive-example-2>
+    </example-2>
+
+    <example-3>
+      <negative-example-3 why-bad="main agent prescribes how to review its work, repeats the peer-review skill’s contents. moreover, agent puts words in the user’s mouth, who did not emphasize any specific aspects.">
+      User to main agent: "Spawn a sub-agent to review your work."
+      Main agent spawns a sub-agent and prompts it: "Load the load-project-context and peer-review skills. The user   asked me to <user request>. I’ve made an attempt to complete the task. Review my work (the current main dirty   tree). do you spot any blindspots, bugs, or opportunities to achieve the same results with a simpler, collapsed   approach? if you find any, please suggest a specific alternative implementation that is simpler and achieves the same results."
+      </negative-example-3>
+      <positive-example-3 why-good="main agent writes as simple a prompt as possible. adds only what is necessary to get the reviewer up to speed. does not put words in the user’s mouth. does propagate the user’s explicit emphasis">
+      User to main agent: "Spawn a sub-agent to review your work. I’m mostly interested in blindspots in the implementation, bugs, and opportunities to get the same results with a simpler, collapsed approach."
+      Main agent spawns a sub-agent and prompts it: "Load the load-project-context and peer-review skills. The user  asked me to <user request>. I’ve made an attempt to complete the task. Review my work (the current main dirty tree). Do you spot any blindspots, bugs, or opportunities to achieve the same results with a simpler, collapsed   approach?"
+      </positive-example-3>
+    </example-3>
+
+## Choosing an Implementer–Reviewer Team
+
+<team-example>
+      Team Example settings: at the session’s start the user ran `/skill:load-context domain: acme, subdomain1: the public REST API, subdomain2: the   data layer`; the main session explored the code, and the user approved a plan to add rate limiting to the public REST API.
+      <negative-team-example why-bad="main agent burns its own context shuttling the diff and the feedback back and forth — dives into the sub-agent’s   work and clogs its own context window worse than doing the task solo would have, acts as a reviewer when biased">
+      User to main agent: "Great, go ahead and build it."
+      Main agent spawns one sub-agent to implement; when it returns the diff, studies and reviews it; relays the review the sub-agent; and keeps ferrying   revisions until the diff settles.
+      </negative-team-example>
+      <positive-team-example why-good="main agent picks a team because the adversarial iteration is synergistic, replicates the user’s context levers   verbatim — including the domain and the subdomains the user specified when loading the context skill — has the reviewer also load `peer-review`,   declares only the bottom line it wants, and stays out of the loop while they converge">
+      User to main agent: "Great, go ahead and implement the plan."
+      Main agent spawns an implementer–reviewer team and prompts them: "/skill:load-context domain: acme, subdomain1: the public REST API, subdomain2: the data layer, then load `ai-to-leader` and the peer conduct in `../coordination/peers.md`. You are an implementer–reviewer team. Here is the user’s original message to me, verbatim, for the bigger picture: {the-user-message-describing-the-task}.
+      [to the implementer] Implement the plan, and ping your teammate when you think you’re done.
+      [to the reviewer] Also load `peer-review`, and review your teammate’s work when it pings you.
+      [to both] The user and I finalized a plan to add rate limiting to the public REST API — here it is: {the plan}. Build it and tear it apart between yourselves until you’re confident it’s the simplest working, correct solution faithful to the plan."
+      [The team implements and reviews live, converging without the main agent in the loop; the main agent receives the finished, reviewed result.]
+      Main agent responds to user: "Done — implemented and adversarially reviewed between the two of them. Here’s what landed: …"
+      </positive-team-example>
+    </team-example>

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

@@ -0,0 +1,9 @@
+---
+name: forked-context
+description: Assign work to an agent that mechanically inherits your context window.
+---
+
+# Brief an Agent With Inherited Context
+
+The agent starts with a clone of your session context, so a separate context brief repeats what it already knows.
+When you create an agent as a fork of your session, give it the assignment without repeating the context it inherits: “You are the fork; do X.”

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

@@ -0,0 +1,22 @@
+---
+name: fresh-context
+description: Request work from an agent without shared context, preserving intent without prescribing the answer.
+---
+
+# Brief an Agent Without Shared Context
+
+Read this when the recipient lacks the context needed for your request.
+Read [forked-context.md](forked-context.md) if you have not already for guidance on agents that inherit your session context.
+
+This section is a communication rulebook to all cases where an AI requests something from another AI: down, sideways and up — main to sub-agent, main to team, teammate to teammate, and delegated to delegator.
+
+Load the [theory-of-mind skill](../../theory-of-mind/SKILL.md) once if you haven’t already. It provides the framework behind this section.
+
+**1. Orient the agent to the project:**
+    1.a. Tell the AI agent to *load the skills and files your leader has referenced* throughout the session. That’s the baseline common ground. Do not repeat the content of those skills and files in your instructions. This why references exist.
+    1.b. Reference any additional files that have been created, read or edited throughout the session.
+
+**2. Generously give the AI wider context:**
+    Understanding *why* it’s performing the task will boost its performance. Don’t micromanage or over-instruct it. The agent already has the same system prompt as you do out of the box, and step #1 will fill in most that is needed. Your delegate highly and equally intelligent as you are, and can navigate uncertainties well without spoon-feeding. Think: What kind of input do YOU thrive on? The answer is wide contextual understanding (is) and explicitly stated desired end state, also known as the intent (should); A and Z, 0 and 1. Avoid prescribing instructions, giving “how-to” examples, providing examples as to what to think about, or dictating which files, symbols, or paths to look at; avoid any form of providing hints for possible answers for your own queries — this is a serious footgun and a form of leakage that outright makes the delegate a waste of time, money and intelligence. Just *_declare_ what is the _bottom line_ _added value_ YOU are seeking for yourself*. Do not specify which steps to take; instead, share with the agent only why it was dispatched and what you hope to gain (dictating the “how” is bad). This directly frees the agent to find the best way to reach *your* goal, unbiased and unconstrained by your own assumptions. Essentially, all these “Don’ts” are forms of overfitting.
+
+Read [examples.md](examples.md) if you have not already for examples that clarify these principles.

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

@@ -0,0 +1,28 @@
+---
+name: colloquium
+shape: Team
+description: Uses live peer exchange so adjacent research findings cross-pollinate each teammate's work.
+---
+
+# Colloquium Team
+
+Before dispatching, 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) before working together.
+
+Individually, each teammate is responsible for an orthogonal, parallel, read-only, think-heavy effort. The teammates would benefit from listening to the other teammates as they share their thoughts and findings in real time, exactly because each of them is doing its own thing. Sharing is fruitful for the same reason it’s fruitful for scientists to attend and listen to peers in scientific conferences: a peer’s finding from an adjacent problem updates your map of the shared terrain and reframes your own problem in ways you could not have generated from inside your own lane, at no cost to your own effort. Think of it as an open studio: everyone works on their own piece while absorbing the others’.
+
+## Shape & Work flow
+
+N flat teammates working in parallel.
+
+## Abstract required conditions for this shape to fit needs
+
+- Teammates’ bottom-line deliverable is figuring out *how* to do something; 
+- Teammates’ scopes overlap semantically at least a bit.
+
+Examples (not an exhaustive list — derive the underlying principles and generalize regardless of domain):
+- Team is given an under-designed existing web page. Teammate A responsible for coming up with a better design language and vision; Teammate B is responsible for pointing out the page’s mobile usability issues and suggesting concrete improvements. A creates a better-informed design vision knowing B’s findings and suggestions; B suggests better-aligned suggestions knowing the larger design language’s direction. A top-down/bottom-up pincer move. Team output is not a funneled merge of individual results; it’s a flat union of the N individual results. The team’s dynamic ensures the results are cohesive and well-aligned (synergy).
+
+## When not to use
+
+When deliverable involves writing or editing.

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

@@ -0,0 +1,72 @@
+---
+name: hillclimber-watcher-team
+shape: Team
+description: Pairs an iterative optimizer with a watcher that prevents tunnel vision.
+---
+
+# Hillclimber–Watcher Team Pattern
+
+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).
+
+Use this pattern when the task has a measurable target, a search space, and a real risk that a busy agent will tunnel-vision while iterating. The point is not ordinary implementer/reviewer pairing. The point is **autonomous optimization with periodic outside-the-loop steering**.
+
+## Shape
+
+Create a two-teammate team:
+
+1. **Hillclimber** — owns the work. It experiments, implements, measures, and iterates toward the target.
+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.
+
+## When to use
+
+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.
+
+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.
+
+Before spawning the team, write a short context file and tell both teammates to read it first.
+
+The context file should include:
+
+1. The actual goal and metric.
+2. The current baseline, if any. 
+3. The constraints that prevent cheap wins.
+4. The relevant files, referenced by path rather than copied wholesale.
+5. The validation command or measurement harness.
+6. What the final handoff must contain.
+
+Keep it a mission brief, not a transcript. Strip stale interpretations, tool receipts, old chatter, and irrelevant files.
+
+## Team prompt template
+
+The dispatcher supplies the goal and context file. Both participants follow the agreement below.
+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`.
+
+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>.
+
+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.
+
+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.). 
+
+Communicate directly with each other and converge without main-agent micromanagement.
+```

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

@@ -0,0 +1,25 @@
+---
+name: watcher
+description: Observe the hillclimber's progress and offer occasional independent judgment without taking over the work.
+---
+
+# Watcher
+
+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.
+
+## Watcher cadence
+
+The watcher loop is deliberately boring:
+
+1. Set status.
+2. Sleep for two 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.
+6. If useful, read changed files or metrics.
+7. Send steering only when it materially improves the search.
+8. Repeat.
+
+The watcher should bias toward silence. A noisy watcher becomes drag.