@robot-inventor/agent-skills 1.0.0 → 1.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@robot-inventor/agent-skills",
-  "version": "1.0.0",
+  "version": "1.1.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

@@ -24,9 +24,9 @@ The following is the core of this skill; please follow the specified steps.
 
 ### 1. Request a code review
 
-Request a code review from the subagent.
+Request a code review from the subagent.If you have the option to choose whether to fork the context or launch the subagent in an isolated context when starting it, **always** launch it in an isolated context.
 
-If you have the option to choose whether to fork the context or launch the subagent in an isolated context when starting it, **always** launch it in an isolated context. Refer to the following for the prompt to send to the review agent.
+Submit review requests to the review agent using a prompt that strictly adheres to the following format. Review request prompts are not free-form; you must use the template below.
 
 ```md
 You are a code review agent. Thoroughly review the code for design issues, bugs, vulnerabilities, and oversights, and report the findings categorized as critical, high, medium, low, or informational. In addition to reviews that increase the amount of code, also check for over-engineering, such as excessive implementation or unnecessary conditional branching, in accordance with simple-engineering skill. In addition to the small details of the code, you should also consider whether there are simpler designs or alternative approaches to the overall logic of the changed parts, following the principles of simple-engineering. If you find any, you should report them, even if it requires rewriting the code being reviewed from scratch.
@@ -37,7 +37,7 @@ Flag excessive validation, overly defensive implementation, and unnecessary comp
 - User's instructions: {user's request / instructions}
 ```
 
-Code reviews by sub-agents can take time. Please note that if you re-spawn a sub-agent currently undergoing a review simply because it has not yet responded, the review process will start over from scratch, resulting in even longer wait times. It is also prohibited to send additional prompts to urge a review when a review agent is taking a long time to respond.
+Code reviews by sub-agents can take time. Note that if you re-spawn a sub-agent currently undergoing a review simply because it has not yet responded, the review process will start over from scratch, resulting in even longer wait times. It is also prohibited to send additional prompts to urge a review when a review agent is taking a long time to respond.
 
 ### 2. Receive reviews and improve your code
 

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