soft-skills 2.1.18 → 2.1.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "soft-skills",
-  "version": "2.1.18",
+  "version": "2.1.20",
   "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.18",
+  "version": "2.1.20",
   "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.18",
+  "version": "2.1.20",
   "description": "Communication toolkit for burnt-out humans and collaborative AI's",
   "author": {
     "name": "Gilad Barnea",

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

@@ -16,6 +16,7 @@ For relationship definitions, see the plugin's [roles map](../../roles.md).
 | The harness cannot set the model, thinking, or fork you chose | [Dispatch outside the harness](planning/dispatch-outside-the-harness.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) |
+| Balancing quotas or spend | [Budget balancing](coordination/budget-balancing.md) |
 | Requesting work from an agent without shared context | [Fresh-context briefing](briefing/fresh-context.md) |
 | Briefing an agent with inherited context window | [Forked-context briefing](briefing/forked-context.md) |
 | Examples of briefing delegates | [Briefing examples](briefing/examples.md) |

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

@@ -0,0 +1,7 @@
+After having tried to overcome a setback multiple times without a major breakthrough, spawn Claude Fable 5.1 on max, with fresh context. Tell it only in product and behavior terms:
+
+```text
+We are working on <planfile>. We are at step X. We have encountered the following unexpected challenges: … We expected behavior Y but seem to have some difficulty getting there. We might be carrying a blind spot or be too invested in the work to think of an effective solution. Take a look at what we have done so far. Can you think of an outside-the-box solution that we might have overlooked that bypasses the problem?
+```
+
+Then, after its response, use judgment. It might propose a good direction worth pursuing. It is not like you have a lot to lose, since at that hypothetical moment you have already been trying for a while without success.

package/plugins/soft-skills/skills/ai-to-delegated/coordination/budget-balancing.md

@@ -0,0 +1,20 @@
+---
+name: budget-balancing
+description: Agree on usage checks and limits, preserve work at a limit, and switch between pre-approved models.
+---
+
+# Budget Balancing
+
+## Agree on usage checks and limits
+
+Ask the human whether to monitor usage. If so, agree on which budgets to monitor, including subscriptions and API keys, and how to check each one. Ask which metrics to watch and what actions to take at each threshold. Suggest pausing and boomeranging yourself an amount of hours later to check if within resume range then.
+
+For subscriptions, calculate burn rate against remaining capacity w.r.t. time until the next reset. For API usage, track total spend, remaining budget, and spending rate over time.
+
+## Pause and preserve work
+
+If a provider is over budget, move work to a pre-approved equivalent model on another provider within budget. Preserve the role.
+
+At the agreed resource limit, pause delegates at the nearest safe checkpoint. Save work in a versioned handoff commit.
+
+For handoff guidance, read [the handoff skill](../../handoff/SKILL.md).

package/plugins/soft-skills/skills/ai-to-delegated/coordination/delegates.md

@@ -30,7 +30,7 @@ The chain processes at every rung: each agent surfaces to its leader only what n
 
 **Batch approvals.** When you expect several approvals to arrive close together, hold them and bring one grouped request. One decision session beats three interruptions. A lone question does not wait for company.
 
-**Suggest, then get approval.** If you intend to dispatch delegates of your own, you may propose a delegation shape, but your leader must approve it before you dispatch anyone.
+**Suggest, then get approval**, unless your leader has already approved this kind of delegation.
 
 ## Understand an Escalation Before Passing It Up
 

package/plugins/soft-skills/skills/ai-to-delegated/coordination/many-hours-supervision.md

@@ -9,11 +9,7 @@ Read this when the session appears to span multiple hours or more. You remain re
 
 Detect rabbit holes and stalls, and keep useful work moving within authorization. Activity alone does not prove progress.
 
-## Agree on usage checks and limits
-
-Ask the human whether to monitor usage. If so, agree on which budgets to monitor, including subscriptions and API keys, and how to check each one. Ask which metrics to watch and what actions to take at each threshold. Suggest pausing and boomeranging yourself an amount of hours later to check if within resume range then.
-
-For subscriptions, calculate burn rate against remaining capacity w.r.t. time until the next reset. For API usage, track total spend, remaining budget, and spending rate over time.
+For subscription quotas, API spend, and provider switching, read [Budget balancing](budget-balancing.md).
 
 ## Check progress and resources
 
@@ -22,8 +18,7 @@ For subscriptions, calculate burn rate against remaining capacity w.r.t. time un
 
 ## Pause and preserve work
 
-1. At the agreed resource limit, pause delegates at the nearest safe checkpoint. Save work in a versioned handoff commit.
-2. When delegates report a slow down, pause them and ask the human for direction. Schedule a 30m reminder to check for a reply. In absence of a reply, and if budget allows, proceed to seek independent advice.
+When delegates report a slow down, pause them and ask the human for direction. Schedule a 30m reminder to check for a reply. In absence of a reply, and if budget allows, proceed to seek independent advice.
 
 For handoff guidance, read [the handoff skill](../../handoff/SKILL.md).
 

package/plugins/soft-skills/skills/peer-review/references/peer-review-instructions.md

@@ -8,16 +8,15 @@ Think again whether you truly grok <research_targets>. Unless you have no missin
 
 Finally, review <work_to_review>.
 
-Review for major overlooks/blindspots and critically incomplete understanding of the source or requirements; significant missed opportunities to leverage elegant design and avoid implementation slop; obviously unnecessary over-engineering that could be collapsed into something simpler yet cleaner; scope creep; mismatch, misuse or underuse of the project’s patterns; Regressions and contradictions; etc.
+Review for major overlooks/blindspots and critically incomplete understanding of the source or requirements; significant missed opportunities to leverage elegant design and avoid slop; obviously unnecessary over-engineering that could be collapsed into something simpler yet cleaner; scope creep; mismatch, misuse or underuse of the project’s pre-existing reality; regressions and contradictions; etc.
 
 Recall the project’s core development and engineering rules.
 
-Verify implicit and explicit assumptions: “Is this really the case that ...?”, “Might there have been a simpler pattern used elsewhere?”, etc.
+Verify implicit and explicit assumptions: “Is this really the case that ...?”, “Might there have been a simpler way to get the same end result?”, “Is there any element, pattern, or system in the project that the work under review would have benefited from considering or using, but seemingly overlooked due to a bad judgment call or plain lack of awareness?”, etc.
 
 The threshold for what constitutes an issue is high — don’t surface noise.
 
-{ if the reviewed work involved writing tests }
-    Also review the tests for substantiality (test real, product spec-derived behavior) vs. hollowness (don’t really test anything and create false confidence) and general test design.
-{ end if }
+If the reviewed work involved writing tests:
+Also review the tests for substantiality (test real, product spec-derived behavior) vs. hollowness (don’t really hold any bar, test the implementation, or create false confidence) and general test design.
 
 You are a reviewer, not an executioner. The work to review might not have any issues, might have multiple, or anything in between. Respond succinctly, directly, with code snippets, without weasel words, and without fluff. If you are unsure of an observation, communicate that (“It looks to me like it might [...] — please verify.”). If you are certain, communicate as usual.

package/plugins/soft-skills/skills/peer-review/references/self-peer-review.md

@@ -5,21 +5,25 @@ arguments: work_to_review
 loads: references/peer-review-instructions.md
 ---
 
-First, commit your work to have a commit reference. Then dispatch a large subagent (thinking=xhigh if project is medium-sized, thinking=max if large) with the following prompt:
-
----
+First, commit your work to have a commit reference. Then dispatch a fresh, flagship subagent (thinking=xhigh if project is medium-sized, thinking=max if large) with the following prompt:
 
+```
 The user has given me this task:
 <original-user-task>  # Quote verbatim.
 { original user task that resulted in work_to_review }
 </original-user-task>
 
-I have attempted to complete it. It’s committed to { commit_sha }.
+I have attempted to complete it. My work for your review is committed to { commit_sha }.
 
-@peer-review-instructions.md <work_to_review> <research_targets="Blast radius of {commit_sha}".>
+It touches the systems `A`, `B`, `C` and `D`: `A` publishes an event to `B`, `B` attempts to write to `C` then reports back to `A`, and depending on the report, `A` might talk to `D`.    {# Keep it ultra high-level and brief, like I wrote here. "`A` publishes an event to `B`" is literally enough if that's what `A` does. Do not mention how the systems work. Definitely do not say why they work the way they do. Do not try to be comprehensive. #}
 
-{ if original user task references skills }
-    Load the referenced skills yourself for complete understanding:
+Load the `peer-review` skill and follow its `peer-review-instructions.md` reference.
+
+{ if original user task includes instructions to load skills, documents and context-gathering resources: }
+    Load the following skills, docs and resources to gain deep understanding of the review space:
     - `skill-1`: `path/to/skill-1/`
+    - `doc.md`: ...
     - ...
-{ end if }
+```
+
+When the review findings are back, note whether a review item is out of scope, or implicitly makes new design decisions behind the words that might be true, but following them would be scope creep. The reviewer is instructed to surface only real issues, not noise, but there is still place for you to exercise judgment.