@robot-inventor/agent-skills 1.3.0 → 1.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@robot-inventor/agent-skills",
-  "version": "1.3.0",
+  "version": "1.4.0",
   "description": "Roboin's personal collection of Agent Skills.",
   "homepage": "https://github.com/Robot-Inventor/agent-skills#readme",
   "bugs": {

package/skills/review-loop/SKILL.md

@@ -8,7 +8,7 @@ metadata:
 
 # Review Loop Skill
 
-This skill involves thoroughly improving code quality by repeatedly requesting a review from a sub-agent after editing and improving the code based on the results. Humans typically improve code quality by creating a pull request after editing code and having it reviewed by a reviewer. Such reviews are important because they can identify problems that might be missed through self-review alone.
+This skill involves thoroughly improving code quality by repeatedly requesting a review from a sub-agent after editing and improving the code based on the results. Humans typically improve code quality by creating a pull request after editing code and having it reviewed by a reviewer. Such reviews are important because they can identify problems that might be missed through self-review alone. Ignore this skill when the user explicitly instructs to skip the review-loop.
 
 ## When to apply
 

package/skills/simple-engineering/SKILL.md

@@ -37,7 +37,3 @@ Refactoring should not be done only at special times; if there are poorly design
 ## DRY principle and modifiability
 
 Keep the DRY principle and modifiability in mind. Avoid defining the same thing repeatedly; instead, aim for code that is easy to modify, where changing a single location automatically updates all related processes. For instance, regarding i18n, the ideal approach is to manage available languages and their labels in one place, such that adding or removing a language requires only updating that single location and adding or removing the corresponding translation file.
-
-## Establish a shared understanding
-
-If `request_user_input` tool is available, actively use it when asking the user questions, especially while running the grilling session. Do not use it for a single yes/no question; instead, use it when asking multiple questions at once or when presenting multiple options. The tool description specifies limiting the number of questions to between one and three, but this is not a functional constraint. If you have more than four questions, enter all of them in `request_user_input`, without limiting yourself to three or fewer.

package/skills/web-master/SKILL.md

@@ -139,6 +139,33 @@ const parsed = Person(externalValue);
 parsed instanceof type.errors ? "Unknown" : parsed;
 ```
 
+### Do not omit curly braces
+
+Unless otherwise specified in project documentation or formatters, do not omit curly braces except in early returns. Also, group the code by its logical content using blank lines, just as a human would.
+
+```ts
+// Incorrect
+
+const main = (value) => {
+    if (!Array.isArray(value)) return null;
+    for (const item of value) console.log(item);
+    if (value.length > 0) console.log("Array is not empty");
+}
+
+// Correct
+const main = (value) => {
+    if (!Array.isArray(value)) return null;
+
+    for (const item of value) {
+        console.log(item);
+    }
+
+    if (value.length > 0) {
+        console.log("Array is not empty");
+    }
+}
+```
+
 ## CSS
 
 ### Define only the necessary styles
@@ -205,6 +232,8 @@ Do not mock application-owned modules. Prefer real implementations and test obse
 
 Test the behavior from an external perspective, not the internal implementation. In other words, tests that require changes when refactoring are bad tests. Test the project's code, not the browser or external libraries. For example, it's obvious that a button element will be displayed in the browser when you write it; this tests the browser's behavior, not the project's code.
 
+Add only the necessary tests. Ensure that your tests verify the correct operation of the code and are capable of detecting when the code breaks. Testing outcomes that are already expected to occur is pointless, and tests that fail to detect when the code is broken are worthless. Test the externally observable behavior of the code when provided with normal, boundary, and anomalous input values.
+
 ### Do not export for testing purposes
 
 You should not export functions, values, or other data solely for testing purposes. When testing things that are not used outside of the file except for testing, use [in-source testing](https://vitest.dev/guide/in-source) instead of exporting them and creating a separate test file.