@robot-inventor/agent-skills 1.0.1 → 1.1.0

package/package.json

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

package/skills/simple-engineering/SKILL.md

@@ -16,7 +16,7 @@ Before implementing a feature or fixing a bug, consider all options. Instead of
 
 Also avoid bringing unnecessary complexity into your code. Carefully examine related processing to ensure there are no impossible conditional branches or unnecessary try-catch blocks. Check the type definitions and actual processing, and remove any impossible conditional branches. There is no need to wrap code in a new try-catch block if an exception is unlikely to occur normally or if a try-catch already exists inside the called function.
 
-Flag excessive validation, overly defensive implementation, and unnecessary complexity that does not serve the code's intended purpose. For example, a function that opens product links for a specific website may only need to verify the hostname. Checking the pathname may add complexity without improving security. You might remove validation by defining the function argument as a type such as `https://example.com/product/{string}`, or by accepting only a product ID and constructing the link inside the function. These are examples, but you should look for simpler implementations of the same kind. Ask what purpose the code serves and whether the implementation contains only what that purpose requires.
+Flag excessive validation, overly defensive implementation, unnecessary intermediate representation, and unnecessary complexity that does not serve the code's intended purpose. For example, a function that opens product links for a specific website may only need to verify the hostname. Checking the pathname may add complexity without improving security. You might remove validation by defining the function argument as a type such as `https://example.com/product/{string}`, or by accepting only a product ID and constructing the link inside the function. These are examples, but you should look for simpler implementations of the same kind. Ask what purpose the code serves and whether the implementation contains only what that purpose requires.
 
 ## Avoid reinventing the wheel
 

package/skills/web-master/SKILL.md

@@ -114,10 +114,31 @@ if (myArray.length) {...}
 
 The `max-lines` and `max-lines-per-function` rules exist as indicators of code readability and maintainability. Warnings for these rules suggest that your code design may be poor. Simply removing line breaks to meet the rules is a superficial solution and actually makes the code harder to read, thus violating the essence of the rules. Instead, you should fix the problem by removing redundant code or properly restructuring and modularizing it. If you've only slightly exceeded the limit and your code is already well-designed, you should disable the rules rather than removing line breaks or forcing splits.
 
-### Design code with types at its core
+### Do not validate it yourself
 
 TypeScript types are not just an afterthought to JavaScript. Designing with types in mind keeps your code clean and efficient. With proper type design, validation is rarely needed except at project boundaries such as user input or web API responses. When code is properly designed based on types, function inputs and outputs are reliable, eliminating the need to validate values repeatedly.
 
+Check the project dependencies to see if a validation library is installed. If one is installed, you should leverage the library's features rather than writing your own validator.
+
+```ts
+// Incorrect
+const isRecord = (value: unknown): value is Record<string, unknown> => typeof value === "object" && value !== null && !Array.isArray(value);
+const isParson = (value: unknown): value is Person => isRecord(value) && typeof value.name === "string" && typeof value.age === "number" && value.age >= 0;
+
+isParson(externalValue) ? externalValue : "Unknown";
+
+// Correct
+import { type } from "arktype";
+
+const Person = type({
+    name: "string",
+    age: "number >= 0"
+});
+
+const parsed = Person(externalValue);
+parsed instanceof type.errors ? "Unknown" : parsed;
+```
+
 ## CSS
 
 ### Define only the necessary styles
@@ -126,10 +147,48 @@ When writing CSS, first check if a reset CSS is loaded into your project and if
 
 In CSS, you should only specify properties that need to be changed from the parent element, and you should not specify properties that do not need to be changed again. Remember that CSS has inheritance, and style accordingly.
 
+```css
+/* reset.css */
+* {
+    margin: 0;
+}
+```
+
+```css
+/* style.css */
+
+/* Incorrect */
+h1 {
+    margin: 0;
+    font-weight: bold;
+}
+
+h1 div {
+    font-weight: bold;
+}
+
+/* Correct */
+h1 {
+    font-weight: bold;
+}
+```
+
 ### Intentional typography design
 
 Do not specify `font-family` outside the document root unless absolutely necessary, such as in code blocks. Also, as a general rule, do not change the font size unless there is a clear reason, such as making unimportant notices smaller or headings larger. Since the base font size may be overridden by browser settings, use `em` or `rem` instead of `px` for font size or areas that depend on font size.
 
+```css
+/* Incorrect */
+h1 {
+    font-size: 32px;
+}
+
+/* Correct */
+h1 {
+    font-size: 2rem;
+}
+```
+
 ## HTML and JSX
 
 ### Avoid redundant definitions