soft-skills 2.1.19 → 2.1.20

package/package.json

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

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.